...
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