1. Presentation: Architectural principles with Keycloak Redhat SSO
The goal of this paper is to present how it is possible to architect a SSO-LDAP-Identity Manager infrastructure with Keycloak-Redhat SSO.
Keycloak-RedHatSSO allows to register applications which communicate with keycloak-Redhat SSO using SAML or oauth2/openid protocol.
Users are provisioned onto an LDAP database with their corresponding applicative rights.
2. Keycloak-Redhat SSO realm
Keycloak realm is like a territory.
A realm encompasses:
-application
-users
-application roles
-user provision with applicative roles
-Theme login page
-realm users are usually mapped onto a specific LDAP suffix.
3. multi-tenant architecture with keycloak-Redhat SSO
In multi-tenant architecture each tenant has it own specific realm.
tenant isolation is performed defacto using the « realm concept »
In a Saas architecture the application used as Saas has to be deployed within each realm.
Each realm is mapped on a specific LDAP suffix.
It is possible to have only one LDAP database for Cloud Saas architecture, with the database encompassing all realm suffix branches.
4. Using application roles
Application access is filtered throughout application roles.
In order to get access to an application, user needs to be provisioned with application roles.
A typical example is defining application-user and application-admin roles.
User who want to access to this specific application, need to be provisioned with such applicative roles, otherwise access is denied.
5. Using LDAP to provision users- user applicative roles
The typical usage is to provision user in LDAP, and to retrieve them with applicate roles at keycloak/Rh-SSO level.
Applicative roles can be defined at LDAP level within a LDAP group such as Realm roles on a per user basis.
It is possible to put LDAP DB and Keycloak/redhat SSO in automatic sync, so that user hare automatically propagated
at SSO level with their correct applicatives rights.
It is possible to leverage any LDAP server with Keycloak-Redhat SSO, but a natural choice is using DS389/RH-DS.
6. Identity Manager
The identity manager acts as a central repository/placeholder for the users.
The identity manager is central repository (SQL like), where the it is contains the all the user and respective permissions.
From user respective permission, it is possible to deduce user applicative rights.
LDAP users are provisioned from the identity manager, and are also in sync.
any update done at identity manager level on users (creation/deletion/ update of teh users rights) shall get propagated to the LDAP.
7. Synthesis
Following all the design principles described above, with a clear distinction betweens applications/user/ and applicative roles
it is hence possibly to provide a very powerful scalable architecture.
JANUA provides better security, build relationships, and enable new cloud, mobile, and IoT offerings from any device or connected thing.
- New Keycloak online training - 19 janvier 2022
- Sizing Keycloak or Redhat SSO projects - 8 juin 2021
- Keycloak.X Distribution - 28 janvier 2021