By connecting your service to SURFconext, the institutions connected to SURFconext will take care of authenticating your users. After the user has successfully authenticated at his institution, SURFconext delivers a message to your service which states that the user is successfully authenticated. So what's next?

Introduction: attributes, claims and privacy

Besides knowing that a user is successfully authenticated, your service might need to know additional things about the user, such as whether the user is a student or employee. The Identity Providers connected to SURFconext can provide your service with this information, in the form of attributes. (If your service uses OpenID Connect, you might only know the term claims; this term is interchangeable with attributes.)

SURFconext, in line with the forthcoming European General Data Protection Regulation (GDPR), assumes a minimum disclosure principle. In short, this means a service should only maintain (personal) information that is strictly necessary for providing the service.

In practice, this means you are only allowed by law to receive those user attributes that you strictly need for providing the service. For instance, if your service allows users to share files with each other and sends out notifications to users when a new file is shared, you can use the user's email address attribute. However, if you only use the user's email address for marketing purposes, you might want to reconsider whether this fits the requirements of the GDPR. Because of this, SURFconext requires each Service Provider to specify which attributes are needed and why during the registration process.

It is therefore highly recommended that you carefully think about the attributes your Service Provider needs early in the process of connecting your service to SURFconext. The remainder of this page provides some guidance on most used attributes within SURFconext.

Identifiers

First of all, think about whether your service really needs to identify one user from another. If not, SURFconext provides a very privacy-friendly identifier, the transient NameID. This is an opaque identifier generated by SURFconext -  it is impossible to see who is behind it. It also changes every time the user re-authenticates - as a Service Provider, you are therefore unable to see whether it is the same user logging in, or someone else.

If you need additional functionality, such as knowing whether it is the same user again or which identifier is associated with the user has at his institution, other options are available. Please refer to this page with additional information on identifiers.

Names and email addresses

Your service might also need a way for other users to be able to see who is who, for instance when users are able to collaborate with each other through your service. In such a case, you might need attributes like name and email address. SURFconext offers several options for such attributes; please refer to the technical attributes page to see which you can use.

Institution

In some cases, your service does not necessarily need to know who the user is, only which institution the user comes from. Your service might need to be able to discern between users from the University of Harderwijk and the Applied University of Monnickendam. In this case, it could be argued your service needs an attribute that contains exactly this information, such as schacHomeOrganization. Please refer to the technical attributes page for more information about this attribute.

Other attributes

Another attribute that can be used to discern between differents types of users without necessarily knowing the exact identity of the user, is using the eduPersonAffiliation attribute. This attribute indicates whether the user logging in is a student, employee, faculty, prestudent and/or affiliate. Please refer to the technical attributes page for more information about this attribute.

Sometimes the Identity Provider is in charge of managing authorisations, e.g. which user or group is entitled to which roles and rights within a Service Provider. A very handy attribute for managing this is the eduPersonEntitlement attribute. Please refer to the technical attributes page for more information about this attribute.

For services specifically aimed at researchers, it might be necessary to use the eduPersonOrcid attribute. Please refer to the technical attributes page for more information about this attribute.