l’agilité du SIOpenCSI

Le SSO, vue d’ensembleBruno Bonfils

bbonfils@opencsi.com

1samedi 29 octobre 11

La présentation

✦ Orientée projet

✦ Critère libre

✦ Aborde les concepts

2samedi 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

poussons l’étude...

✦ mode de fonctionnement

✦ avantages / inconvénients

11samedi 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

✦ Injection de formulaire d’authentifications

25samedi 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

La (vraie) fédération

40

SP

SP

IdP

SP

IdP

SPSP

samedi 29 octobre 11

Quelques mots sur OpenAM

41samedi 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

l’agilité du SIOpenCSI

Questions ?<bbonfils@opencsi.com>http://www.opencsi.com/

44samedi 29 octobre 11