AAI guide for SPs

Overview

This wiki page contains information about connecting services to the NI4OS-Europe Login service in order to enable federated authentication and authorisation.

General Information

NI4OS-Europe Login supports two authentication and authorisation protocols that you can choose from:

1. OpenID Connect - an extension to OAuth 2.0
2. Security Assertion Markup Language (SAML) 2.0

Regardless of which of the two protocols you are going to use, you need to provide the following information to connect your service to NI4OS-Europe Login:

1. Name of the service (in English and optionally in other languages supported by the service)
2. Short description of the service
3. Website (URL) for localised information about the service; the content found at the URL SHOULD provide more complete information than what provided by the description
4. Contact information of the following types:
   • Helpdesk/Support contact information (for redirecting user)
   • Administrative
   • Technical
   • Security/incident response
5. Privacy statement URL: The privacy policy is used to document the data collected and processed by the service. You can use the Privacy Policy template.
6. Logo URL (optional for showing in catalogues); if provided, logos SHOULD:
   • use a transparent background where appropriate to facilitate the usage of logos within a user interface
   • use PNG, or GIF (less preferred), images
   • use HTTPS URLs in order to avoid mixed-content warnings within browsers
   • have a size larger than 40000 and smaller than 50000 characters when encoded in base64

OpenID Connect Relying Party

Services can be connected to NI4OS-Europe Login using OpenID Connect (OIDC). NI4OS-Europe Login provides an OpenID Connect (OAuth2) API based on MITREid Connect, which has been certified by the OpenID Foundation. You need to install an OpenID Connect Relying Party (OIDC RP) software and integrate it into your application. If you are connecting a web application, then you should choose the Authorization Code flow. Please refer to https://openid.net/certification/ for a list of certified relying party library implementations.

Interconnection with the NI4OS-Europe Login OpenID Provider allows users to sign in using any of the supported backend authentication mechanisms, such as institutional identity providers registered with eduGAIN or Social Providers. Once the user has signed in, NI4OS Login can return OIDC Claims containing information about the authenticated user.

Client registration

Before your service can use the NI4OS OIDC Provider for user login, you must register a client in order to obtain OAuth 2.0 credentials and register one or more redirect URIs.

To register your client, please contact faai@grnet.gr. Your request should include the general information about your service (see #General Information) and the protocol-specific details below:

1. One or more redirection URIs where the NI4OS OIDC Provider will send responses to your authentication requests. Note that redirection URIs MUST use the https scheme
2. Token endpoint authentication type - One of the following options:
   • Client Secret over HTTP Basic
   • Client Secret over HTTP POST
3. List of scopes allowed to be requested by your client. The following scopes are available:
   • openid - (REQUIRED) allows retrieving the user's unique user identifier through the sub claim
   • profile - allows retrieving the user's name information through the given_name, family_name, and name claims
   • email - allows retrieving the user's email information through the email and email_verified claims
   • eduperson_entitlement - allows retrieving the user's entitlements (group membership & role information) through the eduperson_entitlement claim
4. Contact for receiving PIN to access client credentials - To ensure the security of your client credentials we will send you a PIN (personal identification number) that you need to use in order to access your client credentials. The PIN must be sent through a different means than the email address used to contact us. Please supply a different email address or a keybase, Skype handle.

The configuration of the NI4OS-Europe Login OpenID Provider is available at https://aai.ni4os.eu/oidc/.well-known/openid-configuration.

SAML Service Provider

To enable federated access to a web-based application, you can connect to the NI4OS AAI IdP as a SAML Service Provider (SP). Users of the application will be redirected to the NI4OS AAI in order to log in, and the NI4OS AAI can authenticate them using any of the supported backend authentication mechanisms, such as institutional IdPs registered with eduGAIN or Social Providers. Once the user is authenticated, the NI4OS AAI will return a SAML assertion to the application containing information about the authenticated user.

Metadata registration

SAML authentication relies on the use of metadata. Both parties (you as a SP and the NI4OS AAI 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 NI4OS AAI IdP Proxy on a dedicated URL: https://aai.ni4os.eu/proxy/saml2/idp/metadata.php

Metadata

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:IDPSSODescriptor> 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 NI4OS AAI IdP is guaranteed to release a minimal subset of the REFEDS R&S attribute bundle to connected Service Providers without administrative involvement, subject to user consent. The following attributes constitute a minimal subset of the R&S attribute bundle:

• Persistent, non-reassignable, non-targeted, opaque, globally unique NI4OS user ID (subject-id); this is always scoped @ni4os.eu
• Email address (mail)
• Display name (displayName) OR (givenName AND sn)

A more extensive list of all the attributes that may be made available to Service Providers is included in the following table:

Attribute friendly name	Attribute OID	Example value
subject-id	urn:oasis:names:tc:SAML:attribute:subject-id	n472285@ni4os.eu
mail	urn:oid:0.9.2342.19200300.100.1.3	john.doe@example.org
displayName	urn:oid:2.16.840.1.113730.3.1.241	John Doe
givenName	urn:oid:2.5.4.42	John
sn	urn:oid:2.5.4.4	Doe
eduPersonAssurance	urn:oid:1.3.6.1.4.1.5923.1.1.1.11	TBD
distinguishedName	urn:oid:2.5.4.49	/C=NL/O=Example.org/CN=John Doe
eduPersonScopedAffiliation	urn:oid:1.3.6.1.4.1.5923.1.1.1.9	faculty@example.org
eduPersonEntitlement	urn:oid:1.3.6.1.4.1.5923.1.1.1.7	urn:mace:geant:ni4os.eu:group:test-group:role=member#aai.ni4os.eu

Attribute-based authorisation

The NI4OS AAI provides information about the authenticated user that may be used by Service Providers in order to control user access to resources. This information is provided by the NI4OS AAI IdP in the SAML attribute assertion. The table below lists the SAML attributes that are relevant for user authorisation:

Description	SAML Attribute
Group membership/roles of the authenticated user	eduPersonEntitlement
Level of Assurance (LoA)	eduPersonAssurance

References

• Shibboleth SP Configuration
• SimpleSAMLphp Service Provider QuickStart
• Simple SAML 2.0 service provider with mod_auth_mellon Apache module