AAI guide for SPs
This wiki page contains information about connecting services to the NI4OS AAI service in order to enable federated authentication and authorisation.
The NI4OS-Europe AAI supports both OpenID Connect (an extension to OAuth 2.0) and 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 the NI4OS-Europe AAI:
- Name of the service (in English and optionally in other languages supported by the service)
- Short description of the service
- 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
- Contact information of the following types:
- Helpdesk/Support contact information (for redirecting user)
- Security/incident response
- 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
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.
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 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.
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|
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:
|Group membership/roles of the authenticated user||eduPersonEntitlement|
|Level of Assurance (LoA)||eduPersonAssurance|
- Shibboleth SP Configuration
- SimpleSAMLphp Service Provider QuickStart
- Simple SAML 2.0 service provider with mod_auth_mellon Apache module
OpenID Connect Service Provider
Service Providers can be integrated with the NI4OS AAI using OpenID Connect (OIDC) as an alternative to the SAML2 protocol. To allow this, the NI4OS AAI IdP provides an OpenID Connect (OAuth2) API based on MITREid Connect, which has been certified by the OpenID Foundation. Interconnection with the NI4OS AAI OIDC Provider allows users to sign in using any of the supported backend authentication mechanisms, such as institutional IdPs registered with eduGAIN or Social Providers. Once the user has signed in, the NI4OS AAI can return OIDC Claims containing information about the authenticated user.
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.
- One or more redirect URIs where the NI4OS OIDC Provider will send responses to your authentication requests. Note that the Redirection URI MUST use the
- Token endpoint authentication type: One of the following options:
- Client Secret over HTTP Basic
- Client Secret over HTTP POST
- 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
profile- allows retrieving the user's name information through the
eduperson_entitlement- allows retrieving the user's entitlements (group membership & role information) through the