SAML
Metadata registration
SAML authentication relies on the use of metadata. Both parties (you as a SP and the LifeScience IdP) need to exchange metadata in order to know and trust each other. The metadata include information such as the location of the service endpoints that need to be invoked, as well as the certificates that will be used to sign SAML messages. The format of the exchanged metadata should be based on the XML-based SAML 2.0 specification. Usually, you will not need to manually create such an XML document, as this is automatically generated by all major SAML 2.0 SP software solutions (e.g., Shibboleth, SimpleSAMLphp, and mod_auth_mellon). It is important that you serve your metadata over HTTPS using a browser-friendly SSL certificate, i.e. issued by a trusted certificate authority.
You can get the metadata of the LifeScience IdP on a dedicated URL that depends on the integration environment being used:
| Development environment | Production environment |
|---|---|
| https://saml.pilot.lifescienceid.org/proxy/saml2/idp/metadata.php | https://saml.lifescienceid.org/proxy/saml2/idp/metadata.php |
Metadata considerations
Metadata provided by your SP should contain a descriptive name of the service that your SP represents in at least English. It is recommended to also provide the name in other languages which are commonly used in the geographic scope of the deployment. The name should be placed in the <md:ServiceName> in the <md:AttributeConsumingService> container.
It is recommended that the <md:SPSSODescriptor> element included in your SP metadata contains both an AuthnRequestsSigned and an WantAssertionsSigned attribute set to true.
Your SP metadata should also contain contact information for support and for a technical contact. The <md:EntityDescriptor> element should contain both a <md:ContactPerson> element with a contactType of "support" and a <md:ContactPerson> element with a contactType of "technical". The <md:ContactPerson> elements should contain at least one <md:EmailAddress>. The support address may be used for generic support questions about the service, while the technical contact may be contacted regarding technical interoperability problems. The technical contact must be responsible for the technical operation of the service represented by your SP.
Attributes
The LifeScience IdP is guaranteed to release a minimal subset of the REFEDS Research & Scholarship attribute bundle to connected Service Providers. A more extensive list of all the attributes that may be made available to Service Providers is included in the following table:
| Attribute Description | Attribute Friendly Name | Attribute OID | Attribute Example Value |
|---|---|---|---|
Life Science unique ID; this is a persistent, non-reassigned, non-targeted identifier, which is always scoped @lifescienceid.org | eduPersonUniqueId | urn:oid:1.3.6.1.4.1.5923.1.1.1.13 |
|
| Life Science username; this is is a user-selected, human-readable, revocable identifier | TBD | TBD |
|
| Email address | mail | urn:oid:0.9.2342.19200300.100.1.3 | john.doe@example.org |
| Display name | displayName | urn:oid:2.16.840.1.113730.3.1.241 | John Doe |
| First name | givenName | urn:oid:2.5.4.42 | John |
| Family name | sn | urn:oid:2.5.4.4 | Doe |
| Assurance information | eduPersonAssurance | urn:oid:1.3.6.1.4.1.5923.1.1.1.11 | TBD |
| Affiliation within research infrastructure | eduPersonScopedAffiliation | urn:oid:1.3.6.1.4.1.5923.1.1.1.9 | affiliate@lifescienceid.org |
| Affiliation within Home Organisation | voPersonExternalAffiliation | https://welcome.lifescienceid.org/attribute-definition/voPersonExternalAffiliation/v1 (only released in pilot environment) | member@example.org |
Entitilement(s): One or more URIs (either URNs or URLs) that indicate rights to specific resources; URN values expressing group membership and role information use the urn:geant:lifescienceid.org:group namespace (see also AARC-G001) | eduPersonEntitlement | urn:oid:1.3.6.1.4.1.5923.1.1.1.7 |
|
| One or more ORCID researcher identifiers | eduPersonOrcid | urn:oid:1.3.6.1.4.1.5923.1.1.1.16 | http://orcid.org/0000-0002-1825-0097 |
OIDC
OIDC Client Registration
LifeScience Authentication and Authorisation Infrastructure (LS-AAI) supports LifeScience community's OpenID Connect (OIDC) based clients or service providers. The providers are Web applications like SAML SPs. For the integration, the clients must be registered with OIDC authorisation server provided by the LS-AAI. The operators of the clients are required to provide OIDC client credentials (client id and secret) and redirect or callback URI for the successful registration.
Metadata Discovery Endpoint
The OIDC endpoints can be discovered under the following address (also called well-known URL):
Pilot: https://oidc.pilot.lifescienceid.org/oauth2/.well-known/openid-configuration
Production: https://oidc.lifescienceid.org/oauth2/.well-known/openid-configuration
Scopes and Claims (Attributes)
Scope in the LS-AAI defines what claims or user attributes the OIDC client can access. Following three standard scopes with corresponding claims are provided:
| Scope | Claim (User Attribute Name) | ||||||
|---|---|---|---|---|---|---|---|
| openid | sub | ||||||
| profile |
| ||||||
| refeds_edu (TBD) |
|
Self Service Home Page
Following endpoint can be used to change password, OIDC redirect/callback URIs and SP url attribute:
Pilot: https://oidc.pilot.lifescienceid.org/home
Production: https://oidc.lifescienceid.org/home