Multiple OIDC and named access support

01

1. Recommended model

Target architectural pattern, not an automatic feature of every release: applications trust a single customer realm in Keycloak, which brokers the identities of the customer, DERS, and possibly the implementation partner. The realm owner, broker support, and operational responsibility are confirmed by the specific deployment.

Aplikace SIFYBOX
  issuer: https://<KEYCLOAK_FQDN>/realms/<CUSTOMER_REALM>
  client: <SIFYBOX_CLIENT_ID>

Keycloak — broker identity
  1. customer-idp
     issuer: https://<CUSTOMER_IDP>/...
     uživatelé: zaměstnanci zákazníka

  2. support-idp
     issuer: https://<DERS_OR_PARTNER_IDP>/...
     uživatelé: jmenovití pracovníci podpory

Jednoznačný auditní klíč
  external_identity = <issuer> + "|" + <subject>

Autorizace
  skupina/claim z domovského IdP
    -> mapper v Keycloaku
    -> omezená aplikační role
    -> procesní oprávnění v konkrétní instalaci

02

2. Why a central login gateway

Keycloak acts as an intermediary here: applications know only one trusted login point, while employees of the customer, DERS, and partner continue to log in with their own organization's account.

• Applications authenticate logins in a uniform manner and do not need to be aware of each identity provider separately.
• A customer can change their home login system without rebuilding all applications.
• DERS or a partner uses their own multi-factor or passwordless login and their own account management within their organization.
• The rules for converting managed groups to application roles remain under the control of the specific installation.
• The audit will preserve the origin of the identity. Two accounts with the same email are not automatically considered to be the same person.

03

3. Establishing a customer IdP

1. Replace issuer/discovery URL, client ID, secret or keys, allowed redirect URIs, and TLS rules.
2. Allow only necessary scopes and claims: stable subject, display name, possibly verified email, and approved groups.
3. Set up a first-login flow without the ability to automatically link an account based on email only.
4. Map approved groups to basic application roles; process roles are assigned according to the rules of the specific process.
5. Test login, logout, group change, account blocking and users without an allowed role.

04

4. Establish DERS/partner IdP for support

1. Use a separate broker alias and a separate client for a specific customer environment.
2. Allow only named work accounts; disable shared support or admin accounts.
3. Require MFA or passkey in the home IdP and pass the authentication level if it is part of the contract.
4. Deduce the approach from the purpose group for the specific customer and environment, not from the general employment at DERS/partner.
5. Map the lowest required role; time-limit and audit elevated permissions.
6. After the intervention is complete, verify the removal of the group, termination of the session, and invalidation of the refresh token.

05

5. Automatic lifecycle without local account creation

• The first login can automatically create an account from a trusted issuer and a stable subject.
• The role is created from a managed claim/group; not from free text or the email domain itself.
• A change or removal in the source IdP will take effect no later than the defined session/token time.
• If immediate removal is required without user login, supplement with back-channel logout, SCIM, or another supported lifecycle channel; OIDC brokering alone does not guarantee this.
• A regular test will verify deactivation, session expiration, role change, and audit of the original identity.

06

6. What must be in the audit

• issuer and subject of the original IdP as an immutable pair
• internal user identifier, display name and organization
• source group/claim and resulting application role
• login time, authentication level and session identifier
• each increase in authorization, its reason, approval and expiration
• actions in the process under a named identity, not under an integration account

07

7. Acceptance test

1. A customer user with the correct group logs in and sees only their scope.
2. A customer user without a group can log in, but will not receive process permissions or will be denied according to policy.
3. A named DERS/partner employee will only receive the supported scope of a specific environment.
4. A second worker without a special purpose group will not gain access.
5. Removing a group will invalidate access at the declared time.
6. The audit will distinguish two people with the same name or email from different issuers.