...
Community based attributes can also be relevant for the education community, for example to implement a more flexible authorization than the ip-based access to services. A unique persistent identifier associated to the user credential information is also considered important.
User stories
DARIAH
The following are the different possible workflows/user stories that are relevant to the DARIAH use case:
- DARIAH homeless user accessing DARIAH services.
This is likely the most common use case identified for the DARIAH community. DARIAH SP get the authentication information from the DARIAH IdP where the homeless users must register to use DARIAH. The DARIAH-IDP releases the user attributes and the authorization (community) attributes directly to the SP. From a user perspective the service provider and the IdP components are seen as homogeneous without separation.
- DARIAH homeless user accessing Federation and interfederation resources
This use case extends the previous one, DARIAH users should be able to access services provided to the DARIAH communities by external providers, by using the DARIAH-IDP. The DARIAH users will be able to browse and find the DARIAH-IDP in the service discovery service offered by national federation. In a similar way homeless users should be able to access inter-federation services supporting the DARIAH community as well.
- Federation users accessing DARIAH resources
Users wishing to access DARIAH resources using their institutional IdP, which should release at least one identifying attribute. DARIAH SP retrieves the missing attributes, not released from the IdP of the user, and the community attributes from the DARIAH IDP, which is filled by the users during their first connection. Community attributes are assigned to the user beforehand.
EGI
The currently most common use case for EGI is users accessing resources. Resources can be computational, storage, or virtualized resources, and the user can access directly through the APIs of the services exposing the resources, or through science gateways and portals.
Use case: user wants to access EGI resources through a science gateway using their federated credentials.
- The user access a portal with their institutional credentials.
- The portal gets the attributes released from the identity provider of the user.
- EGI or community attribute authorities provide the other attributes to complete the identity attributes, the community attributes must confirm that the user is a member of a VO supported by the resources exposed through the portal. User must also be associated to an UID which can be shared across services to track user activities.
- The user selects the resources they want to use and the actions that they want to perform.
- The portal assess if the LoA provided by the IdP suffices to the security level requested by the actions and the resources requested.
- The user tasks can act on behalf of the user, for example output data can be stored on resources of another service provider, and be associated to the user UID.
- The user tasks generate accounting data that is associated to the user persistent identifier.
- User can access EGI accounting infrastructure and retrieve their accounting data, or the accounting data of the community they manage.
Use case: user wants to access resources through command-line interfaces.
- User is registered in a virtual organization, that means the user is registered in the attribute management service that manages the VO membership, possibly with their institutional credentials.
- To perform the planned tasks the user connects to a credential translation service, where the attribute identity, the LoA and attributes are translated in an authorization token using a technology compatible with command line use.
- User connects to the service resources using the authorization token received in the previous step
- The service assess if the user attributes are fulfilling the requirements for the use of the resources requested, and if the LoA of the original credential is fulfilling the security requirements of the service
- Continues as in point 6 Of the previous use case.
EPOS
EPOS users, the researchers, need to access earth observation data that is stored in a distributed network of repositories.
- The researcher connects to the EPOS central services to discover relevant data for their research
- The use of institutional credentials is preferred but not mandatory
- The central services find the data requested by the user and contact on behalf of the user the data repository to retrieve the data
- The user analyses the data on the tools provided by the EPOS central services, and downloads the outputs
The access to the original dataset must be accountable to the user.