|
|
| (77 intermediate revisions by 9 users not shown) |
| Line 1: |
Line 1: |
| {{TOC_right}} | | {{TOC_right}} |
|
| |
|
| = Overview =
| | The documentation has moved to https://docs.egi.eu/providers/check-in/sp/. |
| | |
| This wiki page contains information about enabling federated access to EGI tools and services through the EGI AAI Proxy.
| |
| | |
| = SAML Service Provider =
| |
| | |
| To enable federated access to a web-based application, you need to connect to the EGI AAI IdP Proxy as a SAML Service Provider (SP). Users of the application will be redirected to the Proxy to log in, and the Proxy 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 EGI AAI Proxy 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 EGI 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 [https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf 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 EGI IdP Proxy on a dedicated URL:
| |
| <pre>
| |
| https://aai.egi.eu/proxy/saml2/idp/metadata.php
| |
| </pre>
| |
| | |
| == Attribute release ==
| |
| | |
| The EGI AAI IdP Proxy is guaranteed to release a minimal subset of the [https://refeds.org/category/research-and-scholarship 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:
| |
| | |
| * unique EGI user ID (<tt>eduPersonUniqueId</tt>)
| |
| * email address
| |
| * displayName OR (givenName AND sn)
| |
| | |
| A more extensive list of the attributes that may be made available to Service Providers is included in the following table:
| |
| | |
| {| class="wikitable"
| |
| |-
| |
| ! Attribute friendly name
| |
| ! Attribute OID
| |
| ! Example value
| |
| |-
| |
| |<tt>eduPersonUniqueId</tt>
| |
| |<tt>urn:oid:1.3.6.1.4.1.5923.1.1.1.13</tt>
| |
| |<tt>ef72285491ffe53c39b75bdcef46689f5d26ddfa00312365cc4fb5ce97e9ca87@egi.eu</tt>
| |
| |-
| |
| |<tt>mail</tt>
| |
| |<tt>urn:oid:0.9.2342.19200300.100.1.3</tt>
| |
| |<tt>john.doe@example.org</tt>
| |
| |-
| |
| |<tt>displayName</tt>
| |
| |<tt>urn:oid:2.16.840.1.113730.3.1.241</tt>
| |
| |<tt>John Doe</tt>
| |
| |-
| |
| |<tt>givenName</tt>
| |
| |<tt>urn:oid:2.5.4.42</tt>
| |
| |<tt>John</tt>
| |
| |-
| |
| |<tt>sn</tt>
| |
| |<tt>urn:oid:2.5.4.4</tt>
| |
| |<tt>Doe</tt>
| |
| |-
| |
| |<tt>eduPersonAssurance</tt>
| |
| |<tt>urn:oid:1.3.6.1.4.1.5923.1.1.1.11</tt>
| |
| |<tt>https://aai.egi.eu/LoA#Substantial</tt>
| |
| |-
| |
| |<tt>distinguishedName</tt>
| |
| |<tt>urn:oid:2.5.4.49</tt>
| |
| |<tt>/C=NL/O=Example.org/CN=John Doe</tt>
| |
| |-
| |
| |<tt>eduPersonScopedAffiliation</tt>
| |
| |<tt>urn:oid:1.3.6.1.4.1.5923.1.1.1.9</tt>
| |
| |<tt>faculty@example.org</tt>
| |
| |-
| |
| |<tt>eduPersonEntitlement</tt>
| |
| |<tt>urn:oid:1.3.6.1.4.1.5923.1.1.1.7</tt>
| |
| |<tt>urn:mace:egi.eu:www.egi.eu:wiki-editors:member@egi.eu</tt>
| |
| |}
| |
| | |
| == Authorisation ==
| |
| | |
| Access to the various resources protected by your Service Provider can be controlled based on:
| |
| | |
| # VO/EGI membership/roles of the authenticated user (<tt>eduPersonEntitlement</tt> SAML attribute)
| |
| # Level of Assurance (LoA)
| |
| | |
| === eduPersonEntitlement ===
| |
| | |
| ==== Background ====
| |
| The eduPerson object specification defines the [http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201310.html#eduPersonEntitlement eduPersonEntitlement] attribute In order to control access to resources. This is a multi-valued attribute, with each value formatted as a URI (either URN or URL) to indicate a set of rights to specific resources based on an agreement across the relevant communities. <tt>eduPersonEntitlement</tt> attributes are typically used to assert privileges maintained centrally or remotely rather than within local application-specific user databases.
| |
| | |
| ==== Syntax ====
| |
| Values for <tt>eduPersonEntitlement</tt> for use within the EGI environment adopt the following formatting specification:
| |
| <pre>
| |
| urn:mace:egi.eu:<authority-fqdn>:[<group>[:<subgroup>:…]]:<role>@<vo>
| |
| </pre>
| |
| where:
| |
| * <tt><authority-fqdn></tt> is the FQDN of the authoritative source for the entitlement value
| |
| * <tt><vo></tt> is the name of the Virtual Organisation
| |
| * <tt><group></tt> is the name of a group in the identified <tt><vo></tt>; specifying a group is optional
| |
| * zero or more <tt><subgroup></tt> components represent the hierarchy of subgroups in the <tt><group></tt>; specifying sub-groups is optional
| |
| * the <tt><role></tt> component is scoped to the rightmost (sub)group; if no group information is specified, the role applies to the VO
| |
| | |
| ==== Semantics ====
| |
| Each eduPersonEntitlement attribute value represents a particular position of the user within a VO. A user may be member or hold more specific roles within the groups associated to a VO. Groups are organised in a tree structure, meaning that a group may have subgroups, which in turn may have subgroups, etc.
| |
| | |
| This hierarchical structure implies that if someone is member of a subgroup, then they are also member of the parent group. For example:
| |
| <pre>
| |
| parent-group:child-group:member
| |
| </pre>
| |
| | |
| implies membership in parent-group, i.e.:
| |
| | |
| <pre>
| |
| parent-group:member
| |
| </pre>
| |
| | |
| Ownership of any role always implies the member role for that particular (sub)group. However, holding a more specific role (i.e. one other than member) in a subgroup does not imply the same role in the parent group. For example:
| |
| <pre>
| |
| parent-group:child-group:manager
| |
| </pre>
| |
| | |
| implies plain membership in both <tt>child-group</tt> and <tt>parent-group</tt>, but '''NOT''':
| |
| | |
| <pre>
| |
| parent-group:manager
| |
| </pre>
| |
| | |
| == References ==
| |
| * [https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPConfiguration Shibboleth SP Configuration]
| |
| * [https://simplesamlphp.org/docs/stable/simplesamlphp-sp SimpleSAMLphp Service Provider QuickStart]
| |
| * [https://github.com/UNINETT/mod_auth_mellon Simple SAML 2.0 service provider with mod_auth_mellon Apache module]
| |
The wiki is deprecated and due to be decommissioned by the end of September 2022.