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 organisations staff directory or the campus staff/student directory. 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;
- Oracle Identity Federation (compatibility unknown)
- Tivoli Federated Access Manager (compatibility tested)
- PingFederate (compatibility unknown)
- Microsoft Active Directory Federation Services (compatibility tested).
- Eduserv OpenAthens LA (compatibility unknown)
(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. and the OASIS SAML 2 Metadata standard (the software must be able to frequently process remotely hosted SAML2 metadata containing multiple entities, and validate an XML digital signature).
The identity provider software may need to pull user data from multiple repositories if the directory cannot fulfil or be mapped to 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 where 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 authentication 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.
- ProtectNetwork (compatibility statement)
- OvertSoftware (compatibility statement)
- SSOCircle (compatibility statement)
- OpenAthens MD (compatibility unknown)
- Gluu (compatibility unknown)
- HEAnet Hosted IdP (Q2 2014)
Organisations considering a hosted identity provider are recommended to consider the following topics when assessing a solution.
1. Account Provisioning
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.
2. Access to organisations directory.
While it is possible to connect a hosted identity provider with the institutions directory service for authentication purposes, the confection 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 confection. 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).
3. Schema compatibility
Where accounts are synchronised (1 above) or accessed remotely (2 above) it is likely that the local schema of the user repository or directory is not directly compatible with Edugate. Therefore it is a good idea to evaluate the solution or software ability to map from one local attribute to an Edugate attribute of a different name (e.g. emailaddress = mail ) or if attributes can be dynamically fulfilled using multiple attributes from the source repository givenname+firstname+@domainname = mail).
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 authentication?
- How many unique users?
- How many failed authentication?
Edugate can centrally consume anonymised statistics from the Raptor statistics collector or directly from a Shibboleth audit log.
6. Branding and Logos
The login page will be presented to your users so it is worth considering it the login page can be customised with the institutions logo and style. Also, Edugate support logo's for each participating service provider these can be displayed on the login page alongside descriptive text of the service the user is being asked to authenticate with.
7. Consent prompt
Sometimes the institution may rely on the users consent before user attributes are provided to participating service providers, therefore another consideration is the support for consent prompts displayed to the end-user.
8. 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.