Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "AAI guide for IdPs"

From EGIWiki
Jump to navigation Jump to search
(Add instructions for integration in the development environment)
Line 5: Line 5:
This wiki page contains information about integrating your identity provider with the [[AAI | EGI AAI Proxy]] in order to allow users in your community to access EGI tools and services.
This wiki page contains information about integrating your identity provider with the [[AAI | EGI AAI Proxy]] in order to allow users in your community to access EGI tools and services.


Organisations who want to register their IDP in CheckIn needs to fill this [https://documents.egi.eu/document/3086 form] in case the IdP is not publishing RnS and Sirtfi compliance in eduGAIN. A PDF scansion of a printed and signed copy should be sent to operations [at] egi.eu
Organisations who want to register their IDP in Check-in needs to fill this [https://documents.egi.eu/document/3086 form] in case the IdP is not publishing R&S and Sirtfi compliance in eduGAIN. A PDF scansion of a printed and signed copy should be sent to operations [at] egi.eu
 
= Identity Provider integration workflow =
 
To integrate your Identity Provider with the EGI Check-in service, you need to submit a [[GGUS]] ticket indicating your request. The responsible support unit is [[GGUS:AAI_SUPPORT_FAQ|AAI Support]]. The integration follows a two-step process:
 
* '''Step 1.''' Register your Identity Provider and test integration with the development instance of EGI Check-in. The development instance allows for testing authentication and authorisation to EGI services and resources without affecting the production environment of EGI. Note that the development instance is not connected to the production service and no information is shared between the two systems.
* '''Step 2.''' Register your Identity Provider with the production instance of EGI Check-in to allow members of your Community to access production EGI services and resources protected by Check-in. This requires that your Identity Provider meets all the [https://documents.egi.eu/document/3086 policy requirements] and that integration has been thoroughly tested during Step 1.
 
The most important URLs for each environment are listed in the table below but more information can be found in the protocol-specific sections that follow.
 
{| class="wikitable"
|-
! Protocol
! Development environment
! Production environment
|-
| SAML
| https://aai-dev.egi.eu/proxy/module.php/saml/sp/metadata.php/sso
| https://aai.egi.eu/proxy/module.php/saml/sp/metadata.php/sso
|-
| OpenID Connect
| N/A
| N/A
|}


= SAML Identity Provider =
= SAML Identity Provider =
Line 26: Line 50:
Note that if your IdP is part of a federation, then it would be preferred to send us the URL to a signed federation metadata aggregate. We can then cherry pick the appropriate entityID from that.
Note that if your IdP is part of a federation, then it would be preferred to send us the URL to a signed federation metadata aggregate. We can then cherry pick the appropriate entityID from that.


You can get the metadata of the EGI SP Proxy from the following URL:
You can get the metadata of the EGI Check-in SP Proxy on a dedicated URL that depends on the integration environment being used:
<code>https://aai.egi.eu/proxy/module.php/saml/sp/metadata.php/sso</code>
{| class="wikitable"
|-
! Development environment
! Production environment
|-
| https://aai-dev.egi.eu/proxy/module.php/saml/sp/metadata.php/sso
| https://aai.egi.eu/proxy/module.php/saml/sp/metadata.php/sso
|}


Alternatively, you can use one of the following signed metadata aggregates:
For the production environment, it is recommended that you get the metadata for the EGI Check-in SP (entityID: <code>https://aai.egi.eu/proxy/module.php/saml/sp/metadata.php/sso</code>) from a signed eduGAIN metadata aggregate. For example, the following aggregates are provided by GRNET:
* [https://md.aai.grnet.gr/aggregates/grnet-metadata.xml GRNET federation's metadata]
* [https://md.aai.grnet.gr/aggregates/grnet-metadata.xml GRNET federation's metadata]
* [https://md.aai.grnet.gr/feeds/edugain-sp-samlmd.xml eduGAIN SP metadata]
* [https://md.aai.grnet.gr/feeds/edugain-sp-samlmd.xml eduGAIN SP metadata]

Revision as of 11:11, 15 November 2018


Overview

This wiki page contains information about integrating your identity provider with the EGI AAI Proxy in order to allow users in your community to access EGI tools and services.

Organisations who want to register their IDP in Check-in needs to fill this form in case the IdP is not publishing R&S and Sirtfi compliance in eduGAIN. A PDF scansion of a printed and signed copy should be sent to operations [at] egi.eu

Identity Provider integration workflow

To integrate your Identity Provider with the EGI Check-in service, you need to submit a GGUS ticket indicating your request. The responsible support unit is AAI Support. The integration follows a two-step process:

  • Step 1. Register your Identity Provider and test integration with the development instance of EGI Check-in. The development instance allows for testing authentication and authorisation to EGI services and resources without affecting the production environment of EGI. Note that the development instance is not connected to the production service and no information is shared between the two systems.
  • Step 2. Register your Identity Provider with the production instance of EGI Check-in to allow members of your Community to access production EGI services and resources protected by Check-in. This requires that your Identity Provider meets all the policy requirements and that integration has been thoroughly tested during Step 1.

The most important URLs for each environment are listed in the table below but more information can be found in the protocol-specific sections that follow.

Protocol Development environment Production environment
SAML https://aai-dev.egi.eu/proxy/module.php/saml/sp/metadata.php/sso https://aai.egi.eu/proxy/module.php/saml/sp/metadata.php/sso
OpenID Connect N/A N/A

SAML Identity Provider

To allow users in your community to sign into federated EGI applications, you need to connect to the EGI AAI SP Proxy as a SAML Identity Provider (IdP). Users of the application will be redirected to the central Discovery Service page of the EGI AAI Proxy where they will able to select to authenticate at your IdP. Once the user is authenticated, the EGI AAI Proxy will return a SAML assertion to the application containing the information returned by your IdP about the authenticated user.

Metadata registration

SAML authentication relies on the use of metadata. Both parties (you as an IdP and the EGI AAI SP) 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 IdP software solutions (e.g., Shibboleth, SimpleSAMLphp). It is important that you serve your metadata over HTTPS using a browser-friendly SSL certificate, i.e. issued by a trusted certificate authority.

To exchange metadata, please send an email including the following information:

  1. entityID
  2. Metadata URL

Depending on the software you are using, the authoritative XML metadata URL for your IdP might be in the following form:

Note that if your IdP is part of a federation, then it would be preferred to send us the URL to a signed federation metadata aggregate. We can then cherry pick the appropriate entityID from that.

You can get the metadata of the EGI Check-in SP Proxy on a dedicated URL that depends on the integration environment being used:

Development environment Production environment
https://aai-dev.egi.eu/proxy/module.php/saml/sp/metadata.php/sso https://aai.egi.eu/proxy/module.php/saml/sp/metadata.php/sso

For the production environment, it is recommended that you get the metadata for the EGI Check-in SP (entityID: https://aai.egi.eu/proxy/module.php/saml/sp/metadata.php/sso) from a signed eduGAIN metadata aggregate. For example, the following aggregates are provided by GRNET:

Attribute release

Within the EGI environment, a user must have one persistent, non-reassignable, non-targeted, opaque, and globally unique identifier. To achieve this, the EGI AAI Proxy generates a eduPersonUniqueId (urn:oid:1.3.6.1.4.1.5923.1.1.1.13) attribute based on the first non-empty value from this attribute list:

  • eduPersonUniqueId
  • eduPersonPrincipalName
  • eduPersonTargetedID / SAML 2.0 Persistent NameID

As such, it is required by your IdP to release at least one of the above user identifiers.

The selected attribute value is hashed and the "egi.eu" scope portion is added to the generated ePUID, e.g.:

ef72285491ffe53c39b75bdcef46689f5d26ddfa00312365cc4fb5ce97e9ca87@egi.eu

The generated ePUID should be accompanied with a minimum set of attributes:

  • Email address (mail)
  • Display name (displayName) OR (givenName AND sn)
  • Affiliation with home organisation (eduPersonScopedAffiliation)

The EGI AAI SP Proxy will attempt to retrieve these attributes from your IdP. If this is not possible, the missing user attributes will be acquired and verified through the user registration process with the EGI Account Registry .

Note that the above set of request attributes complies with the REFEDS R&S attribute bundle.

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
eduPersonUniqueId urn:oid:1.3.6.1.4.1.5923.1.1.1.13 ef72285491ffe53c39b75bdcef46689f5d26ddfa00312365cc4fb5ce97e9ca87@egi.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 https://aai.egi.eu/LoA#Substantial
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:egi.eu:www.egi.eu:wiki-editors:member@egi.eu

Integration success stories