Configure Keycloak and UCS

Keycloak documentation: https://www.keycloak.org/docs/latest/server_admin

flowchart id_broker-->keycloak-->realm([realm]) realm-->authentication([authentication])-->flows([flows]) authentication-->bindings([bindings]) flows-->browser_simple_idp_flow>browser_simple_idp_flow] flows-->check_right_IdP_flow>check_right_IdP_flow] flows-->first_broker_login_flow>first_broker_login_flow] realm-->IdP([IdP]) bindings -- browser: default flow-->browser_simple_idp_flow IdP--first login flow-->first_broker_login_flow IdP--post login flow-->check_right_IdP_flow IdP-.use as backend.->SAML_IdP UCS[UCS School Server] UCS---->ucs_ldap--->SAML_IdP ucs_ldap[(UCS LDAP)] ucs_ldap-.provisions.->ldap[(ldap)] realm-->ldap-->ldap_bettermarks_id realm-->client_scopes([client_scopes])-->bettermarksID-.mapping.-> ldap_bettermarks_id{{ldap_bettermarks_id}} realm-->clients([clients])-->python-test-client([python-test-client])--include-->bettermarksID{{bettermarksID}} classDef service fill:#EBF1DE, stroke:black classDef library fill:#E4DFEC, stroke:black classDef product fill:#FCD5B4, stroke:black classDef internal fill:#DCE6F1, stroke:black classDef hidden visibility:hidden class UCS,id_broker,keycloak,SAML_IdP,service service class browser_simple_idp_flow,check_right_IdP_flow,first_broker_login_flow, product class authentication,bindings,flows,IdP,realm,clients,client_scopes,python-test-client library class ucs_ldap,ldap internal

---

Legend

flowchart service internal[(internal)] settings([keycloak setting]) flow>keycloak flow] attribute{{attribute}} classDef service fill:#EBF1DE, stroke:black classDef library fill:#E4DFEC, stroke:black classDef product fill:#FCD5B4, stroke:black classDef internal fill:#DCE6F1, stroke:black classDef hidden visibility:hidden class service service class internal internal class settings library class flow product

---

In our setup we have to configure two systems: an UCS@school server and the ID Broker system. The UCS@school server contains the SAML IdP that is the only source of truth when it comes to authenticating user access. The UCS as a backend for the ID Broker, which is the login manager system that can handle different pseudonyms for different client applications. The heavy lifting for OIDC and SAML in the ID Broker is done by the Keycloak system. This allows different groups of settings called realm (think virtualhost in Apache web server). Within Keycloak you can configure the clients (applications) that are allowed to use the system (e.g. a python-test-client or bettermarks). Such clients want to access their specific data and pseudonyms. Client specific access is organized in client scopes, e.g bettermarksID. This client scope in return contains a mapping to an attribute in the local back-end LDAP, e.g. ldap_bettermarks_id. This is how Keycloak knows where to get its data from. The users in the local backend are provisioned from the UCS LDAP.

Now, when a user, using a browser, connects within an OIDC flow or SAML flow, authentication needs to be configured to determine what data is used for this specific user. Several flows are involved when selecting a specific pseudonym that connects a userid from the back-end UCS@school server to a specific client. In the authentication bindings we need to set the default (Keycloak) flow when a browser connects, for example browser_simple_idp_flow. When a user makes contact to Keycloak for the first time, the binding for the first login flow configured in the IdP is used to link the userid to the internal backend. E.g., the flow used here is the “first_broker_login_flow”. After the userid is linked to a user, we need to make sure that the right back-end IdP is used, this is where the “check_right_IdP_flow” is used.