Page History

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 possible possibly a number of additional attributes (see below).  More information about SAML can be found on this page.

User identifiers

 The The user's identity is transmitted in the form of the NameId element of the SAML statement.  SPs should use the NameId (rather than email address, or other attributes that might change over time) to identify users, as it .  The NameId is guaranteed to be stable and never change for a fixed user (except in the case of transient identifiers, see below).

...

• A persistent identifier.  A persistent NameId contains a random string that uniquely identifies the user for this SP, and which persists over multiple sessions for the same user.. 
• A transient identifier.  A transient NameId contain a random string that uniquely identifies the user for this SP during the session.  Once the user's session at SURFconext expires and the users logs into your service once more, a new transient identifier will be generated for the user and SP.
• A legacy identifier.  A legacy NameId contains a human-readable dentifier identifier of the form urn:collab:person:example.com:johndoe.  This form of the identifier is deprecated and is not available for newly connected services. The reason for this is that SURFconext aims at minimal disclosure of personal informationwants to have fine-grained control over the released attributes.  This is easier to manage if no personal information is disclosed in the NameId identifier. If the SP needs information that is contained in the legacy NameId format (for example, the user's home institution), they should use proper attributes (for example, schacHomeOrganisation, see below) as a source for this informaiton.

...

...