EMI AAI Use-Cases

Use-Case 1: A User obtains a X.509 certificate based on a security token from another domain.

A user has an account in an AAI, federated or not, and wants to access Grid services. For this they need an X.509 certificate from which they can generate a proxy.

There are two different cases, depending on the lifetime of the certificate:

• X.509 is short-lived: This use-case is covered by the gLite SLCS service as well as others (?). Adaptions are needed depending on a) the AAI federation, b) CA being used.
• X.509 is long-lived: There is in our knowledge no package that fulfills this this X.509 issuance process out of the box. The gLite SLCS can be adapted. The Terena Certificate Service provides this functionality - but I have no information whether and how the software is being distributed.

Comments:

• The SLCS suffers from the fact, that there is no SOAP interaction with the identity provider but a user agent parses the HTML. This has to be adapted according to the login page of the identity provider - making the maintenance cumbersome in the long run.
• The CA has to decide how the DN is constructed in order to make the user mapping unique. In the SLCS case, this is done using the AAI attributes.
• The TCS implementation is: confusa . It is in PHP and it's using SimpleSAMLphp. The "main use case" for it seems to be browser-based, but it also somehow supports OAuth to authorize command-line clients.
• The EMI proposal specifically mentions obtaining X.509 based on token from Shibboleth-based AAI federations and Kerberos.
• To be compatible with the STS sequence to obtain X.509 from SAML token, the identity providers (identity providerss = home institutes) in the AAI should support SAML 2 ECP profile. The ECP-compatible client tool would be the messenger between the STS and the identity provider.

Use-Case 2: AAI-enabled portals to Grid infrastructures:

This use case, from the EMI point of view, is not a question of how "we" provide a portal.. (An existing example of this type of operation can be found in the P-Grade portal that uses SLCS to get a credential.)

A user accesses an AAI-enabled portal from which he submits grid jobs. The user is not aware that a certificate is obtained based on the SAML assertion from the AAI and this certificate is used to submit commands to the grid.

Note that the identity provider issues SAML assertions targeted to the portal as well as targeted to the CA, which issues the certificate.

Comments:

• It's a question what the portal does with the certificate after that - stores it somewhere else or manages itself. Alternatively, one can also imagine that the portal obtains proxies and the proxy issuing service manages the certificate.
• Some users may want to store the (proxy) certificate, e.g in MyProxy.
• In addition to the SAML 2.0 ECP profile (like in previous use case), the identity provider in the AAI must also support SAML delegation: the portal would obtain a SAML token that it can delegate to STS on behalf of the user. And finally the portal would obtain X.509 token from the STS.
• The project "Swiss Grid Portal" implemented this use-case using P-Grade.
• This use-case is considered important for the dissemination of Grids to user communities that have an AAI. However, portal technology is outside the scope of EMI.

Use-Case 3: AAI-enabled portal for displaying and accessing information about the Grid:

Today, there are many portals in the EGI infrastructure using portals (GOCDB, GGUS, ...) where a certificate in the browser is used for authorization. All these portals could be AAI-enabled.

Comments:

• This use-case allows users to access Grid information and management webpages using AAI credentials.
• The benefits of this use-case are limited as the audience of this use-case tends to be Grid power-users who to know certificates well.

Use-Case 4: A Grid service obtains a user-request from another security domain and based on the token obtains a X.509 certificate with which it communicates to other grid services

An example of this use-case could be usage of SAML assertion on a CE that subsequently needs to use X.509 credential to initiate GridFTP session(s).

This is considered the most general use-case for exchanging tokens (e.g. X.509, SAML, kerberos tickets) between different security domains. It requires a service, called security token service (STS), which acts as bridge between the two domains. Its design is described here [TODO].

Use-Case 5: Use of AAI attributes in Grid services:

AAIs typically authorize the user based on attributes. The question is to what extent are these attributes useful in Grid environment. Example of AAI attributes are:

• home organization (i.e. employing institution)
• affiliation (student, professor, postdoc)
• study branch, study level (physics, 5th semester)

Comments

• Motivation: the matrix of VO vs employing institution allows to obtain useful accounting information, such as usage of the infrastructure based on NGI affiliation. However, it can be assumed that the number of useful AAI attributes will be rather limited.
• The work-flow associated to this use-case should be written down. How to the attributes relate to the VOMS attribute (if at all)? How does a Grid service know that these attributes can be trusted? The eduperson schema "could" be required to be the base format for these AAI attribs for easy entry into the VOMS schema.
• The relevance of this use-case could potentially be very high (charging across the infrastructure to institutions, not VOs). However, we assume that this will not be the case in the near or mid-term future.

Use-Case 6: Registration in a VO

During the registration of the user in a VO, his identity must be vetted. This can be done through AAI. Optionally, a set of AAI attributes can also be involved in this process.

Comments

• The current VOs already have their mechanisms for VO user registration. They are likely to keep it. This use-case becomes only relevant if large user communities, which are already well-served by AAIs, start using the grid as new users.
• The registration work-flow should coordinated well with the VOMS/VOMRS mechanism.

Summary

The following table summarizes the use-cases:

-- JohnWhite - 28-Feb-2011, updated C.Witzig May 28, 2011