Table of Contents |
---|
Introduction
This page describes the steps This page will list all the SAML2 attributes that SURFconext and their Identity Providers have to offer. An attribute is a characteristic that describes a user. It is a 'name:value' pair. The attributes included in the SAML assertion correspond to certain attributes a service provider needs to go through in order to interface with SURFconext to externalize their user authentication. This is just the technical procedure. An introduction to SAML can be found on Wikipedia. The SAML profile supported by SURFconext is the Interoperable SAML 2.0 Web Browser SSO Deployment Profile.
This page will describe the relevant configuration for the service provider and how to request a connection.
To connect your service to SURFconext you need to do two things:
- Teach your service about SURFconext, i.e. configure relevant SURFconext configuration parameters in your software;
- Tell us about your service so we can configure it in SURFconext, i.e. provide a link to your service's metadata;
SAML
The authentication protocol used is SAML 2.0. This means that the service provider will trust SURFconext to authenticate users and provide (signed) data with user information to the service provider that can be trusted. In the remainder of this document, if we refer to 'SAML' we mean SAML 2.0.
If a user is successfully authenticated using SAML, you can get more information about the user by inspecting the attributes of the user. Most of the attributes are self-explanatory (such as the attributes givenName
and displayName
, but other attributes may need more explanation about their intended use cases. Please contact surfconext-beheer@surfnet.nl if you have questions about how to best use attributes.
How to configure SURFconext as my Identity Provider
SURFconext is a so called 'hub-and-spoke' federation. There is only one IdP for your SP to connect to. There are two ways to configure SURFconext as an Identity Provider to your service provider:
- Using metadata (RECOMMENDED)
- Manually
Using Metadata
The SAML metadata for the SURFconext IdP can be downloaded here. This will use SURFconext to provide "Where Are You From" functionality, i.e.: make the user select their home institution from the list of institutes that are allowed to access your service.
If you want to provide your own "WAYF", e.g. to "brand" the user interface or connect to multiple federations you can use the metadata containing all IdPs connected to SURFconext which can be found here. See section on IdP discovery for more information on this.
For other, specialized versions of the metadata look here.
Info |
---|
The same metadata can be used for connecting to both the Do-It-Yourself/ testing platform as well as to the production platform. |
Manual configuration
If there is no metadata import functionality available in the service provider's software, the SSO endpoint and certificate need to be configured manually:
SSO endpoint: https://engine.surfconext.nl/authentication/idp/single-sign-on
Certificate:
Code Block |
---|
-----BEGIN CERTIFICATE-----
MIIDyzCCArOgAwIBAgIJAMzixtXMUH1NMA0GCSqGSIb3DQEBBQUAMHwxCzAJBgNV
BAYTAk5MMRAwDgYDVQQIDAdVdHJlY2h0MRAwDgYDVQQHDAdVdHJlY2h0MRUwEwYD
VQQKDAxTVVJGbmV0IEIuVi4xEzARBgNVBAsMClNVUkZjb25leHQxHTAbBgNVBAMM
FGVuZ2luZS5zdXJmY29uZXh0Lm5sMB4XDTExMDEyNDEwMTg1N1oXDTIxMDEyMzEw
MTg1N1owfDELMAkGA1UEBhMCTkwxEDAOBgNVBAgMB1V0cmVjaHQxEDAOBgNVBAcM
B1V0cmVjaHQxFTATBgNVBAoMDFNVUkZuZXQgQi5WLjETMBEGA1UECwwKU1VSRmNv
bmV4dDEdMBsGA1UEAwwUZW5naW5lLnN1cmZjb25leHQubmwwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDMJ6v+f3owS3KR5IXSil+3XFwGvCVeYx3jDOFK
AnwvXlDpTu+t730b8/spHtlopyJVAlb6qBIPN7R4TGTLqiu0zebYsYx/PtqCk5cb
u9qs3h+p2BBoTXVwXA/ZYi0tqtxp04hcNrRj1TAgLyC0S+KASTF+zzccAcjTBid5
EMioo+YllgSEobWJ4X33XVRqNrikAPDsNmDrdKUi257JSO2xhVIG5lbtmDaL5ORC
D56oRmVdp7VQTEQ3Yass8J5Rn+Ub6WmRBYeG+KzFBvtyBput2o0/gvtJn9L+NWeD
B0LyUPaUYG/X4GF14FcmFQfz7I5jBCNHtPcLJbPYbZKQNhz/AgMBAAGjUDBOMB0G
A1UdDgQWBBS9QqP8gtMM6nm4oYzNbgqhEDP1aDAfBgNVHSMEGDAWgBS9QqP8gtMM
6nm4oYzNbgqhEDP1aDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQBH
2qyYwLwesIOxUTj+NJ0VXRBDH8VecNLiUUs9Np4x8A0pxLvlNnv5TdJAruEg1LSV
mAqqPUdAB2m7CKDeUVM9cwOB7vqelV2GNgOfevXi+DZRMffyyE8qyIcnTqvDOgcR
8qGTPSVT+SIsOkV9bYrjltrbnal7cJermsA8SC5w/pjLaOHI1xIZHquZzymWoN3Z
fz2CQg2r5o+AURYd74GrHhHqVa9VrdWtcimB+vTQQihoLt8YciehpJjOMpx2D66e
FfpC8ix31RRdjAVIo1y33h1yU3gEHePDbOthZE+lpXi2WJqO85H85LqJOtgn2WPI
3P2Tx32Cq1WXCYkxLaPI
-----END CERTIFICATE-----
|
You can also download the certificate file here:
The SSO endpoint is used by your SAML software to send an AuthnRequest to. The certificate is used to verify the SAML assertion sent to your ACS (see below).
If your software only needs the certificate fingerprint, like for example in simpleSAMLphp, you also use the fingerprint of the certificate instead:
Code Block |
---|
$ openssl x509 -inform PEM -in SURFconext.pem -noout -fingerprint
SHA1 Fingerprint=A3:6A:AC:83:B9:A5:52:B3:DC:72:4B:FC:0D:7B:BA:62:83:AF:5F:8E
|
How to tell SURFconext about your service
In order for us to configure your server we would like to receive your metadata URL. That way we can easily configure your service and you'll be able to update the metadata without telling us about any changes. If you cannot provide a link to metadata containing the information below we at least we need to have the following information:
- Service Entity ID;
- Assertion Consuming Service URL, accepting HTTP POSTs over HTTPS with a trusted and valid SSL certificate;
- Technical contact information:
- Given name;
- Family name;
- E-mail address;
- Name of the service;
- The attribute your service requires including the reason why the attribute is required (see below for a list of available attributes);
- A description of your service (what is it, what does it do, why would someone want to use it, ...);
- Attach a logo of your service. Size: 500x300px, png-format with transparent background.
- (OPTIONAL) A list of custom attributes required or attribute mapping between our attributes and yours (NOT RECOMMENDED).
Send this information to surfconext-beheer@surfnet.nl and we'll get back to you when it is configured. This usually takes two to three working days.
Once this is done the basics should work and you should be able to authenticate to your service using SURFconext. Initially your service will be placed in TEST mode where you can play around with some identity providers configured for testing (see Do-It-Yourself Platform). Moving your service to production will require additional information (see: TODO).
Your (SP) Metadata
Below is a metadata example file for a service using simpleSAMLphp. It will tell SURFconext about the Entity ID, the ACS, the required (and optional) attributes and the (technical) contact information:
Code Block |
---|
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://frkosp.wind.surfnet.nl/simplesamlphp/module.php/saml/sp/metadata.php/default-sp">
<md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://frkosp.wind.surfnet.nl/simplesamlphp/module.php/saml/sp/saml2-logout.php/default-sp"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://frkosp.wind.surfnet.nl/simplesamlphp/module.php/saml/sp/saml2-acs.php/default-sp" index="0"/>
<md:AttributeConsumingService index="0">
<md:ServiceName xml:lang="en">FrKoSP</md:ServiceName>
<md:ServiceDescription xml:lang="en">This is FrKoSP's demonstration service</md:ServiceDescription>
<md:RequestedAttribute Name="urn:mace:dir:attribute-def:mail" isRequired="true"/>
<md:RequestedAttribute Name="urn:mace:dir:attribute-def:displayName"/>
</md:AttributeConsumingService>
</md:SPSSODescriptor>
<md:ContactPerson contactType="technical">
<md:GivenName>François</md:GivenName>
<md:SurName>Kooman</md:SurName>
<md:EmailAddress>francois.kooman@surfnet.nl</md:EmailAddress>
</md:ContactPerson>
</md:EntityDescriptor>
|
Attributes
The following attributes can be included in the response from SURFconext to the service provider. They contain information about the authenticated user. This will make it possible for the service to for instance show the "displayName" of the user in the interface or determine the affiliation of the user for authorization. For instance a student has a different view than a teacher.
work properly. In general they are needed to:
- Convey user information from the Identity provider or IdP to the service provider
- Create an account for the user at the service provider
- Authorize specific services at the service provider
Now, when a user logs in to a Service Provider, SURFconext sends a SAML assertion to the Service Provider via the browser of the user, that contains a:
- User identifier. Al services receive these and are either a configurable Transient or Persistent NameID.
and Additional attributes. These are optional and differ per Service.
Note |
---|
SURFconext's SAML2 implementation adheres to the SAML2int standard 0.2.1. The header on the link above states that work on saml2int has moved to Kantara Initiative. Until further notice, the SAML2int standard SURFconext adheres to remains at 0.2.1. |
Info |
---|
Before you start digging into the theoretical stuff on this page, you might want to start with our 'best practice' page for an introduction to and how attributes are best used. |
Table of Contents |
---|
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 the Service Provider must use the NameID or eduPersonTargetedID. The 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 is 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.
Warning | ||
---|---|---|
| ||
The NameID and eduPersonTargetedID, which is basically a copy of the NameID, is unlikely to change and very privacy aware but can change when service providers or identity provider make critical changes. This can cause user profiles for services to be lost. The NameID, as used in the SAML assertion to a service provider when loggin' on, is generated using the uid, schacHomeOrganization, the Entity ID of the service provider together with a secret that uses a SHA algorithm. Institutions or services that are in production and change one of these attributes, will cause a new NameID and eduPersonTargetedID to be generated by SURFconext when doing so. This can cause loss of access to profiles at services. We will notify identity providers and service providers when we see a change in one of these attributes to prevent user data being lost. |
Changing attributes
As an Identity Provider it is important to realize that changing attributes in production on SURFconext in any way can have an impact on services users have access to. Attributes that you offer to SURFconext are used to create profiles, and data is often linked to them. Changing an attribute in any way can have unwanted results like users that are no longer able to access their valuable data. An example could be to modify the way you fill the email address (amongst others). For example: changing 'student.123456@university.nl' to 'john.doe@university.nl'. Do you plan to do this or do you start a project where this is the case? Contact us and send an email to support@surfconext.nl.
Useful links
- Table with attributes we recommend our institutions to release: https://wiki.surfnet.nl/display/surfconextdev/Vereiste+attributen
- Profile Page https://profile.surfconext.nl/ , showing what attributes are released by your IdP to SURFconext
- For new IdP's or for IdP's that upgrade their environment: system administrators will at some point be asked to share the metadata of their account for analyses. When asked, visit this page and click the 'Mail to SURFconext' button. We will get back to you when we have judged the submitted metadata.This page will also show you the attributes shared and their values.
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
SURFconext supports relaying of the following attributes:
Friendly name | Attribute name | Example |
---|---|---|
SAML NameID element | bd09168cf0c2e675b2def0ade6f50b7d4bb4aae | |
urn:mace:dir:attribute-def:sn | Doe Vermeegen | |
urn:mace:dir:attribute-def:givenName | John Mërgim Lukáš Þrúður | |
urn:mace:dir:attribute-def:cn | John Doe Prof.dr. Mërgim Lukáš Vermeegen 加来 千代, PhD. | |
urn:mace:dir:attribute-def:displayName | Dr. John Doe Prof.dr. Mërgim L. Vermeegen 加来 千代, PhD. | |
urn:mace:dir:attribute-def:mail | m.l.vermeegen@university.example.org maarten.'t.hart@uniharderwijk.nl "very.unusual.@.but valid.nonetheless"@example.com mlv@[IPv6:2001:db8::1234:4321] | |
urn:mace:terena.org:attribute-def:schacHomeOrganization | example.nl something.example.org | |
urn:mace:terena.org:attribute-def:schacHomeOrganizationType | urn:mace:terena.org:schac:homeOrganizationType:int:university urn:mace:terena.org:schac:homeOrganizationType:es:opi | |
Employee/student number | urn:schac:attribute-def:schacPersonalUniqueCode | urn:schac:personalUniqueCode:nl:local:example.edu:employeeid:x12-3456 urn:schac:personalUniqueCode:nl:local:example.nl:studentid:s1234567 |
urn:mace:dir:attribute-def:eduPersonAffiliation | employee, student, faculty, member, affiliate, pre-student | |
Scoped affiliation | urn:mace:dir:attribute-def:eduPersonScopedAffiliation urn:oid:1.3.6.1.4.1.5923.1.1.1.9 | student@uniharderwijk.nl employee@uniharderwijk.nl |
urn:mace:dir:attribute-def:eduPersonEntitlement | to be determined per service (see Standardized values for eduPersonEntitlement) | |
urn:mace:dir:attribute-def:eduPersonPrincipalName | piet.jønsen@example.edu not.a@vålîd.émail.addreß | |
urn:mace:dir:attribute-def:isMemberOf | urn:collab:org:surf.nl urn:collab:org:clarin.org | |
urn:mace:dir:attribute-def:uid | s9603145 flåp@example.edu | |
urn:mace:dir:attribute-def:preferredLanguage | nl nl, en-gb;q=0.8, en;q=0.7 | |
ORCID | urn:mace:dir:attribute-def:eduPersonORCID urn:oid:1.3.6.1.4.1.5923.1.1.1.16 | http://orcid.org/0000-0002-1825-0097 |
ECK ID | urn:mace:surf.nl:attribute-def:eckid | https://ketenid.nl/spv1/eacf3765ad342...cf3a11fe9cab2365f95da3e9965501f7c98e (Attribute made shorter for readability) |
SURF CRM ID | urn:mace:surf.nl:attribute-def:surf-crm-id | ad93daef-0911-e511-80d0-005056956c1a |
MS AuthnMethodsReferences | http://schemas.microsoft.com/claims/authnmethodsreferences | urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport http://schemas.microsoft.com/claims/multipleauthn |
Note that not all identity providers might make all attributes available.
(1) eduPerson Object Class Specification (201602): https://wiki.refeds.org/pages/viewpage.action?pageId=44957738
Info | ||
---|---|---|
| ||
SURFconext considers the attributes nlEduPersonOrgUnit, nlEduPersonStudyBranch and nlStudielinkNummer deprecated. When you register a new SP at SURFconext, these attributes will not be allowed for use with SURFconext. Existing IdP's and SP can use these attributes until further notice. |
Detailed attribute descriptions
Anchor | ||||
---|---|---|---|---|
|
See User identifiers.
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:sn |
urn:oid | urn:oid:2.5.4.4 |
Multiplicity | single-valued |
Data type | UTF8 string (unbounded) |
Description | The surname of a person (including any words such as “van”, “de”, “von” etc.) used for Personalization; this can be a combination of existing attributes. |
Examples | Vermeegen 孝慈 |
Notes |
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:givenName |
urn:oid | urn:oid:2.5.4.42 |
Multiplicity | single-valued |
Data type | UTF8 string (unbounded) |
Description | Given name, also known as a first name, forename or Christian name / “name known by”; combinations of title, initials, and “name known by” are possible. |
Examples | Jan Klaassen |
Notes |
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:cn |
urn:oid | urn:oid:2.5.4.3 |
Multiplicity | multi-valued |
Data type | UTF8 string (unbounded) |
Description | Full name. |
Examples | Prof.dr. Mërgim Lukáš Vermeegen 加来 千代, PhD. |
Notes | For example, a typical name of a person in an English-speaking country comprises a personal title (e.g. Mr., Ms., Rd, Professor, Sir, Lord), a first name, middle name(s), last name, generation qualifier (if any, e.g. Jr.) and decorations and awards (if any, e.g. CBE). |
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:displayName |
urn:oid | urn:oid:2.16.840.1.113730.3.1.241 |
Multiplicity | single-valued |
Data type | UTF8 string (unbounded) |
Description | Name as displayed in applications |
Examples | Prof.dr. Mërgim Lukáš Vermeegen 加来 千代, PhD. |
Notes |
|
Anchor | ||||
---|---|---|---|---|
urn:mace | urn:mace:dir:attribute-def:mail |
urn:oid | urn:oid:0.9.2342.19200300.100.1.3 |
Multiplicity | multi-valued |
Data type | RFC-5322 address (max 256 chars) |
Description | e-mail address; syntax in accordance with RFC 5322 |
Examples | m.l.vermeegen@university.example.org "very.unusual.@.unusual.com"@example.com mlv@[IPv6:2001:db8::1234:4321]; the |
Notes |
|
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:uid |
urn:oid | urn:oid:0.9.2342.19200300.100.1.1 |
Multiplicity | single-valued (multi-valued in the specification, but within SURFconext only 1 value is allowed) |
Data type | UTF8 String (max 256 chars); use of spaces and @ -characters is discouraged. |
Description | The unique code for a person that is used as the login name within the institution. |
Examples | s9603145 |
Notes |
|
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:terena.org:attribute-def:schacHomeOrganization |
urn:oid | urn:oid:1.3.6.1.4.1.25178.1.2.9 |
Multiplicity | single-valued |
Data type | RFC-1035 domain string. The domain MUST be a secondary-level domain that is under control by the institution. Preferably, the institution's main domain name should be used. |
Description | The user's organization using the organization's domain name; syntax in accordance with RFC 1035. |
Examples | uniharderwijk.nl |
Notes |
|
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:terena.org:attribute-def:schacHomeOrganizationType |
urn:oid | urn:oid:1.3.6.1.4.1.25178.1.2.10 |
Multiplicity | single-value |
Data type | RFC-2141 URN (see Schac standard) |
Description | designation of the type of organization as defined on http://www.terena.org/registry/terena.org/schac/homeOrganizationType |
Examples | urn:mace:terena.org:schac:homeOrganizationType:int:university urn:mace:terena.org:schac:homeOrganizationType:es:opi |
Notes |
|
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:schac:attribute-def:schacPersonalUniqueCode |
urn:oid | urn:oid:1.3.6.1.4.1.25178.1.2.14 |
Multiplicity | multi-value |
Data type | RFC-2141 URN (see SURFnet registry) |
Description | The user's student, employee, and/or member id as used in the university's internal systems |
Examples | urn:schac:personalUniqueCode:nl:local:example.edu:employeeid:x12-3456 urn:schac:personalUniqueCode:nl:local:example.nl:studentid:s1234567 |
Notes |
|
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:eduPersonAffiliation |
urn:oid | urn:oid:1.3.6.1.4.1.5923.1.1.1.1 |
Multiplicity | multi-valued |
Data type | UTF8 String (only the values enumerated below are allowed) |
Description | Indicates the relationship between the user and his home organization (institution). The following values are permitted within SURFconext:
Use the above mentioned definitions to determine which affiliation a user gets. If the definitions are not sufficient, please use common sense. |
Examples | see above |
Notes |
|
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:eduPersonScopedAffiliation |
urn:oid | urn:oid:1.3.6.1.4.1.1466.115.121.1.15 |
Multiplicity | multi-valued |
Data type | UTF8 String of the form affiliation@domain (see below) |
Description | Indicates the relationship between the user and the domain of his home organization. The affiliation part must be one of the allowed values of the eduPersonAffiliation attribute (see definition right above). The value is the role of the user and the domain name of the organisation. eduPersonScopedAffiliation can hence be defined as: <eduPersonAffiliation> "@" <schacHomeOrganization>. Just like eduPersonScopedAffiliation, this is a multi valued attribute. The domain part must be the schacHomeOrganization of the user (or a subdomain thereof). |
Examples | student@uniharderwijk.nl faculty@uniharderwijk.nl |
Notes |
|
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:eduPersonEntitlement |
urn:oid | urn:oid:1.3.6.1.4.1.5923.1.1.1.7 |
Multiplicity | multi-value |
Data type | RFC-2141 URN |
Description | entitlement; custom URI (URL or URN) that indicates an entitlement to something. |
Examples |
|
Notes |
|
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:eduPersonPrincipalName |
urn:oid | urn:oid:1.3.6.1.4.1.5923.1.1.1.6 |
Multiplicity | single-valued |
Data type | UTF8 String of the form user@scope |
Description | Unique identifier for a user. |
Examples | piet.jønsen@example.e not.a@vålîd.émail.addreß |
Notes |
|
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:isMemberOf |
urn:oid | urn:oid:1.3.6.1.4.1.5923.1.5.1.1 |
Multiplicity | multi-valued |
Data type | RFC-2141 URN |
Description | Lists the collaborative organizations the user is a member of. |
Examples | urn:collab:org:surf.nl |
Notes |
|
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def:preferredLanguage |
urn:oid | urn:oid:2.16.840.1.113730.3.1.39 |
Multiplicity | single-valued |
Data type | RFC2798 BCP47 |
Description | a two-letter abbreviation for the preferred language according to the ISO 639 language abbreviation code table; no subcodes. |
Examples | nl |
Notes | Used to indicate an individual's preferred written or spoken language. This is useful for international correspondence or human-computer interaction. Values for this attribute type MUST conform to the definition of the Accept-Language header field defined in RFC 2068 with the exception that the value " |
Anchor | ||||
---|---|---|---|---|
|
urn:mace |
Attribute
Attribute (OID)
Example
Remarks
urn:mace:dir:attribute-def:displayName
urn:oid:2.16.840.1.113730.3.1.241
John Doe
Usually this is equal to cn
.
urn:mace:dir:attribute-def:mail
urn:oid:0.9.2342.19200300.100.1.3
john@example.org
This attribute can contain multiple email addresses.
urn:mace:dir:attribute-def:sn
urn:oid:2.5.4.4
Doe
urn:mace:dir:attribute-def:cn
urn:oid:2.5.4.3
John Doe
urn:mace:dir:attribute-def:givenName
urn:oid:2.5.4.42
John
urn:mace:dir:attribute-def: |
urn:oid:1.3.6.1.4.1.5923.1.1.1.6
john_doe@example.org
This is not necessarily a valid email address!
urn:mace:terena.org:attribute-def:schacHomeOrganization
eduPersonTargetedID | |
urn:oid | urn:oid:1.3.6.1.4.1. |
example.org
urn:mace:dir:attribute-def:uid
urn:oid:0.9.2342.19200300.100.1.1
john_doe
5923.1.1.1.10 | |
Multiplicity | single-valued |
Data type | UTF8 string (unbounded) |
Description | The attribute eduPersonTargetedID is a copy of the persistent Subject -> NameID, which is generated by SURFconext itself. When an Identity Provider provides the eduPersonTargetedID itself, it is always overwritten by SURFconext. |
Examples | bd09168cf0c2e675b2def0ade6f50b7d4bb4aae |
Notes | This attribute is created because the Subject -> NameID itself is not part of the SAML v2.0 response and therefore only is available for an application if the local SAML implementation explicitly supports this. Within SURFconext the Subject -> NameID is explicitly copied into the |
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:dir:attribute-def: |
eduPersonOrcid | |
urn:oid | urn:oid:1.3.6.1.4.1.5923.1.1.1 |
student
Supported values: employee
, student
and affiliate
.
urn:mace:dir:attribute-def:isMemberOf
urn:oid:1.3.6.1.4.1.5923.1.5.1.1
urn:collab:org:surf.nl
Contact us before you want to use this attribute!
Note |
---|
In order to uniquely identify a user the persistent Name ID value can be used. This value can be extracted from the Name ID and is also available in the attribute |
Note |
---|
Currently we convert |
Note |
---|
UID is the unique identifier of the user at the home institution, it is not unique for all users in SURFconext! Use eduPersonTargetedID (preferred) or eduPersonPrincipalName if you need to uniquely identify users. |
A service provider SHOULD only at most request the following attributes, requesting these and any other attributes MUST BE accompanied by an explanation of why they are needed:
urn:mace:dir:attribute-def:displayName
urn:mace:dir:attribute-def:mail
urn:mace:dir:attribute-def:cn
urn:mace:dir:attribute-def:eduPersonAffiliation
urn:mace:terena.org:attribute-def:schacHomeOrganization
The attributes are available in both human readable format and OID format. See also this eduGAIN recommendation.
Ultimately it is up to the identity provider and service provider to agree on a set of attributes to be released by the IdP, SURFconext only mediates. However, it is strongly recommend to stick to the above attributes as they are standardized and ensure greater interoperability.
Provisioning
Assuming some kind of user administration is required at your service, the recommended way to deal with people logging in through SURFconext is that on first login an account is automatically created for the user and bound to the (persistent) Name ID value in the SAML assertion.
Some service providers will offer additional APIs or web interfaces to manually configure user accounts and also delete (deprovision) them. It is highly undesirable that the (proprietary) API needs to be used to (manually) create user accounts before users are able to login.
Group API
...
.16 | |
Multiplicity | multi-valued (see remark below) |
Data type | URL, registered with ORCID.org |
Description | The ORCID is a persistent digital identifier that distinguishes the account holder from every other researcher. Through integration in research workflows such as manuscript and grant submission, the ORCID identifier supports automated linkages between the account holder and his/her professional activities ensuring that the account holder's work is recognized. Values MUST be valid ORCID identifiers in the ORCID preferred URL representation, i.e. http://orcid.org/0000-0002-1825-0097 |
Examples | |
Notes | Although the attribute is in theory multi-valued, in practice it probably makes sense that it has no more than one value. |
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:surf.nl:attribute-def:eckid |
urn:oid | - |
Multiplicity | single-valued |
Data type | URL as specified by Edu-K, all-lowercase |
Description | Educatieve Content Keten Identifier (ECK ID) is a pseudonymous identifier for access to content for primary, secondary and vocational education. |
Examples |
|
Notes | This attribute may only be used for “the access to and use of digital learning resources or the digital administration of tests and exams”. For more information see https://www.eck-id.nl (Dutch). Also, if you query this claim information from an external data stores, such as an Enterprise Active Directory, Lightweight Directory Access Protocol (LDAP) directories or a Microsoft SQL Server, you can also define custom attribute stores to query the ECK ID claim from external data stores. Read this Microsoft blog to get to know more. |
Anchor | ||||
---|---|---|---|---|
|
urn:mace | urn:mace:surf.nl:attribute-def:surf-crm-id |
urn:oid | urn:oid:1.3.6.1.4.1.1076.20.100.10.50.2 |
Multiplicity | single-valued |
Data type | Microsoft GUID |
Description | GUID of the organization to which the IdP belongs, as used in the SURF CRM. |
Examples | ad93daef-0911-e511-80d0-005056956c1a |
Notes | SURF specific and only to be used by SURF SPs that have to interface with the SURF CRM. Only to be used after consultation with SURFnet. |
Anchor | ||||
---|---|---|---|---|
|
Name | http://schemas.microsoft.com/claims/authnmethodsreferences |
Multiplicity | multi-valued |
Data type | URI |
Description | The AuthnContext-referenties involved in authenticating the current user on their home IdP. |
Examples |
|
Opmerkingen |
|