Modularity and IAM Stack focuses on containerizing the Univention Management Stack for deployment in modern data centers and clouds. The goals are to deploy each module in multiple instances for scalability and high availability, use a service-oriented API-first architecture, and deploy on platforms like Kubernetes and Sovereign Cloud Stack. Key aspects include containerizing IAM services like OpenLDAP, UDM, and Keycloak for SSO and federation; using the UDM REST API as the primary access point; and rethinking service provisioning to use an event queue instead of LDAP listeners. Challenges include orchestrating services in Kubernetes and ensuring high availability and scalability of the containerized LDAP database.
1. Modularity and IAM Stack
Container Strategy in UCS
Arvid Requate
Univention GmbH
requate@univention.de
2. From UCS Appliance to Service Oriented IAM Architecture
●
UCS Appliance: Debian based Operating System
●
Appcenter: simple domain wide deployment and integration of services
●
UCS core value lies in IAM and related APIs
●
Operation in data centers demands containerization
3. Goals
●
Deployment in modern data center environments and cloud services
●
Focus on service, separation from platform
●
Standardized deployment
●
Scalability and High Availability of Univention Management Stack
●
Each module shall be deployed in several instances
●
API first
●
User interfaces consume those APIs
●
Decoupling of development areas
●
Deployment on arbitrary (Linux) operating systems (with tradeoffs re: scalability)
4. Target platforms
●
Kubernetes as CaaS Plattform
●
Sovereign Cloudstack
●
Partner datacenters, e.g. Phoenix
●
Classic Linux Servers
●
UCS appliance (Debian)
●
Other Linux distributions
5. Sovereign Cloud Stack (SCS): open source reference plattform
●
CSP datacenters provide IaaS (e.g. OpenStack) and CaaS (Kubernets)
●
Sovereign Cloud Stack aims to be open source reference implementation
●
„Openstack based Distribution for CSPs“
●
Univention Management Stack shall be deployable on Kubernetes / SCS.
●
Current state:
●
Containerized OpenLDAP as default IAM backend store for Keycloak
●
Keycloak as main layer for federation between IdPs
6. Services oriented IAM architecture
●
The building blocks: Containerized IAM Services
●
UCS Portal
●
Univention Management Console (UMC)
●
UDM-REST API
●
SSO with federation
●
OpenLDAP
●
Provisioning
7.
8.
9. API First
●
Univention Directory Manager simplifies IAM
●
Abstracts from LDAP specific implementation details
●
UDM-REST-API as primary entry point
●
Taking the UDM Python API to a HTTP based service architecture
●
Univention Management Console (UMC) uses that REST-API
●
Access to interfaces (APIs) can be load balanced
●
Horizontal scalability
10.
11.
12. SSO: Integration of Keycloak in UCS
●
OpenID Connect & SAML in one solution
●
Federation options to external IdPs
●
LDAP „user federation“, Keycloak only holding „shadow“ accounts
●
Basic 2FA options
●
Containerized operation with HTTP configuration API
●
Keycloak 18 (Keycloak-X architecture) with UCS themed login screen
●
First class IAM component, enhancing OpenLDAP
13. SSO: Keycloak User Federation + Ad-Hoc provisioning
First Broker
Login Flow
Keycloak SSO
Entrypoint
MS ADFS
First User Access
14. SSO: Keycloak App in Appcenter
●
Keycloak container will be offered as optional app
●
Alternative to simpleSAMLphp and Kopano Konnect
●
Later: HA integration suitable as full replacement for UCS SSO
●
We need that component for the data center
●
And also directly build it into the UCS appliance
●
Goal: Keycloak as standard IdP for UCS appliance and data center
15. Challenges
●
Service orchestration, configuration and discovery in Kubernetes
●
LDAP schema & ACL extensions
●
Live update via cn=Config
●
Persistence of reference configuration for re-provisioning
●
Cattle vs Pet
●
Robust & efficient scaling of LDAP – Testing, testing, testing...
●
High availability for Primary: Multiprovider replication
●
UDM-Rest as sole authorized writer, UID allocator
16. Thanks for you attention!
Arvid Requate
Univention GmbH
requate@univention.de
18. Rethinking service provisioning
●
UDM-REST-API as primary entry point
1) Writes to Identity Store via LDAP
2) Feeds events into queueing system
●
Containerized workers
1) Consume events from queue
2) provision Apps and external Services
●
In contrast: Listener modules used to be fed by LDAP
19. Rethinking LDAP replication
●
Let OpenLDAP handle replication of LDAP data natively
●
syncrepl: LDAP Content Synchronization (RFC4533)
●
Allows: High-Availability with Multiprovider replication
●
Listener/Notifier can be phased out
●
Translog
●
Listener cache