Case Studies

When working with AAI, it is sometimes useful to study how other projects have solved the same problems. Here is a list of projects that are doing work or have done relevant work and some core case studies from these.

EUDAT and Contrail

EUDAT is a FP7 project building a distributed "collaborative data infrastructure" (CDI in EUDAT-speak). EUDAT supports very diverse user communities which each have different ways of authenticating users and authorising them (and different models for authorisation).

The principal goals of access are:

• Support AAI that communities already use, particularly if they already have (externally) federated AAI.
• Support web based access (portal) for "normal" users, but also command line access.
• There must be a single (EUDAT) federation identity.
• Users can belong to more than one community.
• Users should be able to get access without long registration processes.

Bulding on the outcome of the Contrail project before them (having evaluated about six different options), EUDAT is generating internal X.509 certificates based on users authenticating to the portal. Like Contrail, the certificate is "decorated" with extensions carrying authorisation attributes, and uses OAuth2 to delegate the right to an entity - such as the portal - to obtain a certificate on behalf of the user. EUDAT, however, chose to replace Contrail's identity selector with Unity, a spin off project from Unicore.

1. User goes to EUDAT portal (several options are available for integrating EUDAT portal with community portal).
2. Users select their means of authenticating.
3. Users authenticate, possibly via more WAYFs, as multi-federations have to be supported.
   1. After authenticating to their home instititute, users authenticate to the Unity identity manager.
   2. Unity looks up their single federation identity and authenticates the user to the OAuth authorisation server (because the latter needs to grant other things the right to obtain certificates on behalf of the users)
4. The portal obtains an access token from the authorisation server and uses it to get a certificate. (The portal generates the key pair and the CSR.)
5. The portal can now do Stuff(tm) on behalf of the user with the user's certificate.
6. The certificate and key are made available to download for users wishing to use command line tools.

The advantage of using OAuth over GSI delegation (RFC3820) is that there is a bit more control over the delegation. Indeed, Contrail implemented a pre-authorisation where users could select the OAuth clients they trust, plus a post-delegation visualisation of the delegations. However, EUDAT has not at present taken up this extension.

Authorisation is currently based on simple attributes held at the federation level: e.g. membership of groups, and roles. So it's either very coarse-grained (everyone in VO can do much the same, like the grid), or fine grained (identity based). More work is needed to meet all the use cases of the communities.

Contrail also implemented a LoA, assigned to each IdP by the federation: thus, the LoA of the users authentication was available to the SP. XACML was used for authorisation, with an extension to notify a PDP of a change in "volatile" attributes (such as reputation, or credits) which would lead to a reevaluation of access control decisions. These extensions have not (yet) been taken up by EUDAT.

Projects:

• http://eudat.eu/ (project ended Sep. 2014 but is currently on unfunded extension till Feb 2014).
• http://contrail-project.eu/ (project ended Jan. 2014)
• http://unity-idm.eu/

Code:

• https://bitbucket.org/eudataai/

Contacts:

• AAI: Jens Jensen, STFC
• Other: Mark van de Sanden, SurfSARA

The Grid

The grid is a global network of computing and storage resources, which, among other achievements, has managed to find evidence of Higgs bosons in data from the Large Hadron Collider. Authentication for the grid is global, based on a narrow band of levels of assurance.

Identities are X.509 certificates managed by the users. Recent relaxing of the rules have allowed keys to be managed on behalf of users using trusted key management services, eg based on MyProxy.

The Classic CA is typically as follows:

1. User requests a certificate from national CA. The user normally generates their own private key, typically in a browser.
2. User goes to a registration authority (RA) belonging to this CA, bringing approved photo id.
3. The RA checks the photo id and photocopies it,  checks that the request is from the user and the signature on the request is OK; then approves the request.
4. The CA signs the certificate. The certificate will contain a "reasonable representation" of the user's name.
5. User then requests membership of a VO by going to a VOMS interface and requesting their VO, their roles, and the approver within the VO (if there's a list of approvers, one may be more "local")
6. Once the membership has been approved, the user can now use the grid by extracting the key from the browser, generating GSI proxies and adding VOMS attribute certificates (RFC3281) to it.

The MICS CA is approximately the same except in steps 1-3, users make use of approved (usually national academic) identity management federations, or bilateral IdP/CA agreements.

Project: www.igtf.net

Contact: David Groep, NIKHEF