EMI AAI Use-Cases

The following use-cases are currently discussed with the AAI WG:

Use-Case 1: User obtains a X.509 certificate based on an AAI credential

A user has an account in an AAI and wants to access Grid services. For this he needs an X.509 certificate from which he can generate a proxy.

• 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 gLie SLCS could be adapted. The Terena Certificate Service provides this functionality - but I have no information whether and how the software is being distributed.

Comments:

• HM: If the generation of a proxy is already mentioned here, should the use case also contain how the AAI users are registered to the VO? CW: added use-case 7.
• HM: SLCS: The SLCS service builds the X.509 DN from the AAI attributes according to its configuration. However, in my opinion we need this "logic" in some other use cases too: see for example use case 4 in this mail. CW: yes - this functionality may be relevant in several use-cases.
• HM: How would the portals link an X.509 user to an AAI user (same user, but eg. different browser) otherwise? Or do they have to link them? Or should the portals just support one type of token (or method), and ask service like STS to translate another types to a desired one? CW: In my view the AAI attributes must be used.
• HM: The implementation used by TCS seems to be: 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.

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

This is basically the same use-case as 1 but in this case the user has a set of credential in non-AAI domain (e.g. kerberos) or simply a username/password (e.g. taken from ldap) (use-case mentioned by Krysztof).

Comments:

• CW: The EMI proposal specifically mentions obtaining X.509 based on token from Shibboleth-based AAI federations and Kerberos.

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

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.

Comments:

• HM: Should the use case mention credential stores (like MyProxy), optionally (or not?) in between the portal and the service that issues the certificate? Some users may prefer delegating a proxy to the portal from such a store instead of giving access to the private key corresponding to the "real" certificate. CW: yes - see below
• CW: The portal may obtain a SAML assertion targeted at another service which then issues the certificate.The portal should generate the private key. 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.

Use-Case 4: 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. In theory, all these portals could be AAI-enabled, the question for which (if any) this makes sense.

Comments:

• HM: To not require client X.509 in the browsers would clearly make the services easier to access from wider scale of devices, "public" computers etc. This would also offer pseudonymity features automatically, of course depending on the attribute set that AAI provides about the users

Use-Case 5: 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

Comments:

• CW: This needs to be specified in more detail (e.g. for which grid services this could be useful).

Use-Case 6: 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)

Motivation: the matrix of VO vs employing institution provides interesting information on the usage of the Grid, e.g. NGIs can gain information which ones of their constituencies are using the Grid (e.g. for accounting and charging). However, many of the AAI attributes are probably of little value for the Grid.

Use-Case 7: 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.

-- ChristophWitzig - 14-Feb-2011