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:
-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.
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.
Specialised in IAM (security, access control, identity management) and Open Source integration, settled in 2004 by IAM industry veteran, JANUA offers high value-added products and services to businesses and governements with a concern for Identity Management and Open Source components.
JANUA provides better security, build relationships, and enable new cloud, mobile, and IoT offerings from any device or connected thing.
Les derniers articles par Olivier Rivat (tout voir)
- Understanding Keycloak RedHat SSO Authentication - 25 mars 2019
- Using apache2 mod_auth_openidc module with Keycloak (OpenID Connect) - 21 mars 2019
- Protecting Keycloak RedHat SSO with a Reverse Proxy - 20 mars 2019