Un seul compte pour plusieurs portails enlève une vraie friction. Dans une architecture CAS, l’utilisateur s’authentifie auprès d’un serveur central. Les applications ne voient pas le mot de passe; elles reçoivent une preuve à valider.

Lorsqu’une application ne trouve pas de session locale, elle redirige le navigateur vers CAS avec son URL de retour. Après authentification, CAS remet un ticket de service à usage limité. L’application appelle CAS pour valider le ticket, obtient l’identité, crée sa session puis renvoie la page demandée.

La preuve est courte, l’autorisation reste locale

Le parcours ressemble à ceci :

1. navigateur demande Portail A;
2. Portail A redirige vers CAS;
3. CAS vérifie la session centrale;
4. CAS retourne un ticket lié à Portail A;
5. Portail A valide le ticket côté serveur;
6. Portail A vérifie ses rôles et ouvre une session locale.

Un ticket destiné à A ne devrait pas être accepté par B. L’URL de retour doit être validée pour empêcher une redirection vers un site attaquant. La connexion entre l’application et CAS est chiffrée et le certificat vérifié; sinon une fausse validation peut injecter une identité.

Le SSO authentifie « qui ». Portail A décide encore si cette personne peut voir le dossier 471. Les groupes peuvent venir d’un annuaire, mais l’application applique la règle à chaque action sensible. Cacher un lien de menu ne suffit pas.

La centralisation concentre aussi la panne

Si CAS tombe, les nouvelles sessions échouent partout. Plusieurs nœuds, un stockage de session adapté, DNS, certificats surveillés et une procédure de bascule deviennent critiques. Les applications peuvent garder les sessions déjà ouvertes jusqu’à une courte expiration; prolonger indéfiniment affaiblit la révocation.

La déconnexion est plus compliquée que la connexion. Fermer la session CAS ne détruit pas toujours les sessions locales. Un employé retiré doit perdre groupes, jetons et sessions dans un délai connu. Les applications critiques peuvent relire l’autorisation plutôt que faire confiance à un rôle mis en cache toute la journée.

Les logs CAS montrent échecs, tickets et clients, sans conserver mots de passe ni paramètres sensibles. Une alerte sur de nombreux échecs, ticket rejoué ou nouveau service non approuvé aide à détecter un abus. Les comptes administrateurs ont une authentification plus forte et un usage séparé.

Protéger les attributs transportés avec l’identité

CAS peut retourner nom, courriel ou groupes en plus de l’identifiant. L’application ne devrait accepter que les attributs nécessaires, provenant d’une validation signée et chiffrée. Un groupe reçu n’est pas automatiquement un rôle local; une table de mapping versionnée décide la correspondance. Les changements de groupe sensibles demandent une revalidation plus fréquente. Les logs conservent l’identifiant stable et la décision d’autorisation, pas tout le profil. Je testerais un attribut absent, dupliqué et avec casse différente. Ces détails évitent qu’une application interprète Admin, admin et une chaîne vide de trois façons alors que toutes viennent du même SSO.

Je testerais chaque intégration avec ticket expiré, mauvaise audience, horloge décalée, CAS indisponible et rôle retiré. Le SSO est réussi lorsque la preuve centrale réduit les mots de passe tout en laissant chaque porte défendre son propre contenu.