Configuring Renku for a restrictive authentication via SWITCH edu-ID

Hello admins !

This is my attempt to document some of the steps taken during the setup of an edu-ID based authentication at the University of Fribourg (UniFR). We, at UniFR, had been testing a Kurbenetes based Renku instance on SWITCHengines since Dec’20 with immense assistance from the SDSC team (big shout out to @pameladelgado and @andreas !). Of late, we have a formal institutional platform, Renku@UniFR, mainly for teaching purposes.

First, a bit of context.

Since Jan’20, UniFR had switched to edu-ID for most of its services. Thus having a SWITCH edu-ID based access seemed the most logical way to provide Renku@UniFR to the UniFR community. However, we quickly ran into two issues :

  1. Practical - SDSC members were not sure how to restrict access to only the UniFR community for our institutional Renku instance. And nobody at UniFR knew how to configure edu-ID for the Keycloak component of Renku.
  2. Theoretical - Reaching out to the SWITCH AAI/edu-ID team was productive but not conclusive (thanks @rrrrrok and @pameladelgado !). Further, the SWITCH AAI/edu-ID team didn’t seem to get our problem because it goes against the idea of an edu-ID, as anyone in the world can create one for themselves ! The main argument of SWITCH being that edu-ID is meant to open up access and not used to restrict it.

Luckily, the SDSC team had already setup edu-ID for their Renkulab instance by following some specific documentation for Keycloak prepared by Etienne Dysli-Metref from the SWITCH AAI team. We followed this documentation (available on request) until we had Renku@UniFR open to anybody with a SWITCH edu-ID like with Renkulab. Building upon this documentation, below we provide screenshots showing what steps we took in order to achieve our stated goal : provide access only to UniFR users via SWITCH edu-ID.

In Keycloak we first have to define a SAML Identity Provider (IdP) which we named it to SWITCH edu-ID. One of the steps involved requires the addition of the edu-ID X509 (signing) certificate for this IdP which was directly imported from http://metadata.aai.switch.ch/entities/eduid via the Keycloak interface. However, after many trials we realized with @rrrrrok that we also needed to manually add the UniFR X509 (signing) certificate available from http://metadata.aai.switch.ch/metadata.switchaai+idp.xml. The certificates were separated by a comma (see below).

Along with the Keycloak configuration, one also has to add a new resource description in the AAI Resource Registry. This configuration is relatively straightforward (with the help of the SAML2 metadata wizard) but the most important section for our objective lies in “7. Intended Audience and Interfederation”.

AAI_Resource_Registry

Towards the end of this section one can configure the default/specific audiences. Along with @rrrrrok and @pameladelgado, we tried multiple combinations over several weeks before we hit upon the right one which is shown in the final screenshot below. It consists of :

  • excluding all of the Default Intended Audience,
  • including only UniFR and SWITCH edu-ID in the Specific Intended Audience and
  • excluding the SWITCH edu-ID Private Identity.

Note that each Higher Educational Institution (HEI) has an AAI Resource Registry Administrator who has to approve every change made in the resource registry. Once approved by an admin it takes approximately 2-3 hours before this change is propagated and effective for your resource. This, as you may have guessed, can be painful when testing multiple configurations.

I hope this post finds some use when deploying Renku in other HEIs across Switzerland and avoids re-testing (inventing) the wheel in some cases.

3 Likes

Thanks so much for this detailed post @champost! It’s super confusing for anyone encountering this for the first (or third) time, I’m glad we have a reference to point to now.