[Satosa-dev] SaToSa support for new SAML subject identifiers
Alex.Stuart at jisc.ac.uk
Tue Mar 3 21:06:00 UTC 2020
> 2) For reissue, I think Alex's work fits in nicely, haven't tested that yet though, but many thanks for the pointer.
Thanks, but the microservice quite rough & I don't know Satosa well:
- The scope is hardcoded and I needed to manually ensure the it matched the scope in metadata.
- I'm not aware of attribute encoders in Satosa (like the Shibboleth IdP's, https://wiki.shibboleth.net/confluence/display/IDP30/AttributeEncoderPluginConfiguration) so I wrote the data manipulation within the class.
- I was confident that I'd receive eduPersonTargetedID for the lifetime of the project so pairwise-id is constructed directly from eduPersonTargetedID, and I didn't need to handle the mapping you describe in (4). To manage the migration from one incoming identifier to another, I presume that proxies would need to generate the pairwise-id from an intermediate attribute, and store a many-to-one mapping from the incoming attributes to that intermediate attribute. I seem to recall there were a couple of massive threads on this about a year ago on the REFEDS list ...
> 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>
>>> Hi all,
>>> Is there an existing implementation (or planned) implementation of the
>>> new SAML subject identifiers  ?
>> 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
>> 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
>> openid: [sub]
>> saml: ["subject-id"]
>> I hope this helps.
> 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
Alex Stuart, Technical Development Manager (Trust and Identity)
alex.stuart at jisc.ac.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4313 bytes
Desc: not available
More information about the Satosa-dev