[Satosa-dev] SaToSa support for new SAML subject identifiers

Niels van Dijk niels.vandijk at surfnet.nl
Tue Mar 3 16:09:21 UTC 2020

Hi Alex, Ivan,

Many thanks for your thoughts and suggestion so far.

You have I think addressed 2 out of my 4 concerns in this regard:

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
I think it would be nice to perhaps provide example configuration that
shows how to set that up.

2) For reissue, I think Alex's work fits in nicely, haven't tested that
yet though, but many thanks for the pointer.

3) When SaToSa acts as a SAML entity, the use of subject identifiers
required some additional metadata statements. like e.g.:


    <saml:Attribute Name="urn:oasis:names:tc:SAML:profiles:subject-id:req" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">




We need to see if this is supported and (assuing it is) it would be nice
to provide a config example again.

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?



On 03-03-2020 14:29, Ivan Kanakarakis wrote:
> Hello Niels,
> On Tue, 3 Mar 2020 at 14:40, Niels van Dijk <niels.vandijk at surfnet.nl> wrote:
>> Hi all,
>> Is there an existing implementation (or planned) implementation of the
>> new SAML subject  identifiers [1] ?
> 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
> https://github.com/IdentityPython/pysaml2/commit/6d611b715ca11b2f8250024ba6a8d6f3377609a3).
> 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,
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
www.surfnet.nl                                www.openconext.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sunet.se/pipermail/satosa-dev/attachments/20200303/9f08fbce/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sunet.se/pipermail/satosa-dev/attachments/20200303/9f08fbce/attachment.sig>

More information about the Satosa-dev mailing list