...
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
Trust models and workflows
Federated access has been one of the goals from the beginning of the EUDAT project. EUDAT infrastructure is designing a new service called B2ACCESS to enable the integration of federated IdP with the EUDAT services. The use cases for this service are:
- Integrating new IdPs and enabling SSO for the users using credentials they already own
- Providing an EUDAT unique identifier for the users
- Providing additional attributes associated to the user identity
- Providing catch-all IdP for homeless users
This solution may support also non federated IdPs, nevertheless it would benefit from federated identity management relying on the LoA and the other best practices implemented in a federation.
As technical solution for B2ACCESS EUDAT is deploying unity-idm.
The level of information available is different in each of the communities and needs to be tackled case by case as more and more communities join the EUDAT infrastructure.
In general the EUDAT experience with AAI solutions is good both in terms of usability and quality delivered. The technologies currently enabled in EUDAT are X509 certificates, SAML2 and OpenID Connect/OAuth2
B2ACCESS is not yet integrated in eduGAIN, but this is high in the list of priorities, currently it is under testing with an handful of IdPs and users.
Adopted Authentication & Authorisation Technologies
The EUDAT infrastructure is implementing an AAI solution called B2ACCESS which bridges various AAI technologies used by the communities with the various technologies used by the service providers within the infrastructure. Users of the infrastructure must be able to use their home organisations’ IdPs to log in to the EUDAT infrastructure, as well as IdPs run by the user communities (e.g. CLARIN) and, when applicable, social media (e.g. Google). The user’s EUDAT identity contains attributes provided by the “home” (external) IdP, supplemented with attributes maintained by B2ACESS itself (the proxy scenario) - so every internal identity can present, for example, an email attribute. Finally, EUDAT itself can also provide a “homeless” IdP by having users authenticate using username/password.
As EUDAT runs a lot of different services internally, SPs are offered different technologies for integration with B2ACCESS. Based on work originally done in the Contrail project and carried forward by the first EUDAT project, services can choose to use SAML (using the WebSSO profile), OAuth2 (RFC 6749), or X.509 certificates. In a simple scenario, a service will use OAuth for simple access and authorisation; a more complex scenario would use SAML to authenticate and pass authorisation decisions to an XACML infrastructure. In the most elaborate scenario, users would authenticate to a (community or EUDAT) portal using SAML WebSSO (which in turn redirects to the “home” IdP); then the portal obtains an OAuth access token to grant further rights, including the right to obtain a certificate on behalf of the user from a web services certification authority (internal to B2ACCESS) - it then generates the keys and obtains the certificate which includes authorisation attributes. This scenario provides extra security compared to many of the traditional portals as the issuance of the certificate requires additional authorisation (the portal has to be registered as an OAuth client and needs to be authorised to obtain a particular user’s certificate); the management of such authorisations can be predefined administratively or by the user and can be audited subsequently. Power users can download the certificate and use it to drive non-web services from the command line, e.g. B2SAFE and data transfers. Despite its complexity, this approach offers a high degree of flexibility of integration of the many different components that comprise an EUDAT infrastructure, and many services will choose to use only the least complicated AAI mechanisms depending on their security requirements.
Penetration of federated identity management
EUDAT expects eduGAIN to cover most of the user base of the infrastructure. The B2ACCESS service will enable connection with other IdPs or federations upon request of the users. EUDAT is developing training material for the infrastructure services, including B2ACCESS.
Authentication and authorization technologies
For a multidisciplinary infrastructure as EUDAT it is important to keep open the possibilities for the users to choose the IdP of their preference, this includes institutional IdPs, both federated in national federations and non federated, catch-all IdP provided bu the research communities, and social IdP. The LoA associated to them is also important.
Within the EUDAT infrastructure many services are offered and each service has it’s own needs with respect to authentication technologies. Currently EUDAT is supporting X.509, SAML and OAuth2. Some services are web based but others are not. In this case the infrastructure is currently using X.509 based solutions. Moreover, EUDAT aims for a single sign on experience but given the complexity of the infrastructure this is not always possible.
Attribute release policies
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.
LoA management
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
Attribute management and community managed authorization
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.
Italian libraries (Summary of answers gathered among Italian libraries)
We are a university library. Our use case is typical for any university library in Italy. Our community uses AAI to access the electronic resources we subscribed, to access the personal area of the opac and of the university website, to use wi-fi.
In detail we use AAI:
- In our Discovery Tool (primo-ExLibris) to access research papers and electronic resources, display and download full-text from e-journals and e-books, discovery tool e-shelf. To search directly databases or a electronic journals.
- OPAC services: access to users' personal area, book reservations, loans renewal; interlibrary loan and document delivery requests using the university online forms or SFX form. Access the digital library of SebinaYou (Data Managment).
- Online services of the library: photocopying, scanning of documents, printing .
- Institutional repository: documents loading in the Institutional Repository (ARCA-Iris Cineca); Loading of doctoral thesis in the institutional repository of theses (D-Space).
We need to find a solution with ExLibris to access Primo and our resources from the discovery tool interface using AAI.
What is the current experience with AAI of your community?
Has your community/research infrastructure already uses AAI solutions for their use case? YES
What benefits do you see for Federated Access?
It simplifies the way of accessing ER, OPAC personal area and other library services such us photocopies, scanner and print.
It permits to check the rights of the users because it allows different users' categories to access only the services which they are allowed to use. AAI would permit also to create access for walk-in users but we are not using it at the moment. Moreover with AAI libraries could get more reliable ER usage statistics independent from publishers.
What barriers do you see in joining a federation?
- Lack of technical knowledge
- It is unclear how to organise an Identity Management (IdM)
- It is unclear if the IdM should be internally or externally done
- There is no clarity in the organization about the benefits of using an IdM
- We already have an IdM but it is not completely compatible with SAML/OpenID or other industry-standards
- Too much bureaucracy to join a federation
- Other : There are still a lot of publishers who are not members of the federation and for libraries it seems important to provide users with a unique way of accessing electronic resources.
As it concerns other libraries (public libraries) we think that the main barriers would be:
- The Management doesn’t consider that important
- No enough funds/resources (human resources)
What is the user experience in the interaction with the available AAI solutions?
- Expectations fulfillment
- User friendliness
- Quality of service delivered by the tools
Do you think that your organization is lacking in information about federated identity management?
Yes, it lacks communication and coordination among the different actors (libraries, IT staff, IDEM) that are involved. It lacks cooperation between the federation IDEM and CRUI-CARE (Conference of Italian University Rectors, the association of the Italian state and private universities and CARE is the section which deals with electronic resources contracts), which signs the national contracts with publishers. CRUI-CARE should ask publishers to include in the contracts the technical information about IdPs in order to implement Shibboleth authentication.
It would be interesting to know if in other European countries there are associations like CRUI-CARE and how they deal with national contracts and AAI
What material do you need to inform your organization about federated access?
It would be useful to present online guides and tutorials in the webpages where the users access ER and need instructions. Tutorial should be easy and user-friendly
Do you see the need for trainings to better inform representatives of members in your research area?
Yes, we do.
If your organization isn’t part of a federation yet, what can be helpful in order to join one?
For example:
- More informative material for management and decision makers
- Technical personnel dedicated to IdM
- Guides and trainings on how to implement an IdM and an Identity Provider
- Something ready that can be already used (like Virtual Machines)
- More resources
- External technical support
- A simpler procedure to follow for joining
What are the technical solutions adopted? Can you describe the solutions you have adopted highlighting as applicable?
Technology or technologies adopted:
- X509
- SAML2
- OpenID Connect/OAuth2
- OpenID
- Kerberos
Identity Providers (IdP) federations integrated (e.g. eduGAIN) or:
- Approximate number of individual IdPs integrated =1
- Approximate number of users =190.000
Solution for homeless users (users without a federated insitutional IdP). How do you manage guest users in your organization?
We manage guest users in two ways:
- A guest user can be introduces from a member of the staff (teacher / libraries or other university staff) filling a form in their personal area. The guest user gets a temporary account (7; 30; 90-days account- renewable). The person who introduces the guest is responsible for him/her.
- During an event (lasting from a day to a week), the event organizer may enable participants to request via a text-message or via a link with the registration form a temporary account.
Both methods enable the use of WI-FI and to access their persona area and they can set the proxy or VPN to access electronic resources.
There are also Eduroam guests accessing the WI-FI and may, in some cases, set the Proxy or VPN.
Solutions to handle user attributes
We use eduPersonScopedAffiliation with the value assigned from looking different databases (teachers, students, staff ...) according to the rules of eduPerson
Which IdPs your users would use?
Their institutional IdP, part of national federations and eduGAIN.
Non federated institutional IdPs
Research community catch-all IdP
Social media, at the moment is not used, but it would be useful for guest users of university libraries: facebook credentials would be accepted if certified by one or more institutional users. As for public libraries Facebook credentials could be certified by other registered users.
What are the requirements for the authentication technologies to be used in your use cases?
- User friendliness, single sign on (SSO)
- Web browser and non-browser applications support
- Support multiple technologies and credential translation services (e.g. SAML -> X509 translation)
- Support for delegation (e.g. execute complex workflows on behalf of the user)
Could your community benefit from Scalable IdP attribute release policies? In your use case, do you foresee the need to get attributes (e.g. institution, email address, name,…) from the IdP of the user? If the users will use many different IdPs, coming from different institutions, the service providers supporting the community need to access these attributes, therefore there is need for a set of policies that make scalable the negotiation between SPs and IdPs.
No.
Do you foresee for your use cases the need to have a persistent identifier to be associated to user’s identity? Supporting a persistent identifier allows the users to more easily change IdP preserving their identity.
Not at the moment, maybe in the future. For libraries it would be very interesting to implement ORCID (identifiers for researchers).
Is the support for different level of assurance relevant for your use cases?
Different LoA, allow users to use credentials with different level of assurance, and communicate properly the information to the service providers about the LoA of the used credential.
If yes, whom can we contact to ask further questions on your LoA needs? There is a dedicated task in AARC that investigates LoA.
YES, for the main university services. Libraries do not need it, they need only a level 1.
Does your community need community level authorization?
Authorization is separated from authentication and it is 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.
At present community level authorization is not used. Publishers recognize only eduPersonScopedAffiliation. A group-based attribute would be useful for libraries to allow remote access for ER which are accessible only for a restrict number of users that until now are identified according to a limited IP range (for example electronic resources which can be accessed only from one library PC).
How is the current coverage of IdP federations?Are the current identity federations (e.g. IGTF or eduGAIN) covering enough identity providers/institutions to be a feasible option for your users? What are the use cases where the coverage is not sufficient to reach all the involved users?
At the moment our federation covers part of the Italian Universities (federated). Some universities, companies, visitors, citizens are not included.