Connecting an organisations authoritative credential store to the federation will require the deployment of an Identity Provider Service. Typically the authoritative credential store will be the the organisations staff directory or the campus staff/student directory, but for those organisations who have a campus-only (or enterprise) Single-Sign-On (SSO) solution or standard authentication scheme, integrating the identity provider solution with the organisations current solution may extend the current solutions benefits beyond the campus. This guide will focus on the integration of the identity provider service with the organisations directory, and explain how the identity provider service can be used to provide SSO beyond the traditional boundary of the organisation.
Selecting the identity provider platform.
Institutions will have a choice of open source or commercial identity provider software, or a hosted/managed solution.
There are a number of commercial identity provider software offerings on the market, here are some of the more well known products;
- Oracle Identity Federation
- Tivoli Federated Access Manager
- Microsoft Active Directory Federation Services (configured for SAML rather that the default WS-*).
- Eduserv OpenAthens LA
(an extensive list of SAML IdP products is maintained at http://en.wikipedia.org/wiki/SAML-based_products_and_services)
In the case of any of the above products, or any other product, the vendor should be able to provide a statement on how compliant the product is with the SAML2 Interoperable Profile. Another significant concern when selecting identity provider software is how the software handles remotely hosted SAML2 federation metadata that contains multiple entities and is subject to frequent updates (and how it handles XML digital signatures contained within the metadata).
The identity provider software may need to pull user data from multiple repositories if the directory cannot fulfill the Edugate federation schema. A virtual directory service can be used an intermediary between multiple repositories and the identity provider so that the data is presented through a standard LDAP interface to the identity provider. Even if the directory contains sufficient user data, the software may need to map or transform the the current directory schema onto the federation schema. Another consideration is the release of attributes over SAML to each participating service provider, if the software support the automatic release of attributes based on a presence of SAML2 metadata 'RequestedAttribute' tag in a Service Providers metadata, then this concern could be addressed as the Edugate federation metadata can be tailored for each institution so that the release of attributes can be automatically applied from the Edugate Resource Registry into the metadata feed provided by Edugate.
Where a commercial offering does not support the automatic processing of;
- remotely hosted metadata that is frequently updated
- the SAML2 'RequestedAttribute' tag.
- digitally signed metadata verification.
but conforms the the SAML2 Interoperable Profile, the software may still be used provided the administrator of the software manually applies the metadata changes and attribute release policies in accordance with the Edugate membership agreement's provisions.
Open source software
SimpleSAMLphp and Shibboleth are two open source projects that are known to provide software compatible with the Edugate federation.
Shibboleth is a Java based application that requires the use of a Java web-server such as Tomcat, Jetty or other J2EE compliant web server. Shibboleth can authenticate users using it's own login form (that relies upon LDAP, a database or other JAAS authentication scheme) or it can rely upon the web-servers REMOTE_USER http header to authenticate users making it easy to integrate with other authenticaiton systems that have web-server plugins. HEAnet can assist organisations with the deployment of Shibboleth identity provider services and provide support assistance where problems arise with Shibboleth's processing of the Edugate metadata, Shibboleth attribute release filters generated by the Edugate Resource Registry or the federation WAYF (Discovery Service). HEAnet will also assist Shibboleth identity providers who have difficulty interoperating with any of the service providers within the federation. Further assistance and support can be obtained from the Shibboleth community or a third party.
SimpleSAMLphp is known to be interoperable with the Edugate federation and supports remote metadata containing digital signatures, multiple entities and the SAML2 Metadata 'RequestedAttribute' tags. The software deployment is lightweight as it is built on PHP and thus only requires PHP support from the webserver. While HEAnet have extensive experience with the SimpleSAMLphp identity provider software we cannot offer assistance or support for SimpleSAMLphp due to the numerous way this software can be configured. Support and assistance should be sought from the SimpleSAMLphp community.
There are a number of solutions in the marketplace that offer a hosted Identity Provider. Vendors who self-certify that their services are compliant with Edugate will be added to the published list of vendors. Organisations considering a hosted identity provider are recommended to consider the following topics when assessing a solution.
Some hosted identity providers offer a service where user accounts are provisioned into the vendors service, this results in users having more than one account (i.e. where one account is maintained within the organisation, and another in the vendors service). Account synchronisation between both identity stores may be offered, however it is not always possible to synchronise passwords, and where it is possible there will always be some delay in synchronising password changes. Therefore, the synchronisation schedule and synchronisation capabilities should be considered when assessing such services. While there may be solutions for the account provisioning, account decommissioning is of equal importance in order to remain in compliance with the Edugate membership rules.
Access to organisations directory.
While it is possible to connect a hosted identity provider with the institutions directory service for authentication purposes, the connection security should be considered. VPN solutions or secure directory protocols (i.e.. LDAPs) as well as firewall rules should be considered to enhance the security of the connection. Another consideration is the scope of directory searches and the security of the vendors service (if the vendor is compromised, then the institutions directory service may be exposed as a result).
As with any cloud service that handles personal data, the legal jurisdiction covering the operation of the service should be considered.
Identity Members must be capable of producing SAML messages from audit or debug logs for troubleshooting access problems (as outlined in the Edugate rules).
Statistics may or may not be desired, the following statistics should be considered;
- What are the top 5 services users have been accessing?
- How many authentications are performed per day?
- How many unique users have used the service in the last week?
- How many failed authentications have there been in the last hour?
Edugate can centrally consume anonymised statistics from the Raptor statistics collector (Raptor ICA), it can also consume realtime statistics from a URL containing data of of the form
Resource Registry Compatibility
Edugate metadata containing the metadata of all Edugate participants is published at http://edugate.heanet.ie, however, Edugate participants can customise the content of the metadata to include service providers that are non-members of Edugate, these are referred to as bilateral trusts (examples include; Google Apps, Office 365 or the participants own internal services). If it is expected that the identity provider solution will be used for non-Edugate services then the solution should be able to consume the customised metadata or allow for bilateral trusts to be established using the vendors solution. Vendor solutions should (ideally) be capable of consuming the Edugate metadata in an automated manner, otherwise frequent manual updates will be required.
Edugate also provides an optional service that produces a Shibboleth attribute filter policy that can be consumed by Shibboleth based identity providers. While this feature is offered as an optional service, identity providers are obliged to keep their current attribute release policy up to date in the Edugate Resource Registry, so another consideration will be the ease of keeping the policy defined in the Edugate Resource Registry synchronised with the policy defined in the vendors solution (either manually or automatically).