Prise en charge de plusieurs OIDC et accès nommé

01

1. Modèle recommandé

Modèle architectural cible, non inclus automatiquement dans chaque version : les applications font confiance à un domaine client unique dans Keycloak, qui sert d’intermédiaire entre les identités du client, de DERS et, éventuellement, du partenaire d’implémentation. Le propriétaire du domaine, le support de l’intermédiaire et la responsabilité opérationnelle sont définis par le déploiement spécifique.

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. Pourquoi une passerelle de connexion centralisée

Keycloak joue ici le rôle d'intermédiaire : les applications ne connaissent qu'un seul point de connexion de confiance, tandis que les employés du client, de DERS et du partenaire continuent de se connecter avec le compte de leur propre organisation.

• Les applications authentifient les connexions de manière uniforme et n'ont pas besoin de connaître chaque fournisseur d'identité séparément.
• Un client peut modifier son système de connexion à domicile sans avoir à reconstruire toutes les applications.
• DERS ou un partenaire utilise son propre système d'authentification multifactorielle ou sans mot de passe et sa propre gestion de comptes au sein de son organisation.
• Les règles de conversion des groupes gérés en rôles d'application restent sous le contrôle de l'installation spécifique.
• L'audit permettra de préserver l'origine de l'identité. Deux comptes associés à la même adresse électronique ne sont pas automatiquement considérés comme appartenant à la même personne.

03

3. Mise en place d'un fournisseur d'identité client

1. Remplacez l'URL de l'émetteur/de la découverte, l'ID client, le secret ou les clés, les URI de redirection autorisées et les règles TLS.
2. N’autoriser que les portées et revendications nécessaires : sujet stable, nom d’affichage, adresse e-mail éventuellement vérifiée et groupes approuvés.
3. Mettre en place un processus de première connexion sans possibilité de lier automatiquement un compte uniquement par e-mail.
4. Associer les groupes approuvés aux rôles de base de l'application ; les rôles de processus sont attribués conformément aux règles du processus spécifique.
5. Testez la connexion, la déconnexion, le changement de groupe, le blocage de compte et les utilisateurs sans rôle autorisé.

04

4. Mettre en place un système DERS/IdP partenaire pour le support

1. Utilisez un alias de courtier distinct et un client distinct pour un environnement client spécifique.
2. Autoriser uniquement les comptes professionnels nommés ; désactiver les comptes d’assistance ou d’administration partagés.
3. Exiger une authentification multifacteur (MFA) ou une clé d'accès auprès du fournisseur d'identité d'origine et réussir le test d'authentification si cela fait partie du contrat.
4. Déduisez l'approche du groupe cible pour le client et l'environnement spécifiques, et non de l'emploi général chez DERS/partenaire.
5. Définir le rôle minimum requis ; limiter la durée et auditer les autorisations élevées.
6. Une fois l'intervention terminée, vérifiez la suppression du groupe, la fin de la session et l'invalidation du jeton d'actualisation.

05

5. Cycle de vie automatique sans création de compte local

• La première connexion peut créer automatiquement un compte auprès d'un émetteur de confiance et d'un sujet stable.
• Le rôle est créé à partir d'une revendication/d'un groupe géré ; et non à partir de texte libre ou du domaine de messagerie lui-même.
• Toute modification ou suppression de l'IdP source prendra effet au plus tard à la fin de la session/du jeton défini.
• Si une suppression immédiate est requise sans connexion utilisateur, complétez avec une déconnexion par canal secondaire, SCIM ou un autre canal de cycle de vie pris en charge ; le courtage OIDC seul ne le garantit pas.
• Un test régulier permettra de vérifier la désactivation, l'expiration de la session, le changement de rôle et l'audit de l'identité d'origine.

06

6. Que doit contenir l'audit ?

• émetteur et sujet du fournisseur d'identité d'origine en tant que paire immuable
• identifiant utilisateur interne, nom d'affichage et organisation
• groupe source/réclamation et rôle de l'application résultant
• heure de connexion, niveau d'authentification et identifiant de session
• Chaque augmentation d'autorisation, sa raison, son approbation et son expiration
• actions effectuées dans le cadre de ce processus sous une identité nommée, et non sous un compte d'intégration

07

7. Test d'acceptation

1. Un utilisateur client appartenant au groupe approprié se connecte et ne voit que son périmètre d'accès.
2. Un utilisateur client sans groupe peut se connecter, mais ne recevra pas les autorisations de traitement ou se verra refuser l'accès conformément à la politique en vigueur.
3. Un employé DERS/partenaire désigné ne recevra que le périmètre de support d'un environnement spécifique.
4. Un deuxième travailleur n'appartenant pas à un groupe à vocation spécifique n'y aura pas accès.
5. La suppression d'un groupe invalidera l'accès à l'heure déclarée.
6. L'audit permettra de distinguer deux personnes portant le même nom ou la même adresse électronique, mais provenant d'émetteurs différents.