The technical functions of a Swiss edu-ID service consist of two main building blocks: access management (AM) and identity management (IdM). Within the SWITCHaai federation, the core of the AM functionalities are provided by Shibboleth, while the IdM-processes are implemented at the universities with a variety of products.
While it is clear that the Swiss edu-ID has to be compatible with SWITCHaai, it is basically an open question on what product stack it should be based. Between November 2014 and January 2015 SWITCH conducted a request for information (RFI) to get an overview of the current AM (and partly IdM) products on the market. In the RFI it turned out, that both Shibboleth and Forgerock/OpenAM are valid candidates to build the AM functions of the Swiss edu-ID framework.
The mayor motivation to consider Forgerock/OpenAM is because of two assumed advantages it has over Shibboleth:
- It supports OAuth2 and OpenID Connect out of the box. Both are protocols that may become more important in the near future.
- It can be complemented with OpenIdM – the IdM solution of the Forgerock suite.
Shibboleth has a modular architecture and could be extended with other protocols than SAML. It has OAuth 2.0 and OpenID Connect support on its roadmap, however the status is “under discussion”.
But – is OpenAM compatible with SWITCHaai?
It is imperative that the Swiss edu-ID is compatible with SWITCHaai. We therefore conducted a proof-of concept (POC) at SWITCH with one main question:
Can an IdP based on OpenAM be integrated in the SWITCHaai federation, and what are the issues or limitations?
We have evaluated the compatibility with four use-cases.
1. Setup and first login
The system was set up in just a few hours, including a basic configuration of SAML.
2. Integration in SWITCHaai federation
consisting of …
- attaching an SP by reading the SWITCHaai metadata file. OpenAM was able to read the metadata file. However, reading a single entity takes several seconds, and our metadata file consists of 900 entity descriptors. To maintain the current pace of an hourly metadata update, optimizations would have to be implemented.
- verification of the metadata file signature. This works, but only if the certificate chain is imported manually.
- releasing attributes to an SP. Releasing attributes to the test SP aai attribute viewer worked fine.
- attribute backchannel request of the SP. This works, but only after a little tweak in the SP configuration. (Meanwhile, Forgerock has issued a change request to adapt the behavior of OpenAM).
3. Filtering Attributes
Filtering attributes based on an attribute release policy in the IdP is not natively supported by OpenAM. To test the flexibility and extensibility of OpenAM we asked a consultant to implement this feature.
It took the engineer about one day to implement a fully working attribute release policy filter (just without support for regular expressions). One day, that’s quite fast. Although it is a POC and not a production-grade implementation, this is impressive.
4. Releasing Attributes with User-Consent
User consent is not natively supported by OpenAM. Within one day the engineer was able to develop a basic version of a user consent workflow. In this basic version the IdP only remembers that the user has given the consent to release attributes to a particular SP, but not for which individual attributes. Still, this shows, that a fully functional user consent workflow could be implemented in a few days.
5. OpenID Connect Functionality
Tests with OpenID Connect were not part of the POC, but since it was just available we had a look at it too. As expected, the setup was straight forward, and the test was successful.
Our Conclusion
The proof-of-concept clearly showed that it would be possible to integrate an OpenAM-based IdP into our SWITCHaai federation, which is predominantly based on Shibboleth for SPs and IdPs. The very basic functions work out of the box. To get the full set of functions that we require for our federation, some optimizations and developments would be necessary. We estimate that a skilled developer can accomplish this in 1-2 weeks.
Shibboleth, on the other hand has a modular architecture and OAuth2/OpenID Connect support might be added in the future. Whether this happens or not will depend on the demand in the Shibboleth community.
As it is not clear at what time OAuth2 and OpenID Connect will become important, we have decided to continue building the Swiss edu-ID on top of Shibboleth. As soon as new requirements emerge we will re-evaluate OpenAM – now on a much better basis to estimate the required efforts for its deployment.