9:38 a.m.
Hi Alex,
Thanks for the heads-up. Based on what you write it might indeed need a
bit more work, but for sure we can draw some inspiration form your code ;)
thx,
Niels
On 03-03-2020 22:06, Alex Stuart wrote:
Hi Niels,
--
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
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/AttributeEncoderPlugin…)
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 ...
Regards,
Alex
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?
Best,
Niels
On 03-03-2020 14:29, Ivan Kanakarakis wrote:
—
Alex Stuart, Technical Development Manager (Trust and Identity)
alex.stuart at jisc.ac.uk
Hello Niels,
On Tue, 3 Mar 2020 at 14:40, Niels van Dijk
<niels.vandijk at surfnet.nl>
wrote:
--
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 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/6d611b715ca11b2f8250024ba6…
).
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,