Attribute Release Policy
When a user logs in to a service provider, SURFconext sends a SAML assertion to this service provider. The assertion contains:
- statements about the user who is logging in (user identifiers)
- additional attributes
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:persistentA 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:transientA 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:oidschema (SAML2.0 compliant)
urnschema (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.