<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Alex, Ivan,</p>
    <p>Many thanks for your thoughts and suggestion so far. <br>
    </p>
    You have I think addressed 2 out of my 4 concerns in this regard:<br>
    <p>1) First of all with the comments below from Ivan, we could
      indeed either create relevant configuration for accepting
      'incoming' SAML based subject id attributes and how these get
      mapped internally. Seems straightforward at first glance, perhaps
      a bit of thought is needed to identify if incoming IDs should be
      passed on directly into the sub or should be reissued. The same
      goes for the reverse scenario where a sub is incoming and needs to
      be transformed into the equivalent SAML attribute<br>
      I think it would be nice to perhaps provide example configuration
      that shows how to set that up.<br>
    </p>
    <p>2) For reissue, I think Alex's work fits in nicely, haven't
      tested that yet though, but many thanks for the pointer.<br>
    </p>
    3) When SaToSa acts as a SAML entity, the use of subject identifiers
    required some additional metadata statements. like e.g.:<br>
    <br>
    <pre>  <mdattr:EntityAttributes></pre>
    <pre>    <saml:Attribute Name="urn:oasis:names:tc:SAML:profiles:subject-id:req" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"></pre>
    <pre>      <saml:AttributeValue>any</saml:AttributeValue></pre>
    <pre>    </saml:Attribute></pre>
    <pre>  </mdattr:EntityAttributes></pre>
    We need to see if this is supported and (assuing it is) it would be
    nice to provide a config example again.
    <p>4) As we can probably not just drop support for other incoming
      identifier SAML attributes, some of us may need to update their
      business login to select the properer identifier to use depending
      on what the IdP is sending. Given that this will be a common theme
      for the many years we have both old identifier attributes and the
      new subject identifiers, I guess it would make sense to provide
      some default config or code for that as well?</p>
    <p>Best,</p>
    <p>Niels<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 03-03-2020 14:29, Ivan Kanakarakis
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJnvVWVp-jv1eVhGhAzAzyvYUWTMHZje9Ca615OxjEdxPRX8Tw@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Hello Niels,


On Tue, 3 Mar 2020 at 14:40, Niels van Dijk <a class="moz-txt-link-rfc2396E" href="mailto:niels.vandijk@surfnet.nl"><niels.vandijk@surfnet.nl></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
Hi all,

Is there an existing implementation (or planned) implementation of the
new SAML subject  identifiers [1] ?

</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
I am not sure what it is that you are looking for in satosa. The
satosa core does not know anything about protocols. The new subject-id
is a SAML concept. PySAML2 can recognise it (see
<a class="moz-txt-link-freetext" href="https://github.com/IdentityPython/pysaml2/commit/6d611b715ca11b2f8250024ba6a8d6f3377609a3">https://github.com/IdentityPython/pysaml2/commit/6d611b715ca11b2f8250024ba6a8d6f3377609a3</a>).
Having said this, the new identifier takes the form of an attribute.
This means that the saml frontend and backend will translate it to
satosa's internal structure as a key-value under the internal-data
attribute structure (`internal_data.attributes["subject-id"]` and
`internal_data.attributes["pairwise-id"]` will contain the
corresponding values; if those were received).
Same goes for the internal_attributes.yaml configuration, where you
can map to which internal name and claim or SAML-attribute you want to
map the value. You do this by a configuration like so

```
attributes:
  identifier:
    openid: [sub]
    saml: ["subject-id"]
...
```

I hope this helps.


Cheers,

</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Niels van Dijk        Technical Product Manager Trust & Security
Mob: +31 651347657  |   Skype: cdr-80  |  PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
<a class="moz-txt-link-abbreviated" href="http://www.surfnet.nl">www.surfnet.nl</a>                                <a class="moz-txt-link-abbreviated" href="http://www.openconext.org">www.openconext.org</a></pre>
  </body>
</html>