How do Research Communities build Authentication and Authorisation Infrastructures that support Federated Identity Management? Which software do they choose and how do they make those critical decisions? Over the coming months we will be speaking with various organisations that have gone through this process and created infrastructure that supports the AARC Blueprint Architecture (AARC BPA*).
For our first FIM4R Community blog, I had the pleasure of speaking with Peter Gietz and David Hübner from DAASI International who have designed and developed multiple solutions, primarily for the DARIAH Community, which supports the Humanities.
Although they were originally in favour of mesh federation, several factors contributed to DAASI International’s strategic decision to invest in solutions that support the AARC BPA. DARIAH’s participating services were stable, supportive, and complied with an existing policy framework that facilitated the transition to the Proxy Model**. At the same time, it was clear that the overhead for each service operator would be significantly reduced by offering the possibility for them to connect to one DARIAH Proxy, rather than manage the complexity of multilateral federation themselves.
The first Proxy deployed by DAASI International used a Shibboleth IdP and a Shibboleth SP instance, plugged together with glue code to provide a single DARIAH IdP for DARIAH services and a single DARIAH SP for authentication sources (such as eduGAIN and LDAP). Shibboleth is a mature product with a wide user base, though was not designed to work as a proxy and required custom code to integrate the two components (Aside: Shibboleth recently announced that it will be enabling the Proxy Model in future!).
The second Proxy deployed by DAASI International was for a different organisation, GWDG, who were to become the operators of DARIAH’s AAI. Since GWDG had significant experience with php, DAASI International chose SimpleSAMLPhp for implementing an equivalent Proxy solution. While SimpleSAMLphp natively supports the proxy model and does not require glue code, which currently is necessary with the Shibboleth solution, DAASI International had to develop various extensions to fully integrate the AARC BPA requirements.
For their most recent Proxy, DAASI International is focusing on a newer candidate – Satosa. Satosa is a python based proxy that supports SAML and OIDC for Identity Providers and Service Providers. Its pluggable architecture is easy to extend; DAASI International has already written plugins for LDAP authentication and account linking, see Figure 1 for further details of the Satosa components used. Satosa is supported by the IdentityPython group and has an active contributor base that has seen the software mature significantly in the past few years to cover more of the components recommended by the AARC BPA. Many Research Communities and Infrastructures have chosen Satosa for their AAIs, including LIGO, eduTEAMs, CERN and many more.
Figure 1: DAASI International’s Satosa Setup
DAASI International sees Satosa as a cornerstone of FIM for Research Communities and is heavily invested. They are using Satosa as the base of their own Access Management component didmos Authenticator, and will soon sponsor a Masters Student to integrate OAuth2 into their Satosa based software stack.
I’ll leave you with a final thought from Peter and David …
“We all agree that this wonderful work is a spin off of the AARC Activity, we should all be thankful for the funding received by the EU.”
Let’s hope that more projects emerge in future to further support Federated Identity Management for Research! You can find links to the software mentioned here in the table below.
|Shibboleth||SAML Service Provider, SAML Identity Provider||https://www.shibboleth.net|
|SimpleSAMLphp||Php based Service Provider Proxy||https://simplesamlphp.org|
|Satosa||Python based Service Provider Proxy||https://github.com/IdentityPython/SATOSA|
* The AARC Blueprint Architecture is a set of technical and policy guidelines that describe an effective AAI for Research Communities
** The model described by the AARC Blueprint Architecture, a key feature being a central Proxy for authentication and authorisation