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 be coupled connect to your service, they will be informed of the attributes your service requests. The IP IdP must agree to the release of these attributes to your service. |
...
Attributes
...
in
...
SURFconext
...
- user identifiers: information about the user who is logging in
- additional attributes (optional)
[ Attributen zeggen iets over een gebruiker (bijvoorbeeld dat het een student is, dat zijn voornaam 'teun' is, en dat ie studeert aan instelling X)
Ze hebben als doel de dienst te definiëren (bv. waar leeft de dienst) en te beschrijven (bv. hoe heet de dienst). Elementen zijn configureerbare variabelen van de SAML metadata.]
User identifiers
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: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
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
Note that not all identity providers might make all attributes available.
(1) eduPerson Object Class Specification (201602): http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html
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 | ||||
---|---|---|---|---|
|
...