This page will list all the SAML2 attributes that SURFconext and their Identity Providers have to offer. An attribute is a characteristic that describes a user. It is a 'name:value' pair. The attributes included in the SAML assertion correspond to certain attributes a service provider needs to work properly. In general they are needed to: - Convey user information from the Identity provider or IdP to the service provider
- Create an account for the user at the service provider
- Authorize specific services at the service provider
Now, when a user logs in to a Service Provider, SURFconext sends a SAML assertion to the Service Provider via the browser of the user, that contains a:
Info |
---|
Before you start digging into the theoretical stuff on this page, you might want to start with our 'best practice' page for an introduction to and how attributes are best used. |
User identifiersThe user's identity is transmitted in the form of the NameID element. Every IdP must supply a NameID, but for privacy reasons SURFconext will generate a new one, which is duplicated in the attribute eduPersonTargetedID. To identify a user the Service Provider must use the NameID or eduPersonTargetedID. The NameID is guaranteed to be stable for a fixed user, except in the case of transient identifiers. SURFconext will generate a NameID for each new user. It is unique for the user and specific to the SP, so SP's cannot correlate their received NameID's between each other. There are two types of NameIDs: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
A persistent NameID contains a unique string identifying the user for this SP and is persisting over multiple sessions.urn:oasis:names:tc:SAML:2.0:nameid-format:transient
A transient NameID contains a unique string identifying the user for this SP during the session. If the user logs in again, a new transient identifier will be generated.
Warning |
---|
| The NameID and eduPersonTargetedID, which is basically a copy of the NameID, is unlikely to change and very privacy aware but can change when service providers or identity provider make critical changes . This can cause user profiles for services to be lost. The NameID, as used in the SAML assertion to a service provider when loggin' on, is generated using the uid, schacHomeOrganization, the Entity ID of the service provider together with a secret that uses a SHA algorithm. Institutions or services that are in production and change one of these attributes, will cause a new NameID and eduPersonTargetedID to be generated by SURFconext when doing so. This can cause loss of access to profiles at services. We will notify identity providers and service providers when we see a change in one of these attributes to prevent user data being lost. |
Useful linksIf you have an account at an institution you can get information about attributes shared with SURFconext by visiting our profile page. This page gives you insight in which personal data, provided by your institution via SURFconext, has been forwarded to which service and what they look like. For new IdP's or for IdP's that upgrade their environment, system administrators will at some point be asked to share the metadata of their account for analyses. When asked, visit this page and click the 'Mail to SURFconext' button. We will get back to you when we have judged the submitted metadata.This page will also show you the attributes shared and their values. Attribute schemasA schema is an abstract representation of an object's characteristics and relationship to other objects. SURFconext supports two attribute schemas: urn:oid schema (SAML2.0 compliant) urn schema (SAML1.1 compliant)
Both can be used to convey the same information (except for the NameID, which is only available in the urn:oid schema). By default SURFconext will provide attributes in both schemas as part of the assertion. However it is not recommended to mix the use of the schemas. Attribute overviewSURFconext supported relaying of the following attributes: |