Compatibilidad con múltiples OIDC y acceso con nombre.

01

1. Modelo recomendado

El patrón arquitectónico objetivo, que no es una característica automática de cada versión, consiste en que las aplicaciones confían en un único dominio de cliente en Keycloak, que gestiona las identidades del cliente, DERS y, posiblemente, del socio de implementación. El propietario del dominio, el soporte del intermediario y la responsabilidad operativa se confirman en la implementación específica.

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. ¿Por qué una puerta de enlace de inicio de sesión centralizada?

Keycloak actúa como intermediario: las aplicaciones solo conocen un punto de inicio de sesión de confianza, mientras que los empleados del cliente, DERS y el socio siguen iniciando sesión con la cuenta de su propia organización.

• Las aplicaciones autentican los inicios de sesión de forma uniforme y no necesitan conocer cada proveedor de identidad por separado.
• Un cliente puede cambiar su sistema de inicio de sesión personal sin necesidad de reinstalar todas las aplicaciones.
• DERS o un socio utiliza su propio sistema de inicio de sesión multifactor o sin contraseña y su propia gestión de cuentas dentro de su organización.
• Las reglas para convertir grupos administrados en roles de aplicación siguen estando bajo el control de la instalación específica.
• La auditoría preservará el origen de la identidad. Dos cuentas con el mismo correo electrónico no se consideran automáticamente pertenecientes a la misma persona.

03

3. Establecer un proveedor de identidad (IdP) para el cliente.

1. Reemplace la URL del emisor/descubrimiento, el ID del cliente, el secreto o las claves, las URI de redireccionamiento permitidas y las reglas TLS.
2. Permita únicamente los ámbitos y las declaraciones necesarias: asunto estable, nombre para mostrar, correo electrónico posiblemente verificado y grupos aprobados.
3. Configura un flujo de primer inicio de sesión sin la posibilidad de vincular automáticamente una cuenta basándose únicamente en el correo electrónico.
4. Asigne los grupos aprobados a las funciones básicas de la aplicación; las funciones del proceso se asignan según las reglas del proceso específico.
5. Prueba el inicio de sesión, el cierre de sesión, el cambio de grupo, el bloqueo de cuentas y los usuarios sin un rol permitido.

04

4. Establecer un proveedor de identidad asociado (DERS/IdP) para obtener soporte.

1. Utilice un alias de agente independiente y un cliente independiente para un entorno de cliente específico.
2. Permitir únicamente cuentas de trabajo con nombre; deshabilitar las cuentas de soporte compartido o de administrador.
3. Exija la autenticación multifactor o una clave de acceso en el proveedor de identidad (IdP) principal y apruebe el nivel de autenticación si forma parte del contrato.
4. Deduzca el enfoque a partir del grupo de propósito para el cliente y el entorno específicos, no del empleo general en DERS/socio.
5. Mapea el rol mínimo requerido; limita el tiempo y audita los permisos elevados.
6. Una vez finalizada la intervención, verifique la eliminación del grupo, la finalización de la sesión y la invalidación del token de actualización.

05

5. Ciclo de vida automático sin creación de cuenta local.

• El primer inicio de sesión puede crear automáticamente una cuenta desde un emisor de confianza y un sujeto estable.
• El rol se crea a partir de una reclamación/grupo gestionado; no a partir de texto libre ni del dominio de correo electrónico en sí.
• Cualquier cambio o eliminación en el proveedor de identidad (IdP) de origen entrará en vigor a más tardar en el tiempo de sesión/token definido.
• Si se requiere la eliminación inmediata sin que el usuario inicie sesión, complemente con el cierre de sesión mediante canal secundario, SCIM u otro canal de ciclo de vida compatible; la intermediación OIDC por sí sola no garantiza esto.
• Una prueba periódica verificará la desactivación, la expiración de la sesión, el cambio de rol y la auditoría de la identidad original.

06

6. ¿Qué debe incluirse en la auditoría?

• emisor y sujeto del IdP original como un par inmutable
• identificador de usuario interno, nombre para mostrar y organización
• Grupo de origen/reclamación y función de la aplicación resultante
• hora de inicio de sesión, nivel de autenticación e identificador de sesión
• Cada aumento de autorización, su motivo, aprobación y vencimiento.
• acciones en el proceso bajo una identidad nombrada, no bajo una cuenta de integración

07

7. Prueba de aceptación

1. Un usuario cliente con el grupo correcto inicia sesión y solo ve su ámbito de aplicación.
2. Un usuario cliente sin pertenecer a un grupo puede iniciar sesión, pero no recibirá permisos de proceso o se le denegará el acceso según la política establecida.
3. Un empleado de DERS/socio designado solo recibirá el alcance compatible de un entorno específico.
4. Un segundo trabajador que no pertenezca a un grupo con un propósito especial no tendrá acceso.
5. Eliminar un grupo invalidará el acceso en el momento declarado.
6. La auditoría permitirá distinguir entre dos personas con el mismo nombre o correo electrónico pertenecientes a diferentes emisores.