Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 31 Next »

Attribute Release Policy

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 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)

User identifiers

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: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.

Attribute schemas

A 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 overview

  • No labels