...
Currently the coverage and the features of the national and European IdP federation are not entirely fulfilling the needs of the education sector. Besides the campuses not yet federated there are other categories of users who would be left out anyway: for example the high school students not yet registered in a university but who need to access some tools, and the citizen users in the university library.
...
Requirements: Attribute release policies
When service providers and user communities have the need to get attributes (e.g. institution, email address, name,…) from the IdP of the user, the bureaucracy involved can be an unacceptable overhead. If the users use many different IdPs, coming from different institutions, the service providers supporting the community need to access these attributes, therefore there could be need for a set of policies that make scalable the negotiation between SPs and IdPs.
BioVel
BioVel will very likely make use of the attributes released from the IdP, if available, and the community would benefit from scalable processes and policies between IdPs and SPs.
DARIAH
DARIAH users will use either homeless IdP or one and only one campus IdP, with authorization and additional attributes provided by the VO via SAML attribute queries.
Having campus IdPs releasing ePPN is critical for DARIAH AAI. The community hasbeen working with a number of initiatives (notably CoCo) to improve the current situation. Thus more efforts should be made to scalably a) increase the number of such IdPs and b) find some way for to know whether a given IdP will release ePPN to DARIAH services (e.g. by respective entity categories of IdPs), still before the first user is affected and perhaps disappointed.
As an attempt to solve the, DARIAH decided that a) SPs must express eduPersonPrincipalName as required (via SAML metadata) and b) users' campus IdPs should honor this If not user will have to aplly for An DARIAH homeless account.
PSNC
The release of the attributes has not been an issue based on the PSNC experience.
Photon and Neutron
Not relevant for the use case.
EGI
EGI is a highly distributed infrastructure, whith hundreds of service providers, hundreds of communities, and tens of thousands users. In this scenario is critical that the policies and the procedures are scalable with the number of actors involved.
Attributes are important to reduce the effort for user management on the communities or the service providers. If trusted IDPs can release easily information to the service providers, the credentials can be used to access the most complex workflows in the infrastructure without the need of additional vetting of the user identity.
But even in a scenario where the IdP releases a minimal set of attributes, policies must scale. For example services must be able to store and to share with other services the unique identifier of the user provided by the IdP.
Service provider federations should be seen by the IdPs as trusted entities, once policies are agreed with the federation should be valid for all the service providers within the federation.
EUDAT
The more information that is provided by the user’s IdP, the more streamlined the process of creating the users identity in the EUDAT infrastructure will be. If the users IdP is not providing enough of the required attributes, we will prompt the user to provide these. Currently EUDAT aims to a minimum set of attributes a name and email address.
D4Science
Yes, the infrastructure would benefit from a simpler way to access attributes released from the IdPs.
CLARIN
The CLARIN use cases would benefit by scalable policies for attribute release, this is one of the main issue while integrating new IdP with the research infrastructure. One example of actions towards this direction is the GEANT Data Protection Code of Conduct, which is a requirement to become a CLARIN B centre.
Education
Having scalable policies for attribute release is relevant for the community.
Requirements: LoA management
An AAI infrastructure that manages different Level of Assurance (LoA), allow users to use credentials with from sources that provide different level of assurance, and communicate properly the information about the assurance to the service providers.
With this information service providers, but also the user communities themselves, can decide which tasks the user can perform and which services can be accessed by users with the credentials used.
Requiring that all the user credentials have the same LoA regardless of the actions that are performed adds unnecessary overhead, and can discourage new users.
One example of this is that to upload big amount of data, and to use resources, users should be strongly authenticated, while to read open data the lower LoA is enough.
BioVel
At the moment the community has no clear use cases for a differentiated level of assurance, but there are two potential uses for it: enable limited access to citizen science services, with social accounts, and restrict access to other services only for very high assurance credentials.
These use cases have not been formalized yet within the community, but it is a key issue how institutionally affiliated users can be made able to authenticate using a non-institutional mechanism (i.e., FB, Google, etc.) in the same way that some users opt to use a non-institutional email address.
DARIAH
DARIAH services are used for research and educational purposes only.
Therefore users are classified as : belonging to some research institution (access via eduGAIN qualifies for this, or an institutional e-mail address), or so-called citizen researchers.
Accounts that fall into the latter category are checked manually, i.e. mail communication to make sure that user is involved in research. Any institution that is not yet known (mail domains are stored) is checked manually as well, in order to be sorted into one of the two categories.
After this manual check there is no need for further information about differentiated LoA.
PSNC
No need for LOA management is needed for the moment, but there are potential use cases for this that are foreseen for the future.
Photon and Neutron
LoA management is relevant for the Umbrella use case.
CLARIN
For CLARIN LoA management is relevant Yes, LoA is highly relevant: We would like to be able to trace users back to real persons and also have reliable user data to determine the user’s status (for example if they are students or staff).
EGI
EGI supports a very diverse set of use cases. Open data is a typical use case where a very large community of users can access a data set, but there is need for a lightweight authentication to account – for example – the number of connections to a service. In this example EGI needs to enable users without the need for ‘expensive’ high assurance credentials.
Clearly service providers must be able to extract information about the LoA from the attributes associated to the user identity. LoA definitions should be standard and simple, not to over-complicate the service provider decision to allow, or not allow, the user task.
EUDAT
The level of assurance assigned to the user credential is a very important attribute for the EUDAT use cases. EUDAT plans to be as open as possible in terms of the types of credentials accepted, and good practices in the management of LoA would be beneficial for the future development of B2ACCESS.
FIM
Service provider will ultimately decide on supporting low level of assurance identities, what SPs need is to get the information about the LoA in a reliable and standard way.
Requirements: Attribute management and community managed authorization
Authorization is separated from authentication and in many cases it should be controlled by the community. To implement this community-driven authorization user communities must manage a set of attributes associated to the users, which need to be provided to the service providers together with the identity attributes provided by the IdP.
BioVel
Community level authorizations are surely needed but the main obstacle is to integrate the community specific attributes with the institutional IdPs attributes. The trend for many communities is now to set up community IdPs. BioVel community would prefer to have a generic infrastructure to handle community attributes, rather than deploying their own system.
DARIAH
The only user identifier used is ePPN, DARIAH connects user’s ePPNs and accounts together in the DARIAH portal.
The homeless IdP delivers via SAML attribute queries keyed by the ePPN the following attributes:
- any needed personal attributes the campus IdP did not provide, e.g. mail
- the accepted terms of use for the service in question
- authorization attributes, i.e. the names of the authorization groups the user is member of
Authorization group membership is managed manually via the administration portal in a distributed way, i.e. by the administrators of DARIAH countries, organizations, and projects.
DARIAH is therefore using community attributes to authorize access to internal services and potentially to all the services supporting the community.
PSNC
Persistent identifiers are not needed for the moment, while community based authorization is foreseen to become more important in the future, and therefore PSNC is interested in supporting it.
Photon and Neutron
The community has already an unique identifier for the users. This is provided by the Umbrella infrastructure, since this has been a very important requirement for the community use case from the beginning.
Authorization based on community attributes is less relevant for the photon and neutron use case, since the authorization is entirely regulated by the service providers who enable users to access their services.
EGI
EGI infrastructure is already consuming community-provided information for the authorization of users on the services. Currently the services that allow research communities to manage their attributes are based on X509 certificates. It is critical that integrating with multiple authentication technologies, EGI services are able to both consume attributes from the attributes management services already in use by the communities and offer to the users tools that can be used with their institutional credentials.
Community attributes are also important to integrate the missing information not provided by the IdPs.
The attributes associated with the user identity are not only used to authorize access to the resources (cloud, storage or HTC), but also to identify the user’s role in the community, and authorize privileged access to the Operational Tools.
EGI foresees the need for a user unique and persistent identifier. One use case is to map multiple credentials to a single user. A second use case, and in particular for an EGI-specific unique identifier is to share between EGI services authorization assertions which may not be possible when using an IDP-provided user UID.
EUDAT
B2ACCESS will consume the attributes provided by the IdPs, and integrate with additional attributes where needed during the user registration process. B2ACCESS will in fact act as an attribute provider as well.
Given the distributed and heterogeneous nature of the EUDAT infrastructure, a persistent identifier for the user is really important. This is exactly the reason why EUDAT is mapping the users community identity to an (internal) EUDAT identity, since at the moment the infrastructure cannot rely on proper persistent identifiers in available from third parties. Even with this approach it is possible that the same user might get multiple EUDAT identities based on the used combination of IDP and SP and the attributes which are provided.
The use of community attributes for distribute authorization is a topic that has not been yet fully addressed by EUDAT but it is high in the agenda. For the EUDAT services the authorization management should remain on the communities.
D4Science
The Authorization Service is based on Attribute Based Access Control paradigm, where valid attributes depend on the caller:
- Roles are currently the only attribute associated to humans
- Several attributes are associated to services (that can act as clients in m2m communication) such as Service Class and Service Instance identifier.
These attributes are internally managed within D4Science and currently are not using community attributes, therefore the integration with external attribute authorities has a lower priority.
FMI
Persistent identifiers for the users is a feature needed in the FIM use cases, ORCID is a possibility, for example.
FIM uses an entitiy-attribute-value model to regulate authorization, customizable per user, community, group, organization, department etc. The community or the users decide on the attributes release policies, which are then used by the FMI service provder to authorize users.
FIM would benefit from better and scalable policies for attribute release from the IdPs.
CLARIN
Missing attributes not released by the IdPs are handled case-by-case. In the worst case via the homeless IdP. A dedicated project Attribute Authority is in testing.
The CLARIN Service Provider Federation solves the necessary coverage for our project, although even then limited attribute release or complex SP acceptance policies make IdP-SP interoperability difficult in some countries. In eduGAIN, countries with Opt-In are not well covered and are not sustainable in this respect. Moreover, 6 countries are behind > 1000 IdPs in eduGAIN (July, 2015) leaving ca 300 to the rest of the world, so it would be nice to see IdP coverage in eduGAIN improve.
Education
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.