Single Sign On is a user experience we do not want to miss today. Keycloak is an open source software maintained by RedHat, which we prefer at fairkom when it comes to stream line the authentication and authorisation at organisations with complex groups and roles. We have deployed several Keycloak instances at customer projects and we maintain a large one for our own fairapps cloud service portfolio. Some of them allow to sign in with other identity providers (IdPs), such as Google or AppleID.
However, when users should be able to choose from dozens or hundreds identity providers, that users should be able to choose their login from, maintenance gets tricky. The academic community has established a mechanism with large xml files, containing all meta information, that are merged and maintained by national network centers such as ACONET in Austria. Keycloak has no built-in feature to read such a metadata file. Our first approach was a metadata importer, that reads all the IdPs, creates the config within Keycloak and after passing some filters adds for each valid IdP a button to the login screen.
When researching for good practices, we investigated some modern proxy and discovery services. The flow below shows how the Keycloak, SATOSA proxy and a discovery service components interact to authenticate a user against the ACONET federation using an OIDC to SAML bridging mechanism.
- User: The user attempts to access a protected resource.
- Keycloak: Receives the request and forwards it to the SATOSA proxy as an OIDC authorization request.
- SATOSA Proxy: Redirects the user to the Discovery Service (WAYF) to select an Identity Provider (IdP) from the ACONET Federation.
- Discovery Service: The user selects their IdP, which is passed back to the SATOSA proxy.
- IdP: The SATOSA proxy forwards a SAML authentication request to the selected IdP. The IdP authenticates the user and returns a SAML response.
- SATOSA Proxy: Converts the SAML assertion to an OIDC token and sends it back to Keycloak.
- Keycloak: Grants an access token to the user.
- User: Uses the access token to access the protected resource. Keycloak may additionally validate the token against the ACONET federation before granting access.
We do have now our own set of docker images to roll out SSO for applications at any member organisation. In fact what we could achieve is a modern replacement for good old Shibboleth which we also can deploy in kubernetes in a high availabliity (HA) setup.
We would like to thank the professional support at ACONET and colleagues at TU Vienna, who had been working on this challenge for the fairdata project, netidee foundation, Universität Innsbruck (who sponsored an online workshop series in 2021+2022) and the Austrian RIS-Synergy fund for supporting our work on those issues.
Do not hesitate to contact us to analyze the identity management tools in your organization. We know how to stream line the flows, even within heterogeneous landscape including LDAP, AD and 2FA.
