The motivation behind scoping the eduPersonEntitlement attribute is very similar to the motivation of scoping eduPersonPrincipalname. That is, the attribute consumer might want to accept a certain subset of values from an Issuer and not have just one rule of filtering for every possible issuer or no filtering at all.

The issuer may also want to cross-check an Issuer's authority for values with a given scope with the SAML Metadata, just like a scope used in eduPersonPrincipalName can be checked in the metadata.

One pressing use case for eduPersonScopedEntitlement (epse) is distributed authorization. Consider a cloud provider that wants to serve several Virtual Organizations, managed by different Virtual Organization Manager Entities. In SAML terms this means contacting different Attribute Authorities by Attribute Queries by the SP itself or by a proxy and aggregate entitlements of the principal is about to log in. One such deployment is openstack.hbit.sztaki.hu that is accepting eduPersonEntitlements from HEXAA, PERUN and a Grouper instance as well. The intention is that each AA releases entitlements belonging to a different tenant within the cloud. However, the problem is that every Attribute Authoritiy could release any value that the others can. In a future where Virtual Organization Manager platforms can be acquired as a service, the number of AAs in federations, i.e. eduGAIN might be similar to IdPs. And just as like SPs cannot trust every IdP to not impersonate another IdP's users - therefore they use eppn with scoping - they will not be willing to accept every entitlement value from every AA.


Syntax: DirectoryString (1.3.6.1.4.1.1466.115.121.1.15)

Equality: caseExactMatch


Format: <anyUri>@<scope>


<scope>: something (could be a domain name) that is associated with the issuing entity in metadata - not the same scope that we use for eppn

<anyUri>: any valid URI.


Examples:

urn:mace:dir:entitlement:common-lib-terms@hexaa.eduid.hu

urn:geant:niif.hu:hexaa:projectfoo:bar@hexaa.eduid.hu

urn:elixir:foo:baz:bar@aa.scope.com

urn:x-perun:baz-collaboration.foo-service.bar-value@perun.org

https://cern.ch/unifocaltelescope/admin@perun.cz

urn:REGISTERED_NAMESPACE:[auth source]:{target}:{service}:{[entitlementName]}:[entitlementValue]@perun.org


Benefits:

  • can use any URIs in the “local-part”, thus existing eduPersonEntitlement values as well

  • scope can be verified by using existing code in Shibboleth&SimpleSAMLphp. They can also handle multiple occurrence of the delimiter character.


Gotchas:

  • the whole edupersonScopedEntitlement is NOT a URI, because the position of ‘@’ delimiter is reserved in RFC 2396

    RFC 2396 was obsoleted by RFC 3986
  • No labels

9 Comments

  1. Keith Hazelton

    There is at least one way, probably many, to accomplish the desired result and use a syntax that can still constrain these 'scoped' entitlements to be valid URIs. That approach makes "scoped" entitlements legitimate eduPersonEntitlement values. That would mean no need to create an additional attribute.

    It does involve defining a REFEDS-scale convention to represent ePEs as URLs with a particular query parameter: eduPersonEntitlement.

    Assume VO neurogastro.institute uses an Attribute Authority Service, AAaaS.net.  Trusted metadata for neurogastro.institute states this relationship. For a user with neurogastro entitlements; a SAML attribute assertion might carry something like this: "eduPersonEntitlement: http://neurogastro.institute?entitlement=endocycle". AAaaS.net asserts it, and the metadata allows SPs to trust that AA's assertions about neurogastro.institute entitlements.

    1. Scott Cantor

      I think it's clearly possible to do this without a new attribute but not if you want to immediately automate policy at the SPs using existing code.

      Shibboleth can certainly easily impose rules based on issuer and a regex against the values, but somebody would have to write them into the system or enable them.

      Personally, though, that's still my preference. I think this use case is sufficiently rare that needing to write those rules is a pretty minor issue.

    2. Keith Hazelton

      I guess a more RESTful approach would be to consider entitlements as a resource. That would yield URLs like http://api.neurogastro.institute/v1/authz/entitlements?value=endocycle 

      This also suggests actually using RESTful APIs (with appropriate access control, a non-trivial problem) to manage and query attributes.

      For example, GET http://api.neurogastro.institute/v1/authz/entitlements?value=endocycle would return either a (JSON) representation of the endocycle entitlement as defined by the Institute of Neurogastronomy or a 404. POST, PUT, DELETE would round out the CRUD operations on entitlements.

  2. Scott Cantor

    I think this idea raises some serious questions. Historically we've wanted to see shared definitions of entitlements and not require every IdP to issue its own. If you were to "scope" a shared entitlement, you are effectively just moving the declaration of what today would be a filter policy on eduPersonEntitlement into an application authorization rule that enumerated which "scopes" you would accept the entitlement from.

    In other words, you're still manually creating a rule per IdP. In which case, why not just skip the "scope" altogether and use URIs today with a filtering rule on which IdPs to accept the URI from? I don't see much difference.

    I think this idea only makes sense if you're thinking about non-shared entitlement definitions that are specific to an issuer, but even there I haven't quite wrapped my brain around it yet. There may be something there, not sure.

    1. Keith Hazelton

      I was thinking of SP-specific entitlements when I came up with this example. The IdP in this scenario is 'just' an AAaaS that carries SP-specific entitlements on behalf of its many service subscribers. I.e. AAaaS.net is holding neurogastro attributes that are probably of interest mainly to neurogastro SPs.

      I need to study up on how filter rules are managed and used....

      1. Scott Cantor

        SP-specific essentially means "shared" in my parlance. I don't believe there is any benefit to "scoping" such entitlements. Once you work through the scenarios, it doesn't work. You end up with exactly the same policy rules (and control) in each case, the rules are just slightly different.

        I'm not sure of that in the case where an entitlement is unique to an IdP, but in either case I think you end up with a cleaner situation by just using URIs and writing rules for who can assert them to you. I think scoping just confuses matters in this case.

        1. Keith Hazelton

          So, as I understand you, the rules you are talking about are one per AA and per entitlement value:

            AA: X.com  ok to assert Entitlement: http://refeds.org/entitlements/value?2348028u3434

            AA: X.com  ok to assert Entitlement: http://refeds.org/entitlements/value?4545685344060 

            .....

          Based on the above, I would change my proposed approach to make it more general. I think this is a direct fit for the use case Niels proposes here.

          At most one rule per AA/IdP:

           "Attribute Authority X.com may assert attributes on behalf of EntityId: http://neurogastro.institute

           

  3. MICHAEL R GETTES

    I too am not appreciating the need for scoping this attribute since the attribute, by nature being a URN is easily scoped with a little bit of effort on the front side of the URN.  The same little bit of effort involved in adding on @domain.  I believe scoping is redundant in addition to Scott's arguments.  I'd also add I never thought ePE should have been case sensitive and, should this attribute gain any steam even in the face of these concerns, I think it should be case insensitive.

    1. Keith Hazelton

      Don't think of it as scoping. It's just a plain old URI in my proposal.