---
# Keycloak Knowledge Sharing
###### Co-organised by INFN and CERN
---
# 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
- "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

----
# 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)
---
# 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"}}