[Fim4l] CoCo / attributes for authorization

Peter Gietz peter.gietz at daasi.de
Wed Mar 20 20:06:20 CET 2019


Hi Peter S.

This is getting a bit stressful...

Yes I know about entitlement common-lib-terms, and that it specially 
designed for libraries, and thanks for mentioning it, which I forgot, 
but I am not sure whether that will be the only entitlement that 
contracts will be based upon in the future. FIM will allow for more 
precise definition of users, which will make licenses cheaper for 
libraries. I may be wrong here, but I'd rather be corrected by 
librarians actually signing contracts.

Yes its is good to have such an technical expert like you in this list, 
but please be aware that we have to also tackle non-technical issues 
here. And please be also aware that some people subscribed to this list 
are rather non-technical. It is ok to correct things, and I very much 
appreciate this, but we should not get too much into technical details. 
There are more appropriate lists for that.

Yes we have new alternatives than targetedID, but I fear that attribute 
is still common practice and we should IMO  name both targetedID and 
pairwise subjectID. Especially when RA21 only named targetedID. We are 
talking about a community that is rather slow in adapting new 
technologies and we cannot expect very current state of the art in 
software and in software configuration.

Cheers,

Peter G.



Am 19.03.2019 um 16:52 schrieb Peter Schober:
> * Peter Gietz <peter.gietz at daasi.de> [2019-03-19 15:46]:
>> I have a few comments here based on also reading between the lines:
>>
>>> Earlier this year (2019), the RA21 Security & Privacy group endorsed
>>> the GEANT Data Protection Code of Conduct as guidance that RA21 should
>>> follow: data minimization, purpose limitation, data retention, and
>>> more.
>> Basically "RA21 endorses Coco" only says "RA21 endorses GDPR" which in
>> Europe has not a lot more meaning than "we want to follow the law". But
>> outside of Europe, especially in the US this is of course significant.
> I remember the old (v1) GEANT CoCo saying that contracts always
> overrule whatever the CoCo requires because they're more specific.
> (Last time I looked I didn't find language to that regardin in v2 but
> that doesn't mean that contracts between two parties won't prevail
> nonetheless.)
>
> Since instiuttionally licensed resources will almost always be covered
> by contracts I don't see the significance of that announcement (as
> well). But of course getting the word out about the GEANT CoCo and
> maybe getting it validated in commercial contexts (licensed resources
> cost a lot of money which satisfies my ad.hoc criterion of "commercial
> context" here) can only be benefitial.
>
>> This is more or less the opposite of:
>>
>>> unless the Service Provider (such as a publisher or
>>> other content vendor) has a specific agreement with an Identity
>>> Provider (IdP - usually an individual’s institution) to receive
>>> additional data the IdP should only send anonymous and pseudonymous
>>> identifiers to the Service Provider.
> Well, ignoring "anonymous" for now (as there's no use for that within
> federated identity management ever so could well be removed from any
> documents) there's a realization that pretty much everything today
> (under GRPD at least) will be considered personal data,
> incl. pseudonyms, and so the CoCo could still provide legal support
> for transferring and processing this.
>
> But see the argument about contracts > code of conducts above.
>
>>> Specifically, the service
>>> provider should only ask for eduPersonEntitlement and, optionally, a
>>> pseudonymous pairwise user identifier (e.g., eduPersonTargetedID)
>> eduPersonTargetedID is a very good choice since it does not allow
>> for user tracking beyond one SP, since every SP gets a different ID
>> for the same user.
> The idea of "targeted"/"pairwise"/SP-specific identifiers is good, but
> not the eduPersonTargetedID attribute itself, in 2019.
> eduPersonTargetedID is dead, or should long have been.
> https://wiki.univie.ac.at/display/federation/eduPersonTargetedID
>
> 1. It should never have been defined for use with SAML2 (according to
> some of the people involved), instead it should have been replaced
> with proper SAML2 persistent NameIDs once SAML2 defined those in 2005.
>
> 2. saml2int ("old") -- the best standard for interop we have -- has
> been reommending againt eduPersonTargetedID (and for proper persistent
> NameIDs, i.e., in the Subject elelement of the SAML2 Assertion) for
> many, many years now.
>
> 3. There's a case-folding issue both with "proper" persistent NameID
> and therefore equally with eduPersonTargetedID attributes that could
> cause information disclosure (one person seeing someone elses data at
> an SP, e.g. the history of the content they searched for!).
> We/You can't continue pretending this does not exist and on the other
> hand claim we are sooo concerned about privacy, even more so than the
> federations themselfs (cf. "talk to InCommon about privacy").
>
> 4. saml2int ("new") requires use of the replacement identifiers and is
> veryy clearly worded in this regard.
>
> Short version: We all need to adopt and prompte pairwise-id and stop
> even mentioning the old eduPersonTargetedID attribute, except in some
> legacy/migration from old-to-current documents.
>
>> But there are other Attributes in use in addition or in stead of the
>> second attribute mentioned, eduPersonEntitlement, namely
>> eduPersonScopedAffiliation. So why does RA21 recommend entitlement?
> Here's the simple reasoning:
> https://wiki.univie.ac.at/display/federation/Library+Services
> The common-lib-terms value for the eduPersonEntitlement attribute is
> static and the same for every SP and from every IDP. (No other
> entitlement is relevant for this discussion/sector.)
>
> That alone creates massive scalability benefits for everyone, because
> IDPs do not have to tell the SP just what eduPersonScopedAffiliation
> attribute values they consider to be covered by the specific contract.
> (Unless the SP makes assumptions about how the IDP implemented
> eduPersonAffiliations every IDP will need to tell every SP just what
> affiliation values are to be considered authrorized.)
>
> But the common-lib-terms entitlement (value) also has further
> scalability advantages: In SAML 2.0 Metadata (cf. eduID.at) you can
> list not only the RequestedAttribute' names (as is commonly done) but
> also the *values* a given SP requires. With sufficiently powerful
> software (e.g. the Shibboleth IDP) that means the attributes released
> by the IDP can be automatically filtered to the values provided in
> metadata, without manual intervention.
>
> A single and static configuration rule in the IDP can tell the IDP to
> release the (non-PII) common-lib-terms value to any SP that says it
> needs it. *Nothing* *else* is required from the IDP if the SP supports
> his attribute (and can work without identifiers).
>
> On the other hand affiliations are mostly (or exclusively) used in
> their "scoped" variant, and that prevents an SP from ever listing the
> expected attribute *values* in metadata, as the SP would have to list
> the acceptable affiliations mutiplied by the scopes of all their
> customers' scopes, i.e.:
> staff at univie.ac.at
> faculty at univie.ac.at
> student at univie.ac.at
> employee at univie.ac.at
> staff at jku.at
> faculty at jku.at
> student at jku.at
> faculty at mci.edu
> student at mci.edu
> etc.
>
>> Here is my hypothesis:
>> entitlement means that the IdP side knows about the rights at the service.
> [...]
>> This means that the complex algorithm, evaluating contracts to specify
>> entitlements has to be implemented on the IdP side.
> That's correct only in the fully abstract and ignoring the /one/
> attribute *value* for the eduPersonEntitlement attribute that has been
> agreed for this use-case specifically (access to institutionally
> licensed resources). So I also only speak to that one entitlement
> *value*, not to using entitlements in general.
>
> In fact looking at the eduID.at documentation (link below) you can see
> that an IDP can simply and automatically derive the common-lib-terms
> entitlement from an existing affiliation.
>
> I.e., if an IDP can produce eduPerson(Scoped)Affiliation attributes
> -- which arguably are the main/only remaining value proposition of
> academic IDPs and so should be supported by any academic IDP on the
> planet -- then the IDP only needs to add one trivial rule that creates
> the common-lib-terms entitlement from a set of (locally decided)
> affiliations and be done with this. For *all* SPs that can support
> common-lib-terms entitlments.
>
> Example from our documentation: "If the subject has the 'member'
> affiliation then give it the common-lib-terms entitlemen', too".
> https://wiki.univie.ac.at/display/federation/IDP+3+Attribute+resolution#IDP3Attributeresolution-eduPersonEntitlement
> (That's the simplest possible case since 'member' is defined in
> eduPerson to include 'staff', 'faculty', 'employee' and 'student'. So
> all of these will also have 'member' and so all of these groups will
> get the common-lib-terms entitlement added.)
>
> It's trivial to create on the IDP side and makes comparison and
> agreement much easier for everyone involved: IDPs (no guessing or
> per-SP-configuration overhead what affiliation values the SP wants),
> for federation operators (all e-resource services are handled the same
> way) and IDPs (one attribute with one static value means no more
> per-IDP configuration).
>
>> The IdP can quite easily release the affiliation (IdPs generally
>> know what relation exists between the user and the institution, and
>> to which subdomain a user belongs). If this attribute is sent to
>> publishers, the computing and comparing with the contracts is on the
>> SP side.
> Not yet achievable just from your decription, though: The IDP would
> also have to configure (via a self-service interface at the SP or via
> their request/ticket system or sales contact) *which* of their values
> should be allowed and which should not.
> Repeated for every SP they use.
> Repeated at every IDP that uses such SPs.
> And it's all completely avoidable!
>
>> If publishers require entitlement it means IMO that they trust the
>> institutions to tell the truth and that they want less work on their
>> own side.
> Obviously that's always the case (trusting that IDPs don't lie), same
> with affiliations or anything else.
> If an IDP lies that IDP risks getting thrown out of the federation and
> possibly worse (contract violations).
> In other words: My IDP might as well lie to just one SP using
> affiliations. How is anyone supposed to detect that?)
>
>> Thus my recommendations to libraries would be to rather agree to
>> contracts based on affiliation than on entitlement.
> For the reasons stated above (and on the wiki page I referenced) I
> think the opposite should be the case. ;)
>
> Currently IDPs simply have to support both models because some SPs
> only support one or the other, increasing the effort slightly (both
> are trivially easy to support, but knowing when to use what is an
> overhead, of course).
> Within eduID.at I curate the metadata such that any SP that's known to
> support the common-lib-terms entitlement for authorization (either by
> default or on request) only has that attribute listed.
> I.e., those that play by the rules have it Just Work.
> Make those do extra steps that insist on doing it in less efficient ways.
>
> Best regards,
> -peter
> _______________________________________________
> Fim4l mailing list
> Fim4l at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l

-- 

Peter Gietz, CEO

DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany

phone: +49 7071 407109-0
fax:   +49 7071 407109-9
email: peter.gietz at daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz




More information about the FIM4L mailing list