You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

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:

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 DescriptionAttribute Friendly NameAttribute OIDAttribute Example Value
Life Science unique ID; this is a persistent, non-reassigned, non-targeted identifier, which is always scoped @lifescienceid.orgeduPersonUniqueIdurn:oid:1.3.6.1.4.1.5923.1.1.1.13

ef72285491ffe53c39b75bdcef46689f5d26ddfa00312365cc4fb5ce97e9ca87@lifescienceid.org

Life Science username; this is is a user-selected, human-readable, revocable identifierTBDTBD

jdoe@lifescienceid.org

Email addressmailurn:oid:0.9.2342.19200300.100.1.3john.doe@example.org
Display namedisplayNameurn:oid:2.16.840.1.113730.3.1.241John Doe
First namegivenNameurn:oid:2.5.4.42John
Family namesnurn:oid:2.5.4.4Doe
Assurance informationeduPersonAssuranceurn:oid:1.3.6.1.4.1.5923.1.1.1.11TBD
Affiliation within research infrastructureeduPersonScopedAffiliationurn:oid:1.3.6.1.4.1.5923.1.1.1.9affiliate@lifescienceid.org
Affiliation within Home OrganisationvoPersonExternalAffiliationhttps://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)eduPersonEntitlementurn:oid:1.3.6.1.4.1.5923.1.1.1.7

urn:geant:lifescienceid.org:group:examplegroup#perun.pilots.lifescienceid.org

urn:geant:lifescienceid.org:group:examplegroup:examplesubgroup#perun.pilots.lifescienceid.org

urn:geant:lifescienceid.org:group:examplegroup:examplesubgroup:role=manager#perun.pilots.lifescienceid.org

One or more ORCID researcher identifierseduPersonOrcidurn:oid:1.3.6.1.4.1.5923.1.1.1.16http://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:

ScopeClaim (User Attribute Name)
openidsub
profile

cn

c
email
givenName
sn
eduPersonUniqueId
emailemail
refeds_edu (TBD)
eduperson_unique_id

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

  • No labels