--- # Keycloak Knowledge Sharing ###### CERN IT-PW-IAM --- # CERN AAI Architecture  --- # 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 ---- # Realms 2 - "Guest" - LDAP for "legacy" email/password guests - Inbuilt Users for "new guests" - "Provider Realms" - "MFA" (LDAP + Yubikey) - "u2f" (LDAP + Authenticator app) - "Kerberos" - Clients for all = CERN Realm ---- # HA Setup - Kubernetes --- # EduGAIN Setup - Satosa as proxy (both incoming and outgoing) - Using PyFF for metadata query and discovery - Will move to thiss.io (seamless access) iin coming months ---- # CERN as an SP Proxy  ---- # CERN as an IdP  --- # 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) ---