SURFconext operates with a minimal disclosure principle. This means that only the absolute necessary (personal) information is transferred to a service. When requesting a Connecting to SURFconext production environment, you need to specify the attributes you need from the above list. SURFconext Support will review your attribute request and configure an Attribute Release Policy accordingly.
When Identity Providers are asked if they want to be coupled to your service , they will be informed of the attributes your service requests. The Identity Provider must agree to the release of these attributes to your service. Identity Providers will be more inclined to allow a coupling with a service that only requests the necessary attributes instead of one that asks for all.
When a user logs in to a service provider, SURFconext sends a so-called SAML assertion to the service provider. This SAML assertion contains a number of statements about the user who is logging in to you service, including his identity, and possibly a number of additional attributes (see below).
On this page we will show you which attributes SURFconext and their Identity Providers have to offer.
The user's identity is transmitted in the form of the NameID element of the SAML statement. Every Identity Provider must supply a NameID, but for privacy reasons SURFconext will generate a new one regardless. For convenience, this identifier is duplicated in the SAML attribute eduPersonTargetedID (see below).
Service Providers should use the NameID or eduPersonTargetedID (rather than email address, or other attributes that might change over time) to identify users. The NameId is guaranteed to be stable and never change for a fixed user (except in the case of transient identifiers, see below). It is generated for each new user by SURFconext and is based on a hash over the uid, schacHomeorganization (together a unique user accross the federation), the SP entityID and a secret. It is therefore both unique for that user and specific to the SP, so SP's cannot correlate their received NameID's between eachother.
SURFconext can provide NameIDs of 2 different types:
Persistent and transient identifiers typically have the form 'bd09168cf0c2e675b2def0ade6f50b7d4bb4aaef
'. However, please do not rely on the identifier being a hexadecimal string, as the syntax may change in the future.
The two supported NameID types, for respectively persistent and transient NameID specifiers, are:
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
SURFconext supports two attributes schemas: a (SAML2.0 compliant) urn:oid
schema and a (SAML1.1) named urn
schema. Both of these 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 schemata as part of the assertion. It is not recommended to mix the use of these schemata, but for legacy reason SURFconext offers both.