SURFconext has a minimal disclosure principle: only the absolute necessary (personal) information is transferred to a service. When you request a connection to the Production environment, you must specify the attributes needed. SURFconext Support will review your 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 IP must agree to the release of these attributes to your service.
When a user logs in to a service provider, SURFconext sends a SAML assertion to this service provider. The assertion contains:
The user's identity is transmitted in the form of the NameID element. Every IP 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 you must use NameID or eduPersonTargetedID. 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 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.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.