Secure public access with EnBW IDM Keycloak as identity provider

ID
ADR 9.1
Status
accepted
Date
unknown (before 2026-08-17)
Deciders
KBP team, Sales Capabilities Architect
Tags
security authentication identity

This record was written before the Arc42 documentation was imported into the repository on 2026-08-17 and was retrofitted with ADR metadata afterwards. The original decision date is not recorded. The resulting concept is described in the cross-cutting concept Authentication (section 8.3).

Business Case & functional requirements

Public access shall be enabled for KBP and therefore we need to restrict access to KBP to fullfill security requirements.

Data Protection Category Estimation:

For Production the demand for data protection is pretty high, there we shall consider using high security standards as conditional access policy.

For test (test, integration) we have pseudonimized data, there we won’t need that high security standards there.

Proposal access rules Production:

  • only allow SmartClient or virtual SmartClient or Büko or go4smart without the need for MFA (this means that Devs can’t try to reproduce issues running application locally on production anymore without SmartClient, which should be ok)

Proposal access rules Test:

  • allow SmartClient or virtual SmartClient or Büko or go4smart without MFA
  • allow Any client (Windows/Linux/Mac) with updated security patches, but enforcing MFA asking every 90 days per device (used for external devs) Is it perhaps possible to add KBP_DEV in savvy so that only a specific user group is allowed using any client?)

Considered alternatives / Shortlist

  1. use enbw client certificates to restrict access
  2. setup own conditional access in enpower tenant
  3. reuse enbw/o365 tenant cond. access rules directly by configuring test relationship between enpower/enbw tenant.

Relevant influencing factors

–

Assumptions

–

Decision

Possible options for enabling Conditional Access:

  1. Setup in Home Tenant (enpower)

  2. Setup in Master Tenant (O365 -> main tenant connected to Intunes)

  3. Setup using IDM Keycloak as Authentication/Identity Provider (preferred Option)

Option 1. Setup in Home Tenant (enpower)

According to Sales Capabilities Architect option 1 is not easy to setup because additional configuration and trust settings (which will probably not be allowed) have to be done on the tenants. And Compliance Device Check won’t work.

Pros

  • You have full control about conditional access rules
  • You have full control of your Authentication Endpoint (configuring claims, configuring access to user profile data, Microsoft.Graph, etc)

Cons

  • more configuration is needed to not have MFA multiples times being asked for.
  • compliant device check is not possible because syncrhonized DAP accounts are not connected to Microsoft Intunes.
  • you have the responsible to setup everything correctly (option 3 could just be ordered in Savvy)
  • If MFA is used, you have to setup multi MFA and for people using hardware tan generators, multiple devices would be needed

Option 2. Setup in Master Tenant (O365 -> main tenant connected to Intunes)

According to Sales Capabilities Architect Pfeiffer option 2 is not possible because there won’t be any group synchronization by IDM.

Pros

  • default conditional access rulesets could be used (compliant device, mfa)

Cons

  • You have restricted control about conditional access rules
  • You have restricted control of your Authentication Endpoint (configuring claims, configuring access to user profile data, Microsoft.Graph, etc)
  • Savvy doesn’t work because groups won’t be synchronized by IDM

Option 3. Setup using IDM Keycloak as Authentication/Identity Provider (preferred Option)

Further information regarding IDM can be found here https://myenbw.sharepoint.com/sites/idm/SitePages/IDM-Datennutzung-technisch.aspx

Pros

  • default conditional access rulesets could be used (compliant device, mfa)
  • use authentication as a service by IDM (no responsibility to setup authentication security)
  • easily to setup (can be ordered in Savvy, after Agreement (VZN) regarding data usage is signed with IDM guys)
  • Savvy works as before (ordering groups etc)
  • keycloak is connected to IDM and o365 tenant and can do the heavy load for you (You can also have multiple Auth Endpoints for test/prod to establish different rules)

Cons

  • You have restricted control about conditional access rules
  • You have restricted control of your Authentication Endpoint (configuring claims, configuring access to user profile data, Microsoft.Graph, etc)
  • Currently the availability is only “Best Effort”, which means that it can happen, that keycloak is shutdown for a longer period of time and there is also no 24/7 support to handle issues. All issues will only be solved within usual working hours by idm@enbw.

Solution: 3. Setup using IDM Keycloak as Authentication/Identity Provider

Data needed

User data needed in KBP:

  • KBP Webportal App authentication (groups, claims)
  • user profile ** userid (email) ** firstname ** lastname

User data usage:

  • firsrname/lastname are visualized in our application to show the user who is logged in
  • userid is used to identify the agent when executing tasks for a customer/lead (setting customer marketing permission for the customer being on the phone, creating orders, etc)
  • userId is saved in databases to be able to have a history of user actions for a specific customer (ZAUV database, etc)
  • user data is not available to the public at all

Application data to be protected: customer personal data (birthday, name, address, etc) customer banking data customer account balance customer claims management …