Technical Specification

Edugate Technical Specification

Member Service Providers can expect member identity providers to support (but not necessarily release) a minimum set of data as set out in Table 1. This data will be formatted according to the Interoperable SAML 2 Web Browser SSO Deployment Profile[i] .Members may choose to support additional data from the eduPerson data schema[ii] and the OASIS X500/LDAP Schema (OASIS Security Services Technical Committee) or agree their own additional data schemas. Service Providers must accept that the federation operator may extend the minimum agreed set in the future or adopt changes made by the eduPerson data schema standards body (Internet2 MACE-Directories Working Group).  Members have a two year period to support the revised minimum attribute set.

Attribute Personal Data Example eduPersonTargetedID no 43348f9490029fdjkqdqje eduPersonPrincipalName yes 1312394238@ucd.ie, stf39292@tcd.ie, jbloggs@ucc.ie eduPersonEntitlement potentially urn:mace:heanet.ie:edugate:media:user eduPersonScopedAffiliation no staff@gmit.ie, student@lit.ie givenName yes Joe surname yes Bloggs mail yes joe.bloggs@tcd.ie, stu1341123@ucc.ie organizationName no Dundalk Institute of Technology

Table 1 Minimum Agreed Set

eduPersonScopedAffiliation.

The eduPersonScopedAffiliation consist of two parts separated by the ‘@’ symbol, the latter part is discussed in the section of this document titled ‘Scoped Attribute’ below. The former part is limited to a vocabulary as defined by the eduPerson specification, for convenience the permissible values are limited to the following vocabulary as follows;

faculty, student, staff, alum, member, affiliate, employee, library-walk-in

The value ‘employee’  is not recommended as the value of ‘staff’ has greater meaning in the context of Irish HEI’s.  Where a postgraduate research student is issued with a campus account equivalent to fulltime paid employees such as faculty and administrative staff, the value of ‘staff’ should be used. A user may have multiple affiliations to an institution, therefore multiple values are permitted.

1.1     Attribute Requirements

The Edugate Resource Registry website serves as the system of record for service provider Attribute Requirements. Service providers must ensure that the attributes required by their services are accurately declared on the Edugate Resource Registry website.  This declaration enables identity providers to identify where attributes are requested by service providers and assist them to define a corresponding attribute release policy.

1.2     Scoped Attributes

eduPersonPrincipalName and eduPersonScopedAffiliation are two examples of scoped attributes. Identity providers must ensure that the value of the scope that is asserted matches the organisations primary registered domain name as used on the organisations primary website. Sublevel scopes below the primary registered domain name are permitted.

1.3     Attribute Release Policies.

The Edugate Resource Registry website serves as the system of record for Identity Provider attribute release policies. Identity members must ensure that the attribute release policy recorded within the Edugate Resource Registry accurately reflects the attribute release policy defined for that Identity member within the configuration of the identity providers system.  Once a policy is defined, all other members with access to the Edugate Resource Registry will have visibility of the policy.

The Edugate Resource Registry can generate Federation Metadata tailored for each identity provider that reflects the members attribute release policy which can be dynamically applied by some identity provider systems such as SimpleSAMLphp, members availing of this functionality must routinely ensure that the policies are being dynamically applied when changes to the policy are made on the Edugate Resource Registry website.

The Edugate Resource Registry can dynamically generate Shibboleth 2 attribute filter files that can be downloaded by Shibboleth Identity Provider software on a periodic basis, members availing of this functionality must routinely ensure that the policies are being dynamically applied when changes to the policy are made on the Edugate Resource Registry website.

2       Name Identifiers

All members of Edugate must adhere to the NameID requirements as set out in the  SAML2 Web-SSO Interoperable Profile at a minimum.

3       Federation Protocol

The federation supports the protocols SAML2 Web-SSO Interoperable Profile. Members must support this all the bindings and message contents of this profile as a minimum.

Members must accept that the federation operator may add support for additional protocols or profiles in the future, where the federation operator declares to members that support for additional protocols or profiles is mandatory, members will have a two year period to support these additional protocols or profiles. 

Members must also accept that the federation operator may or adopt changes made to the SAML2 Web-SSO Interoperable Profile, where the federation operator declares to members that support for the amended protocol is mandatory; members will have a two year period to add support for the amended protocol.

4       Federation Metadata

The SAM2 Web-SSO Interoperable Profile mandates the use of the SAML V2.0 Metadata Interoperability Profile Version 1.0.  Members must ensure that the Edugate Federation Metadata is applied when their identity or services systems are first commissioned. Where the federation operator has notified members of a change to the metadata the changes to the Federation Metadata must be applied within (2) two working days.

Members must nominate a contact person and contact email address that will be embedded within the Federation Metadata, these details may be used by members to identify the person who has responsibility for a fellow member’s federation service.

The organisation names, as declared on the relevant Identity Member or Provider Member agreement will be used to fulfil the organisation element for the member in the Federation Metadata.

Members must ensure that the validity periods declared within the Federation Metadata are enforced by their service of identity systems.

4.1     Certificates

The use of self signed certificates is permitted for the exchange of SAML messages, however, it is recommended that members use a certificate signed by a well known CA. The use of CA issued certificates is required for any endpoint that is secured by SSL or TLS where that endpoint will be invoked in a users web-browser during authentication and authorization.

The Federation Metadata will contain embedded certificates for each entity, the Federation Metadata will not include a list of CA certificates.

Members must ensure that the expiry dates of certificates are monitored and certificates renewals are submitted to the federation operator at least one week before the expiry date.

5       Discovery or Where are you from service (WAYF).

The federation operator will provide a Discovery Service compatible with the OASIS Identity Provider Discovery Service Protocol and Profile[iii]. Service providers may operate their own discovery services. Service providers may agree with other identity provider on how discovery will be handled, where such an agreement does not exist the service provider must provide a discovery service that will instigate an authentication request that conforms to the  requirements on SAML2 AuthenticationRequest’s as set out in the Interoperable SAML 2 Web Browser SSO Deployment Profile.

6       Logging

Identity providers must maintain logs with sufficient detail so as to correlate its users with a SAML2 authentication statement. These logs must be maintained for a minimum period of one month. Identity providers may maintain logs for longer periods to meet the organisations policy on log retention or to meet any requirements as set out in Irish law.