You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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: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
  • No labels