1. OpenCSI
l’agilité du SI
Le SSO, vue d’ensemble
Bruno Bonfils
bbonfils@opencsi.com
1
samedi 29 octobre 11
2. La présentation
✦ Orientée projet
✦ Critère libre
✦ Aborde les concepts
2
samedi 29 octobre 11
3. 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
3
samedi 29 octobre 11
4. L’existant
Penser à parler des rôles
au sein de chaque
application
App1
SQL
bonfilsb
App2
SQL
bbonfils
App
App3 Salesforces ??
propriétaire
App web
Interne
LDAP bbonfils App
Internet
4
samedi 29 octobre 11
5. L’existant
✦ Des groupes (~ rôles) propre à chaque
application
✦ Ces groupes sont liés au métier de
l’application
5
samedi 29 octobre 11
6. 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
6
samedi 29 octobre 11
7. 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
7
samedi 29 octobre 11
8. Objectifs 2/2
✦ Gérer plus efficacement les rôles
✦ Fournir une solution propre pour
l’authentification sur les applications
externes
8
samedi 29 octobre 11
9. Les solutions
✦ Après une recherche, on arrive à :
✦ CAS
✦ OpenAM
✦ LemonLDAP::NG
✦ Vulture
9
samedi 29 octobre 11
10. 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
10
samedi 29 octobre 11
11. poussons l’étude...
✦ mode de fonctionnement
✦ avantages / inconvénients
11
samedi 29 octobre 11
12. SSO application
✦ Grand nombre de références Internet à
CAS, qui se révèle être un SSO géré au
niveau application
12
samedi 29 octobre 11
13. Fonctionnement CAS (app1)
App1 CAS
accède à
redirige
accède à
authentification
redirige (cookie + jeton)
accède à (jeton)
vérifie le jeton
13
samedi 29 octobre 11
14. Fonctionnement CAS (app2)
App2 CAS
accède à
redirige
accède à (cookie)
redirige (jeton)
accède à (jeton)
vérifie le jeton
14
samedi 29 octobre 11
15. SSO application, les +
✦ Totalement indépendant de
l’environnement d’exécution
✦ Libs CAS existantes pour Java, PHP, .Net
✦ Facile à déployer, à administrer
✦ Performances
15
samedi 29 octobre 11
16. 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 ?
16
samedi 29 octobre 11
17. 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)
17
samedi 29 octobre 11
18. 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)
18
samedi 29 octobre 11
19. OpenAM (app1)
Serveur
OpenAM
d’app1
accède à
redirige
accède à
authentification
redirige (cookie)
accède à (cookie)
information de session
19
samedi 29 octobre 11
20. OpenAM (app2)
Serveur
OpenAM
d’app2
accède à (cookie)
information de session
Exemple :
• liste des groupes
• attributs :
• email, prénom, nom
20
samedi 29 octobre 11
21. 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
21
samedi 29 octobre 11
22. 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)
22
samedi 29 octobre 11
23. 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)
23
samedi 29 octobre 11
24. 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
24
samedi 29 octobre 11
25. SSO par injection
✦ Injection de formulaire d’authentifications
25
samedi 29 octobre 11
26. SSO par injection
App3
POST /login HTTP/1.0
user=bonfilbs&password=secret
SSO
App
POST /auth/login.php HTTP/1.0
username=bbonfils&password=secret2 propriétaire
26
samedi 29 octobre 11
27. 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
27
samedi 29 octobre 11
28. 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)
28
samedi 29 octobre 11
29. 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)
29
samedi 29 octobre 11
30. 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
30
samedi 29 octobre 11
31. Choix du SSO interne
✦ Il conviendra de :
✦ lister les serveurs d’applications, les
applications
✦ se rappeler les contraintes
(déconnexion, rôles)
31
samedi 29 octobre 11
32. 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
32
samedi 29 octobre 11
33. 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
33
samedi 29 octobre 11
34. 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)
34
samedi 29 octobre 11
35. 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
35
samedi 29 octobre 11
36. 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
36
samedi 29 octobre 11
37. 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)
37
samedi 29 octobre 11
38. Fonctionnement SAML
SP IdP
accède à
redirige
accède à
authentification
redirige (assertion)
accède à (assertion)
38
samedi 29 octobre 11
39. 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
39
samedi 29 octobre 11
42. Un peu plus sur OpenAM
Hiérarchie des utilisateurs :
✦ / (tous)
✦ /employes
✦ /employes/interne
✦ /employes/prestataires
✦ /fournisseurs
42
samedi 29 octobre 11
43. 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
43
samedi 29 octobre 11
44. OpenCSI
l’agilité du SI
Questions ?
<bbonfils@opencsi.com>
http://www.opencsi.com/
44
samedi 29 octobre 11
