It seems so easy: a single institution account that you can use to log in to a range of services. However, if a service requires more information than the institution account offers, you still need to supply additional information or establish a connection with another database. This is why a change will soon be made in the form of attribute aggregation in SURFconext!
If a user logs in to a service via SURFconext, attributes relating to this user (e.g. name, e-mail address and rights) are usually also transferred to this service. Until now, these attributes have been provided solely by the institution at which the user studies or works. There are also other resources available that have useful information about the user. To be able to disclose this information to a service simply and securely, SURFconext has been extended with attribute aggregation. Attribute aggregation enables a user’s identity to be enriched with information from sources other than from the specific institution itself. Group information or a researcher ID can, for example, therefore be made available to a service when logging in.
Why are we doing this?
Some services require more or different information about a user, such as the collaborative groups that the user is a member of or the user’s international researcher ID. Often, the institution is not able to provide this information itself via SURFconext. However, there are sources available that provide this user information via an interface. The service provider then needs to build interfaces along with a connection with SURFconext in order to retrieve this information. By providing centralised connections with commonly used interfaces and enabling the attributes obtained to be part of the login flow, service providers no longer need to build or maintain these connections themselves. They can now simply use the existing SURFconext connection instead. This leads to economies of scale, especially for external attributes used by multiple providers. In addition, SURFconext is able to ensure that these attributes are retrieved, shared and clearly displayed in a manner that protects privacy. This is often more difficult if the service provider needs to retrieve these attributes itself.
In addition to the direct practical benefits, it is a first step towards the institution no longer being the sole provider of identity information. For example, in the future, a user will be able to log in using a government ID, after which information stating that a student is studying at a specific university will be added to this identity using attribute aggregation.
Figure 1 Attributes from different sources (institution, ORCID and SURFconext groups) are forwarded to the service.
What solution do we provide?
We add new functionalities to SURFconext, the system that facilitates the login process to cloud services. In addition to the attributes of the home institution, a service can now be given the following attributes:
Group information from SURFconext Teams or institutions that have linked their group information system to SURFconext can be added to the login flow via attribute aggregation. This information is made available to the service with the minimum of effort. No additional VOOT connection with SURFconext is required in order to receive group information. Receiving group information as part of the SAML message is primarily intended for services that wish to use groups for authorisation purposes. Service providers must specify in advance which groups they need so that the size of the SAML messages remains under control. If a service wishes to receive all of a user’s groups or does not know beforehand which groups are required, then the service stills need to establish a VOOT connection.
ORCID ID for researchers
An ORCID ID can be requested by a researcher by visiting https://orcid.org/. Using this ID, a researcher can be uniquely and globally identified, for example to link publications or data to a researcher. It is also feasible that this ID will be used in order to apply for grants or facilities. As the researcher has to apply for the ORCID ID personally, this ID is often unknown within an institution’s identity management system. By adding ORCID to attribute aggregation, it is possible for SURFconext to disclose this ID to the service. As this is provided centrally via SURFconext’s attribute aggregation, the services do not need to individually establish a connection with the ORCID record. A user only needs to connect their ORCID ID to the institution ID once. Establishing this connection and (where applicable) directly requesting the ORCID ID is facilitated by SURFconext. If a researcher changes institution, they can simply connect their ORCID ID to their new institution account.
Figure 2 By using a URL (1) generated by SURFconext, a user can connect an existing or new ORCID ID to the ID provided by the institution (2). The user grants permission to ORCID (3) to share this ID with SURFconext.
A third option is to pass on authorisation roles assigned by SURFnet or the contact person for an institution. These attributes are assigned by the SURFnet authorisation management (SAB) application and are only to be used by services provided by SURF.
How far are we now?
Attribute aggregation service is at the service development stage. It is currently already possible to add SURFnet group information and authorisation roles to a user’s set of attributes. Service providers who wish to use this service can find out more on the SURFconext wiki.
It will be possible to connect and disclose the ORCID ID in the second half of 2017. We want to start adding more attribute providers in 2018. We are looking forward to collaborating with institutions, researchers and service providers on this, so please report your ideas!