--- # Keycloak Knowledge Sharing ###### Co-organised by INFN and CERN --- # CERN AAI Architecture ![](https://codimd.web.cern.ch/uploads/upload_2c135d0160183d230f704e3d91c2c164.png) --- # CERN Keycloak Setup ---- # Overall Impression - Positives - Keycloak community recently much more active (see mailing lists) - Tool works well - Negatives - Scaling issues (pull request submitted, should be in KC 9) - Doesn't completely fit CERN use case - Some functionality disabled (e.g. User Profile) - Configuration done via API rather than allowing end users admin access - KeycloakX on the horizon ---- # MFA - Requirements - Allow application owners to choose whether they require MFA or not, or for specific roles - Users can force MFA for their account - Command line - PAM module written for command line - Plugin to extend Keycloak API to validate 2nd factor tokens - Portal for users to register their token ---- # Realms - "CERN" - Clients = all CERN clients - Providers = Social IdPs, Satosa SP, LDAP, Kerberos, MFA Realm - "eduGAIN" - Clients = Satosa IdP - Providers = LDAP - "Provider Realms" - "MFA" (LDAP + Yubikey) - "u2f" (LDAP + Authenticator app) - "Kerberos" - Clients for all = CERN Realm ---- # HA Setup - Since we are using Puppet to configure our servers, we went for [Standalone-HA Clustered Mode](https://www.keycloak.org/docs/latest/server_installation/index.html#_standalone-ha-mode) with some HAProxy servers in front - The trickiest part was configuring the communication between the Keycloak servers - To solve it we configured [JGROUPS and JDBC_PING](https://www.keycloak.org/2019/04/keycloak-cluster-setup.html) --- # EduGAIN Setup - Satosa as proxy (both incoming and outgoing) - Using PyFF for metadata query (beware - this will becoming unsupported at some point in the future, join the IdPy mailing lists!) eduGAIN SP is already deployed. eduGAIN IdP requires a few tweaks and a well controlled deployment ---- # CERN as an SP Proxy ![](https://codimd.web.cern.ch/uploads/upload_fe4d176be77b33b98f1d4dfbffd53388.png =700x450) ---- # CERN as an IdP ![](https://codimd.web.cern.ch/uploads/upload_223ed8bf2735139bb256366896469def.png =700x450) --- # Client Registration Keycloak admin priveleges provide too much flexibility for the number of client owners that we have - Authorization Service API (home built) calls the Keycloak API to register clients - Application Portal (ReactJS) built to make life as easy as possible for developers, and only expose parameters that developers should be touching --- # Authorization - Not using Keycloak's own authorization - On each authentication, looking up roles per use per application (controlled via Authorization Service API) --- # User Migration - AD (LDAP) currently configured as User Federation - Users will be migrated to FreeIPA - FreeIPA will be added as a User Federation to Keycloak - Users will be removed from AD Care required to maintain attributes (e.g. AD GUID has been used as an identifier) ---
{"title":"Keycloak Knowledge Sharing","type":"slide","slideOptions":{"theme":"cern3","transition":"slide"}}