You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

By connecting your service to SURFconext, 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?

Attributes and privacy

Besides knowing that a user is successfully authenticated, your service might need to know additional things about the user, such as whether it is a student or employee. The Identity Providers connected to SURFconext can provide your service with this information, in the form of 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 to receive those user attributes that you 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 could receive the user's email address attribute. However, if you only use the user's email address for marketing purposes, you might not receive email address as an attribute. You must therefore also specify during the registration process for each attribute, why you need it and what you do with it.

Identifiers

First of all, you probably need to discern one user from another. The most privacy-friendly way to achieve this, is to use the transient NameID SURFconext can provide. 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 do really need additional functionality, such as not only knowing whether it is the same user again but also which identifier 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 schacHomeOrganizationPlease refer to the technical attributes page for more information about this attribute.

 

 

 

 

==== Oud ====

When your service has been connected to SURFconext, identification of users will happen through attributes (instead of username + password). Personal data of the user is always transferred, independently of what attributes are used. There is a difference in the sensitivity of the personal data that is exchanged per attribute. We encourage Service Providers to ask for a minimal set of attributes, and use privacy-friendly attributes, especially when it comes to user identifiers.

User identifiers are attributes that are able to uniquely identify a user, for example: NameID, Employee/Student-number, UID, PrincipalName and Email.

In order to help you in choosing the best attributes considering both usability and privacy, please ask yourself the following questions:

  • Is it necessary to know the name of the user?
  • Is it necessary to know if a user is a returning user?
  • Is it necessary to know the user’s contact information?
  • Is other information, apart from the SURFconext attributes, processed in the application?
  • No labels