Cas pratiques SSO

Contexte : Une PME utilise cinq applications internes distinctes. Chaque application possède sa propre authentification, ce qui complique la gestion des accès. Le Problème : Concevoir une architecture SSO simple permettant à toutes les applications de déléguer l'authentification à un Identity Provider unique. Contraintes : La solution doit être compatible SAML ou OpenID Connect. Elle doit permettre la révocation centralisée des accès. Aucun changement majeur du code applicatif n'est souhaité. Livrable attendu : Proposer une architecture SSO simple incluant Identity Provider, Service Providers, gestion des certificats et flux d'authentification.

Contexte : Deux applications d'entreprise doivent partager une authentification unique afin d'améliorer l'expérience utilisateur. Actuellement, chaque application demande un login séparé. Le Problème : Vous devez configurer un flux OAuth2 simple permettant à une application cliente de déléguer l'authentification à un serveur d'autorisation central. Contraintes : Utiliser le flux Authorization Code. Le token doit avoir une durée de vie limitée. Aucun stockage local des mots de passe n'est autorisé. Livrable attendu : Décrire et configurer les éléments nécessaires (client_id, redirect_uri, scopes, token endpoint) pour permettre un SSO fonctionnel basé sur OAuth2.

Contexte : Après authentification SSO, certains utilisateurs se connectent mais leurs rôles ne sont pas correctement attribués dans l'application cible. Le Problème : Le mapping des attributs SAML ou OpenID Connect est mal configuré. Configuration actuelle : email -> user_name role -> department Les rôles applicatifs ne correspondent pas aux valeurs attendues. Contraintes : Vous ne pouvez pas modifier l'Identity Provider. Seule la configuration du Service Provider peut être ajustée. Livrable attendu : Corriger le mapping des attributs afin que les informations utilisateur soient correctement interprétées par l'application et que le SSO fonctionne pleinement.

Contexte : Les utilisateurs d'un système SSO se retrouvent déconnectés immédiatement après authentification sur certaines applications. Le Problème : La durée de validité configurée côté Service Provider est inférieure à celle définie dans l'assertion émise par l'Identity Provider. Configuration actuelle : SessionTimeout: 300 AssertionValidity: 3600 Les sessions expirent prématurément. Contraintes : Vous ne pouvez pas modifier la configuration de l'Identity Provider. La correction doit rester simple. Livrable attendu : Ajuster la configuration du Service Provider afin d'aligner la durée de session avec la validité de l'assertion et rétablir un SSO stable.

Contexte : Un SSO SAML fonctionne de manière intermittente. Certains utilisateurs reçoivent une erreur indiquant que l'assertion est "not yet valid". Le Problème : Les serveurs du Service Provider et de l'Identity Provider ne sont pas parfaitement synchronisés. Extrait d'assertion : NotBefore: 10:00:00 NotOnOrAfter: 11:00:00 Le serveur SP est en retard de 2 minutes. Contraintes : Vous ne pouvez pas modifier l'Identity Provider. La solution doit rester conforme au standard SAML. Livrable attendu : Ajuster la tolérance de clock skew côté Service Provider afin de permettre une validation correcte des assertions.

Contexte : Une intégration SSO via SAML fonctionne en environnement de test mais échoue en production. Les utilisateurs sont redirigés vers une page d'erreur après authentification. Le Problème : L'assertion SAML reçue est rejetée avec une erreur de validation de signature. Voici un extrait simplifié de la configuration actuelle : AssertionConsumerServiceURL: https://app.company.com/sso/acs EntityID: https://app.company.com Certificate: certificat_test.pem En production, le certificat a été changé mais la configuration n'a pas été mise à jour. Contraintes : Vous ne devez pas modifier l'Identity Provider. La correction doit rester conforme au standard SAML 2.0. Livrable attendu : Identifier et corriger la configuration afin que la validation de signature fonctionne correctement en production.

Contexte : Une application configurée pour utiliser OAuth2 en SSO redirige les utilisateurs vers une erreur "redirect_uri_mismatch" après authentification. Le Problème : La configuration actuelle est la suivante : Authorized redirect URI: https://app.company.com/callback Application redirect URI: https://app.company.com/auth/callback La connexion échoue systématiquement. Contraintes : Vous ne pouvez pas modifier le code applicatif. Seule la configuration côté fournisseur d'identité peut être ajustée. Livrable attendu : Corriger la configuration afin que la redirection corresponde exactement à celle déclarée et que le SSO fonctionne correctement.

Contexte : Votre entreprise souhaite centraliser l'authentification de plusieurs applications internes via un fournisseur d'identité existant. Aujourd'hui, chaque application possède son propre système de connexion. Le Problème : Vous devez configurer un mécanisme SSO permettant à un utilisateur authentifié auprès de l'Identity Provider d'accéder automatiquement à une application Service Provider sans nouvelle authentification. Contraintes : Vous devez utiliser le protocole SAML 2.0. Aucune modification du fournisseur d'identité n'est autorisée. La configuration doit rester minimale et respecter les standards de sécurité. Livrable attendu : Fournir la configuration SAML du Service Provider incluant l'ACS URL, l'Entity ID et la validation de l'assertion afin de permettre un SSO fonctionnel.

Contexte : Les utilisateurs se déconnectent d'une application mais restent authentifiés sur les autres applications connectées via SSO. Le Problème : Le Single Logout (SLO) n'est pas configuré correctement entre le Service Provider et l'Identity Provider. Contraintes : Utiliser le mécanisme SLO standard du protocole SAML ou OpenID Connect. Aucun développement complexe n'est autorisé. Livrable attendu : Configurer un mécanisme de Single Logout permettant de terminer la session sur toutes les applications connectées via le SSO.

Contexte : Votre organisation souhaite moderniser son système d'authentification en utilisant OpenID Connect au-dessus d'OAuth2 pour centraliser les identités. Le Problème : Vous devez configurer un flux d'authentification simple permettant de récupérer un ID Token contenant les informations de l'utilisateur afin d'activer un SSO entre plusieurs services. Contraintes : Utiliser le flux Authorization Code avec ID Token signé. Aucun stockage local d'identifiants n'est autorisé. Les tokens doivent être validés via leur signature. Livrable attendu : Définir la configuration client (issuer, client_id, redirect_uri, scopes openid profile email) et expliquer le mécanisme de validation du token pour activer le SSO.

Contexte : Votre organisation dispose d'applications historiques compatibles uniquement SAML et de nouvelles applications compatibles OpenID Connect. Le Problème : Vous devez concevoir une architecture SSO capable de supporter les deux protocoles simultanément avec un Identity Provider unique. Contraintes : Aucun double stockage d'identité n'est autorisé. La gestion des sessions doit être centralisée. Le logout global doit fonctionner pour les deux protocoles. Livrable attendu : Proposer une architecture détaillée permettant la coexistence SAML et OIDC, incluant la gestion des sessions, la configuration des Service Providers et la stratégie de Single Logout.

Contexte : Votre groupe possède plusieurs applications réparties sur différents sous-domaines (app1.company.com, app2.company.com, portail.company.io). Chaque application gère encore sa propre authentification. Le Problème : Vous devez concevoir une architecture SSO permettant une authentification unique et sécurisée entre ces domaines distincts tout en garantissant l'isolation des environnements. Contraintes : La solution doit utiliser OpenID Connect ou SAML 2.0. Les cookies ne doivent pas être partagés entre domaines de manière non sécurisée. Les tokens doivent être signés et avoir une durée de vie contrôlée. La révocation des sessions doit être centralisée. Livrable attendu : Proposer une architecture détaillée incluant Identity Provider, gestion des tokens, stratégie de redirection, validation des signatures et mécanisme de logout global.

Contexte : Plusieurs Service Providers sont connectés au même Identity Provider via SAML. Lorsqu'un utilisateur se déconnecte d'une application, les autres restent actives. Le Problème : Le Single Logout est configuré mais certains SP ne traitent pas correctement la requête LogoutRequest. Contraintes : Vous ne pouvez pas supprimer le SLO. La solution doit respecter le standard SAML 2.0. Les modifications doivent être faites côté Service Provider concerné. Livrable attendu : Identifier la cause du traitement incorrect du LogoutRequest et corriger la configuration afin d'assurer un logout global cohérent.

Contexte : Une application interne reçoit une assertion SAML valide mais ne retrouve pas l'utilisateur correspondant dans sa base. Le Problème : Le NameID transmis est au format transient alors que l'application attend un identifiant email. Extrait d'assertion : NameID Format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient Contraintes : L'Identity Provider peut être configuré mais l'application cliente ne peut pas être modifiée. Livrable attendu : Ajuster la configuration afin que le NameID soit transmis au format emailAddress ou persistent et restaurer le fonctionnement du SSO.

Contexte : Une application web intégrée en OpenID Connect fonctionne en environnement de test mais échoue lors d'audits de sécurité. Le Problème : L'ID Token est accepté sans validation du nonce envoyé lors de la requête d'authentification. Implémentation actuelle : if(validateSignature(idToken)) { allowAccess(); } Aucune vérification du nonce n'est effectuée. Contraintes : Vous devez respecter le standard OpenID Connect. Le fournisseur d'identité ne peut pas être modifié. Livrable attendu : Implémenter une validation complète incluant la vérification du nonce pour prévenir les attaques de replay tout en conservant un SSO fonctionnel.

Contexte : Une application utilisant OpenID Connect reçoit correctement un ID Token mais la validation de signature échoue en production. Le Problème : La configuration actuelle utilise une clé statique locale alors que l'Identity Provider publie ses clés via un endpoint JWKS. Configuration actuelle : SignatureKey: local_public_key.pem Issuer: https://id.company.com Les tokens signés avec une nouvelle clé ne sont plus acceptés. Contraintes : Vous ne pouvez pas désactiver la validation de signature. La solution doit supporter la rotation automatique des clés. Livrable attendu : Mettre en place une validation basée sur le endpoint JWKS afin de récupérer dynamiquement la clé publique correcte et restaurer le fonctionnement du SSO.

Contexte : Une application intégrée en SSO via OpenID Connect refuse certains utilisateurs malgré un ID Token valide. Le Problème : La validation de l'audience est mal implémentée. Voici la logique actuelle : if(token.aud != 'my-app') { reject(); } Or le token contient : aud: ['my-app', 'account'] L'accès est refusé alors que l'application fait bien partie des audiences autorisées. Contraintes : Vous ne devez pas modifier le fournisseur d'identité. La validation doit rester conforme au standard OIDC. Livrable attendu : Corriger la logique de validation afin d'accepter correctement les tokens contenant plusieurs audiences tout en conservant un contrôle strict de sécurité.

Contexte : Les utilisateurs se plaignent de devoir se reconnecter fréquemment malgré un SSO correctement configuré. Le Problème : Les access tokens expirent rapidement et aucun mécanisme de refresh token n'est utilisé. Contraintes : Utiliser OpenID Connect. Les refresh tokens doivent être protégés contre le vol. La rotation des tokens doit être activée. Livrable attendu : Définir une stratégie d'utilisation des refresh tokens incluant rotation, durée de vie limitée et validation côté serveur afin d'améliorer l'expérience utilisateur sans compromettre la sécurité.

Contexte : Votre entreprise souhaite renforcer la sécurité de son SSO en imposant des règles d'accès selon le contexte (localisation, type d'appareil). Le Problème : Actuellement, toute authentification réussie donne accès aux applications sans contrôle supplémentaire. Contraintes : Utiliser les mécanismes natifs du protocole SAML ou OpenID Connect. Les règles doivent être centralisées au niveau de l'Identity Provider. Aucun développement spécifique dans les applications clientes. Livrable attendu : Proposer une configuration d'accès conditionnel intégrée au SSO incluant gestion des claims, politiques d'accès et validation côté application.

Contexte : Votre entreprise souhaite centraliser l'authentification et l'autorisation de plusieurs applications métiers via un Identity Provider unique. Le Problème : Au-delà de l'authentification, les rôles utilisateurs doivent être transmis dans l'assertion ou le token afin que chaque application applique ses propres règles d'autorisation. Contraintes : Utiliser SAML ou OpenID Connect. Les rôles doivent être signés dans le token ou l'assertion. Aucune base de données locale de rôles ne doit être maintenue dans les applications clientes. Livrable attendu : Définir la configuration permettant d'inclure les rôles dans le token/assertion et expliquer comment les applications doivent les valider et les exploiter de manière sécurisée.

Contexte : Votre système d'authentification central devient un point critique. Une indisponibilité de l'Identity Provider bloque l'accès à toutes les applications. Le Problème : Concevoir une architecture SSO tolérante aux pannes garantissant la continuité de service en cas d'indisponibilité partielle d'un IdP. Contraintes : Support OpenID Connect ou SAML. Synchronisation sécurisée des clés et métadonnées. Gestion cohérente des sessions entre plusieurs IdP redondants. Aucune perte d'intégrité des tokens. Livrable attendu : Proposer une architecture haute disponibilité incluant redondance des Identity Providers, synchronisation des clés, gestion des sessions distribuées et stratégie de reprise après incident.

Contexte : Une plateforme SaaS héberge plusieurs entreprises clientes sur la même infrastructure avec un Identity Provider commun. Le Problème : Garantir qu'un utilisateur authentifié dans un tenant ne puisse jamais accéder aux ressources d'un autre tenant via un token valide. Contraintes : Utiliser OpenID Connect. Les tokens doivent contenir un claim tenant_id signé. Validation obligatoire côté application. Aucun partage d'audience entre tenants. Livrable attendu : Proposer une architecture SSO multi-tenant incluant gestion des claims, validation stricte du tenant_id et mécanisme empêchant toute élévation de privilèges inter-tenant.

Contexte : Votre entreprise opère des applications critiques réparties sur plusieurs environnements (on-premise, cloud public, SaaS). Chaque environnement possède ses propres mécanismes d'authentification. Le Problème : Vous devez concevoir une architecture SSO unifiée permettant la fédération d'identité entre plusieurs Identity Providers tout en respectant une approche Zero-Trust. Contraintes : Support simultané SAML 2.0 et OpenID Connect. Validation stricte des signatures et des audiences. Gestion centralisée des politiques d'accès conditionnel. Support de la rotation automatique des clés. Aucune duplication d'annuaire utilisateur. Livrable attendu : Proposer une architecture détaillée incluant schéma de fédération, flux d'authentification, validation des tokens, stratégie de confiance inter-domaines et mécanisme de Single Logout global.

Contexte : Un système OpenID Connect dessert plusieurs applications clientes avec des client_id distincts. Le Problème : L'application valide uniquement l'issuer et la signature du token. Implémentation actuelle : if(validateSignature(token) && token.iss === expectedIssuer) { allowAccess(); } La vérification de l'audience (aud) et du azp est absente, permettant potentiellement à un token destiné à un autre client d'être accepté. Contraintes : Vous devez respecter strictement la spécification OIDC et empêcher tout usage croisé de token entre clients. Livrable attendu : Implémenter une validation complète incluant aud, azp et client_id afin d'éliminer tout contournement d'audience.

Contexte : Un audit révèle que l'application SAML valide la signature XML mais reste vulnérable à certaines attaques XML Signature Wrapping. Le Problème : La validation actuelle accepte toute signature valide sans vérifier que l'élément signé correspond bien à l'assertion utilisée. Implémentation actuelle : if(validateXMLSignature(assertion)) { processAssertion(assertion); } Aucune vérification de référence ID n'est effectuée. Contraintes : Respect strict des standards XML Signature et SAML 2.0. Aucune désactivation de validation. Livrable attendu : Mettre en place une validation robuste garantissant que seule l'assertion réellement signée et référencée est traitée par l'application.

Contexte : Votre application accepte des tokens provenant de plusieurs Identity Providers partenaires. Le Problème : La validation actuelle ne vérifie pas strictement la correspondance entre issuer attendu et endpoint de récupération des clés. Implémentation actuelle : if(validateSignature(token)) { allowAccess(); } Un IdP malveillant pourrait potentiellement émettre un token valide mais non autorisé. Contraintes : Vous devez lier explicitement issuer, endpoint JWKS et client_id. Aucune désactivation de validation n'est permise. Livrable attendu : Mettre en place une validation stricte empêchant toute confusion d'Identity Provider en vérifiant issuer exact, audience et provenance des clés.

Contexte : Une plateforme utilisant SAML subit des interruptions lors de la rotation des certificats du fournisseur d'identité. Le Problème : Le Service Provider conserve un seul certificat statique pour valider les assertions. Configuration actuelle : TrustedCertificate: idp_old_cert.pem Lorsque l'Identity Provider publie un nouveau certificat, les assertions sont rejetées. Contraintes : Vous devez supporter plusieurs certificats simultanément et respecter la validation stricte des signatures XML. Aucun contournement de validation n'est autorisé. Livrable attendu : Mettre en place une validation dynamique basée sur les métadonnées SAML permettant la gestion transparente de la rotation des clés sans interruption du SSO.

Contexte : Un audit de sécurité révèle qu'une application intégrée en OpenID Connect pourrait être vulnérable aux attaques par rejeu. Le Problème : L'application valide la signature de l'ID Token mais ne vérifie pas correctement les paramètres state et nonce. Implémentation actuelle : if(validateSignature(idToken) && validateIssuer(idToken)) { allowAccess(); } Aucune vérification du nonce stocké côté client n'est effectuée. Contraintes : Le fournisseur d'identité ne peut pas être modifié. La solution doit respecter strictement la spécification OpenID Connect et empêcher toute réutilisation de token intercepté. Livrable attendu : Implémenter une validation complète incluant state, nonce, exp, aud et protection contre le replay, avec description précise du mécanisme sécurisé.

Contexte : Deux entreprises partenaires souhaitent permettre à leurs employés d'accéder aux applications respectives via un mécanisme SSO fédéré. Le Problème : Vous devez établir une relation de confiance croisée entre deux Identity Providers distincts sans exposer les annuaires internes. Contraintes : Utiliser SAML 2.0 avec échange de métadonnées signées. Validation stricte des certificats et gestion de la rotation des clés. Les assertions doivent inclure uniquement les attributs strictement nécessaires. Livrable attendu : Décrire la configuration complète de la fédération incluant échange de métadonnées, gestion des certificats, flux d'authentification et contrôle d'accès sécurisé entre les deux organisations.

Contexte : Une architecture microservices expose des APIs protégées derrière une API Gateway. L'authentification est gérée via OpenID Connect. Le Problème : Les microservices doivent faire confiance aux tokens validés par la Gateway tout en empêchant l'injection de tokens falsifiés. Contraintes : Validation des tokens à la Gateway et propagation sécurisée des claims. Signature obligatoire des tokens. Aucun partage de secret entre microservices. Protection contre le token substitution attack. Livrable attendu : Définir une architecture sécurisée incluant validation en amont, propagation des claims signés et stratégie de confiance interne entre services.