Download - Vue d'ensemble du SSO
l’agilité du SIOpenCSI
Le SSO, vue d’ensembleBruno Bonfils
1samedi 29 octobre 11
L’histoire d’ACME
✦ Une petite société crée il y a quelques années, qui a vite grossie
✦ Des applications installées de manière autonome, des logins différents
✦ Les commerciaux utilisent SalesForces
✦ Rachat d’une entreprise
3samedi 29 octobre 11
L’existant
4
App1bonfilsb
App2bbonfils
SQL
App3
LDAP
Apppropriétaire
SQL
bbonfils
App webInterne
AppInternet
Salesforces ??
Penser à parler des rôles au sein de chaque application
samedi 29 octobre 11
L’existant
✦ Des groupes (~ rôles) propre à chaque application
✦ Ces groupes sont liés au métier de l’application
5samedi 29 octobre 11
Problématiques
✦ Multiple entrepôts de comptes utilisateurs
✦ Changement du mot de passe ?
✦ Politique de mot de passe ?
✦ Identifiant non uniforme
✦ Authentification des applications externes
6samedi 29 octobre 11
Objectifs 1/2
✦ Utiliser un seul entrepôt de compte utilisateur
✦ Mettre en place une politique de mot de passe uniforme
✦ Une seule authentification (SSO)
✦ Si possible, déconnexion unique
7samedi 29 octobre 11
Objectifs 2/2
✦ Gérer plus efficacement les rôles
✦ Fournir une solution propre pour l’authentification sur les applications externes
8samedi 29 octobre 11
Les solutions
✦ Après une recherche, on arrive à :
✦ CAS
✦ OpenAM
✦ LemonLDAP::NG
✦ Vulture
9samedi 29 octobre 11
Après étude, on constate
✦ Gestion du SSO au sein de l’application
✦ CAS
✦ Un module spécifique au serveur d’application
✦ OpenAM, LemonLDAP::NG
✦ SSO par injection
✦ Vulture, OpenAM / LL::NG
10samedi 29 octobre 11
SSO application
✦ Grand nombre de références Internet à CAS, qui se révèle être un SSO géré au niveau application
12samedi 29 octobre 11
Fonctionnement CAS (app1)
13
App1 CAS
accède à
redirige
accède à
authentification
redirige (cookie + jeton)
accède à (jeton)
vérifie le jeton
samedi 29 octobre 11
Fonctionnement CAS (app2)
14
App2 CAS
accède à
redirige
accède à (cookie)
redirige (jeton)
accède à (jeton)
vérifie le jeton
samedi 29 octobre 11
SSO application, les +
✦ Totalement indépendant de l’environnement d’exécution
✦ Libs CAS existantes pour Java, PHP, .Net
✦ Facile à déployer, à administrer
✦ Performances
15samedi 29 octobre 11
SSO application
✦ Pas d’autorisation (avec le serveur officiel)
✦ Pas de single logout évident
✦ Cas d’utilisations généralement très simple (pas ou peu de gestions de groupes, etc.)
✦ Que faire quand on a pas la main sur l’application ?
16samedi 29 octobre 11
SSO application
✦ CAS (Central Authentication Service), développé par l’université de Yale
✦ Très gros déploiement (y compris dans des universités françaises)
17samedi 29 octobre 11
SSO par agent
✦ Nécessite un agent (module) sur le serveur d’application : Apache, Tomcat, JBoss, etc.
✦ Se substitue à la couche d’authentification (autorisation le cas échéant)
18samedi 29 octobre 11
OpenAM (app1)
19
Serveur d’app1 OpenAM
accède à
redirige
accède à
authentification
redirige (cookie)
accède à (cookie)
information de session
samedi 29 octobre 11
OpenAM (app2)
20
Serveur d’app2 OpenAM
accède à (cookie)
information de session
Exemple :• liste des groupes• attributs :
• email, prénom, nom
samedi 29 octobre 11
SSO par agent
✦ Avec OpenAM, pour obtenir un nom d’utilisateur :
✦ getPrincipal() en Java (couche JAAS)
✦ Par l’API de l’agent, en Java
✦ Par l’API REST
✦ Ou tout simplement en-tête HTTP
21samedi 29 octobre 11
SSO par agent, les +
✦ Plus grande souplesse fonctionnelle
✦ Gestion centralisée possible des agents (configuration, logs, etc.)
✦ Gestion des autorisations dans une certaine mesure (par méthode et par URL)
22samedi 29 octobre 11
SSO par agent, les -
✦ Complexité
✦ Dépendance à l’agent (logiciel, OS, archi)
✦ Performances (serveur sollicité très souvent)
✦ Fonctionne par cookie (Cross Domain Cookie comme palliatif)
23samedi 29 octobre 11
Les SSO par agent
✦ OpenAM (ex OpenSSO) probablement le plus ancien (beaucoup de très gros clients)
✦ LemonLDAP::NG, très complet, mais communauté réduite
24samedi 29 octobre 11
SSO par injection
26
App3
Apppropriétaire
SSO
POST /auth/login.php HTTP/1.0username=bbonfils&password=secret2
POST /login HTTP/1.0user=bonfilbs&password=secret
samedi 29 octobre 11
SSO par injection, les +
✦ Complète transparence au niveau des applications
✦ Permet de gérer le SSO sur les applications propriétaires
✦ Aucune contrainte sur la multiplicité des logins
27samedi 29 octobre 11
SSO par injection, les -
✦ Performances : tous les flux passent par le SSO
✦ Obligation de stocker les mots de passe des applications sous une forme réversible
✦ Travail d’intégration pour chaque application (formulaires différents)
28samedi 29 octobre 11
SSO par injection
✦ Il est possible d’utiliser OpenAM ou LemonLDAP::NG, via mod_proxy
✦ injection possible au travers d’en tête HTTP
✦ pas de rejeu de formulaires pour OpenAM (mais pas de portefeuilles de credentials pour LL::NG)
29samedi 29 octobre 11
Choix du SSO
✦ Projet mené en deux temps :
1. SSO interne prioritaire, en attendant on accepte d’utiliser un autre compte pour salesforces
2. Réflexion sur l’ouverture à l’extérieure
30samedi 29 octobre 11
Choix du SSO interne
✦ Il conviendra de :
✦ lister les serveurs d’applications, les applications
✦ se rappeler les contraintes (déconnexion, rôles)
31samedi 29 octobre 11
Projet SSO pour acme
✦ En fonction des contraintes imposées, choix de la solution :
✦ peu d’agents CAS gèrent nativement la déconnexion unique
✦ Choix final : OpenAM
32samedi 29 octobre 11
Projet SSO pour acme
✦ Comment gérer la différence de login ? (bbonfils vs bonfilsb)
✦ Définir REMOTE_USER avec un attribut
✦ Modifié l’application pour utiliser l’attribut
33samedi 29 octobre 11
Un mot sur les rôles
✦ Dans un monde idéal, les utilisateurs sont associés à des rôles métiers (nombre limités de rôles) qui sont véhiculés par le SSO
✦ Un rôle métier est associé à des rôles applicatifs (au sein de chaque application)
34samedi 29 octobre 11
Et l’externe ?
✦ Reste la problématique des applications à hébergées par un tierce, donc entités commerciales différentes
✦ on évite les échanges directs entre les SI
35samedi 29 octobre 11
La fédération
✦ Deux entités différentes : on parle donc de fédération
✦ nécessite une relation de confiance
✦ Techniquement, un seul choix standard : SAML
36samedi 29 octobre 11
La fédération
✦ Quelques termes :
✦ Identity Provider (IdP) c’est le fournisseur, celui qui vérifie l’authentification d’un utilisateur (ici ACME)
✦ Service Provider (SP) un fournisseur de service (ici SalesForce)
37samedi 29 octobre 11
Fonctionnement SAML
38
SP IdP
accède à
redirige
accède à
authentification
redirige (assertion)
accède à (assertion)
samedi 29 octobre 11
Concrètement
✦ Configuration d’OpenAM en tant qu’IdP
✦ il n’est même pas nécessaire de l’exposer sur Internet (mécanisme de redirection)
✦ SalesForces accepte les assertions
✦ Vérification par signature
39samedi 29 octobre 11
Un peu plus sur OpenAM
Hiérarchie des utilisateurs :✦ / (tous)✦ /employes
✦ /employes/interne✦ /employes/prestataires
✦ /fournisseurs
42samedi 29 octobre 11
Un peu plus sur OpenAM✦ De la même manière que UNIX, distinction
entre
✦ identification des utilisateurs (attributs)
✦ authentification des utilisateurs
✦ Cas client
✦ connexion sous un utilisateur sans connaître son mot de passe
43samedi 29 octobre 11