Hi,
thanks, Peter & Peter, Raoul.
I’d suggest adding CoCo support for smooth attributes release and to be in-line with RA21 recommendations.
Cheers
Jiri
On Thu, 21 Mar 2019 at 14:14, Peter Schober peter.schober@univie.ac.at wrote:
- Peter Gietz peter.gietz@daasi.de [2019-03-21 14:55]:
- we will recommend common-lib-terms entitlement and scoped affiliation
One vital missing piece here is to recommend (though I'm in favor of much stronger wording) that authorization is actually performed by the SP based on transmitted attributes. I.e., "We don't need no attributes" should not be acceptable.
While there may be cases where indeed "everyone and everything that can authenticate" at an institution is covered by the contract (I know of exactly one such case) even then tying the contract to the IDP's entityID (there's nothing else to tie it to without any attributes) is an anti-pattern: Not every institution runs/maps to exactly one entityID.
In the vast majority not processing any attributes (as part of federated logins) will simply mean the SP expects the IDPs to only sends authorized subjects to the SP (i.e., abort SSO for those subjects which should not be allowed access to the SP according to the SP's rules), which does not scale: Federation is based on the IDP performing authentication and asserting things and the SP performing authorization based on the asserted data.
An SP not looking at any attributes makes it impossible for an IDP to tell the SP that someone should NOT be able to access licensed resources on behalf of the institution.
Should the IDP not completely block access to the SP that then creates a legal risk and potential fingerpointing between the SP ("The IDP should not send us unauthorised people") and IDP ("The SP should look at the data we sent were its clear the person is not authorized").
- we will recommend targetedID quoting chapter 2.2.11 of eduperson201602
( https://wiki.refeds.org/pages/viewpage.action?pageId=38895708#eduPerson(2016... )
and its follow up attribute pairwise subjectID quoting chapter 3.4. of
the
January 2019 specification (
http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-i... )
That would directly go against saml2int that has had an RFC-SHOULD there for many years:
"If an opaque targeted user identifier is being provided to the Service Provider, it is RECOMMENDED to use a saml2:NameID construct with a Format of urn:oasis:names:tc:SAML:2.0:nameid-format:persistent rather than transporting that identifier as an saml2:Attribute." ( https://saml2int.org/profile/current/#section7 )
It would also ignore the new saml2int which has much stronger language on not requiring any NameID or Attribute for identification.
But give me a couple of days/week to find out whether the former can be formally deprecated or something else to that effect. Our deployment profiles have been speaking out against ePTID for many years now, it's time to close that chapter.
-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l