Attribute Release Policy
SURFconext has At the core, SURFconext is a service that handles attributes. You will need to get yourself acquainted with attributes as soon as you connect a service to SURFconext. An attribute is a characteristic that describes a user. There are quit a few attributes we can provide but we have a minimal disclosure principle: . This means only the absolute necessary (personal) information minimum amount of information needed to make your service work is transferred to a your service. When you request a connection to the Production environment, you must specify the attributes needed and motivate them to make us and users understand why you need them. SURFconext Support will review your request and configure an Attribute Release Policy accordingly. If we think you ask to much, we will discuss this with you.
| Info |
|---|
When Identity Providers are asked if they want to |
...
connect 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. |
Attributes
...
in
...
SURFconext
...
User identifiers
The user's identity is transmitted in the form of the NameID element of the SAML statement. Every Identity Provider must supply a NameID, but for privacy reasons SURFconext will generate a new one regardless. For convenience, this identifier is duplicated in the SAML attribute eduPersonTargetedID (see below).
Service Providers should use the NameID or eduPersonTargetedID (rather than email address, or other attributes that might change over time) to identify users. The NameId is guaranteed to be stable and never change for a fixed user (except in the case of transient identifiers, see below). It is generated for each new user by SURFconext and is based on a hash over the uid, schacHomeorganization (together a unique user accross the federation), the SP entityID and a secret. It is therefore both unique for that user and specific to the SP, so SP's cannot correlate their received NameID's between eachother.
SURFconext can provide NameIDs of 2 different types:
- 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.
Persistent and transient identifiers typically have the form 'bd09168cf0c2e675b2def0ade6f50b7d4bb4aaef'. However, please do not rely on the identifier being a hexadecimal string, as the syntax may change in the future.
The two supported NameID types, for respectively persistent and transient NameID specifiers, are:
urn:oasis:names:tc:SAML:2.0:nameid-format:persistenturn:oasis:names:tc:SAML:2.0:nameid-format:transient
Attribute schemas
SURFconext supports two attributes schemas:
- a (SAML2.0 compliant)
urn:oidschema and - a (SAML1.1) named
urnschema.
| Info |
|---|
The information below is a carbon copy of our Attributes in SURFconext page as found in the background part of our documentation of SURFconext. |
| Include Page | ||||
|---|---|---|---|---|
|
urn:oid schema). By default SURFconext will provide attributes in both schemata as part of the assertion. It is not recommended to mix the use of these schemata, but for legacy reason SURFconext offers both.