Attribute Release Policy
When, they will be informed of the attributes your service requests. The IdP 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 the Service Provider, containing:
- user identifier (NameID)
additional attributes (optional)
The 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 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.
A schema is an abstract representation of an object's characteristics and relationship to other objects.
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.