« SSO » : différence entre les versions

De Justine's wiki
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 1 : Ligne 1 :
<div class="mw-parser-output"><h1> Single Sign-On</h1>
 
<h2> Liens</h2>
= Single Sign-On =
<p>Panorama de solutions&#160;: <a href="http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite" alt="http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite" title="http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite">http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite</a>
 
</p>
== Liens ==
<h2> Présentation</h2>
 
<p>Le SSO consiste à centraliser les authentifications; on uniformise la sécurité de l'authentification, quelle que soit la plateforme. On peut ensuite appliquer une politique de mdp et gérer l'authentification via des protocoles normalisés et sécurisés (LDAP, Kerberos, CAS, RADIUS, etc). Le SSO est un début pour passer ensuite à l'authentification multi-facteurs. Les buts sont&#160;:
Panorama de solutions&nbsp;: <a href="[http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite]" alt="[http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite]" title="[http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite]">[http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite]</a>
</p>
 
<ul><li>Amélioration de la sécurité </li>
== Présentation ==
<li>Simplifier l'utilisation </li>
 
<li>Faciliter les opérations pour les gestionnaires </li></ul>
Le SSO consiste à centraliser les authentifications; on uniformise la sécurité de l'authentification, quelle que soit la plateforme. On peut ensuite appliquer une politique de mdp et gérer l'authentification via des protocoles normalisés et sécurisés (LDAP, Kerberos, CAS, RADIUS, etc). Le SSO est un début pour passer ensuite à l'authentification multi-facteurs. Les buts sont&nbsp;:
<p>AAA&#160;:
 
</p>
*Amélioration de la sécurité  
<ul><li>Authentification&#160;: Prouver son identité </li>
*Simplifier l'utilisation  
<li>Authorization&#160;: Qu'est-ce que j'ai le droit de faire </li>
*Faciliter les opérations pour les gestionnaires  
<li>Accounting&#160;: Qu'est-ce que je fais </li></ul>
 
<p>On a aussi une notion de single logout&#160;: je me peut me loguer et me déloguer de manière globale, ce qui est moins évident, parce que chaque application gère son authentification de façon globale. Il faut donc gérer une base centrale des applications qui ont une session d’authentification avec l’utilisateur et mémoriser une URL de déconnexion.–Le single logoutest complexe donc peu implémenté...
AAA&nbsp;:
</p>
 
<h2> Technos utilisées</h2>
*Authentification&nbsp;: Prouver son identité  
<ul><li>HTTP header&#160;: Pour les application proxifiées. On protège les apps, contrôle les urls, et on crée des variables multiples... (???) On a pas besoin de SLO.  
*Authorization&nbsp;: Qu'est-ce que j'ai le droit de faire  
<ul><li><img src="/mediawiki/images/3/34/Http_header.png" _fck_mw_filename="Http header.png" _fck_mw_origimgwidth="781" _fck_mw_origimgheight="351" alt="RTENOTITLE" title="RTENOTITLE" style="vertical-align:middle;" />  </li></ul></li>
*Accounting&nbsp;: Qu'est-ce que je fais  
<li>SAML (Security Assertion Markup Language)&#160;:standard informatique définissant un protocole pour échanger des informations liées à la sécurité. Basé sur le langage XML, SAML a été développé par OASIS. SAML propose l'authentification unique (en anglais single sign-on ou SSO) sur le web. De cette manière, un utilisateur peut naviguer sur plusieurs sites différents en ne s'authentifiant qu'une seule fois, sans pour autant que ces sites aient accès à des informations trop confidentielles. (wikipédia) </li>
 
<li>Authentification formulaire&#160;: Elle est utilisée par les applications sans SSO possible, ne permet pas de SLO, et lente et non recommandée. De plus, on doit stocker les mdp utilisateurs... </li>
On a aussi une notion de single logout&nbsp;: je me peut me loguer et me déloguer de manière globale, ce qui est moins évident, parce que chaque application gère son authentification de façon globale. Il faut donc gérer une base centrale des applications qui ont une session d’authentification avec l’utilisateur et mémoriser une URL de déconnexion.–Le single logoutest complexe donc peu implémenté...
<li>Il reste aussi CAS, OpenID, WS-federation... </li></ul>
 
<h1> LDAP</h1>
== Technos utilisées ==
<p>cf&#160;: <a href="Protocoles">Protocoles</a>
 
</p><p>Un annuraire LDAP contient de nombreuses informations relatives aux personnes&#160;: compte, mdp, etc; mais aussi aux structures. Il sert au contrôle d'accès (en donnant différents droits sur différents services). Un tas de services s'appuient sur LDAP, chez Windows comme chez Unix.
*HTTP header&nbsp;: Pour les application proxifiées. On protège les apps, contrôle les urls, et on crée des variables multiples... (???) On a pas besoin de SLO.  
</p>
**<img src="/mediawiki/images/3/34/Http_header.png" _fck_mw_filename="Http header.png" _fck_mw_origimgwidth="781" _fck_mw_origimgheight="351" alt="RTENOTITLE" title="RTENOTITLE" style="vertical-align:middle;" />   
<h2> Recommandations</h2>
*SAML (Security Assertion Markup Language)&nbsp;:standard informatique définissant un protocole pour échanger des informations liées à la sécurité. Basé sur le langage XML, SAML a été développé par OASIS. SAML propose l'authentification unique (en anglais single sign-on ou SSO) sur le web. De cette manière, un utilisateur peut naviguer sur plusieurs sites différents en ne s'authentifiant qu'une seule fois, sans pour autant que ces sites aient accès à des informations trop confidentielles. (wikipédia)  
<p>Recommandations nationales SUPANN (juin 2003), pour que les annuaires de la communauté 'Education Recherche' partagent un modèle identique:
*Authentification formulaire&nbsp;: Elle est utilisée par les applications sans SSO possible, ne permet pas de SLO, et lente et non recommandée. De plus, on doit stocker les mdp utilisateurs...  
</p>
*Il reste aussi CAS, OpenID, WS-federation...  
<ul><li>assurer l'interopérabilité des différents annuaires (ENT), </li>
 
<li>faciliter la mise en place d'un méta-annuaire national </li></ul>
= LDAP =
<p>LDAP a une structure arborescente&#160;:
 
</p><p><img src="/mediawiki/images/4/4e/Ldap_struc.png" _fck_mw_filename="Ldap struc.png" _fck_mw_origimgwidth="960" _fck_mw_origimgheight="482" alt="RTENOTITLE" title="RTENOTITLE" style="vertical-align:middle;" />
cf&nbsp;: <a href="Protocoles">Protocoles</a>
</p><p>Exemple d'une entrée 'personnel'&#160;:
 
</p>
Un annuraire LDAP contient de nombreuses informations relatives aux personnes&nbsp;: compte, mdp, etc; mais aussi aux structures. Il sert au contrôle d'accès (en donnant différents droits sur différents services). Un tas de services s'appuient sur LDAP, chez Windows comme chez Unix.
 
== Recommandations ==
 
Recommandations nationales SUPANN (juin 2003), pour que les annuaires de la communauté 'Education Recherche' partagent un modèle identique:
 
*assurer l'interopérabilité des différents annuaires (ENT),  
*faciliter la mise en place d'un méta-annuaire national  
 
LDAP a une structure arborescente&nbsp;:
 
<img src="/mediawiki/images/4/4e/Ldap_struc.png" _fck_mw_filename="Ldap struc.png" _fck_mw_origimgwidth="960" _fck_mw_origimgheight="482" alt="RTENOTITLE" title="RTENOTITLE" style="vertical-align:middle;" />
 
Exemple d'une entrée 'personnel'&nbsp;:
<pre>dn: uid=declercq,ou=people,dc=univ-lille1,dc=fr
<pre>dn: uid=declercq,ou=people,dc=univ-lille1,dc=fr
objectClass: inetOrgPerson (classe d'objet par d&#233;faut qui caract&#233;rise une personne)
objectClass: inetOrgPerson (classe d'objet par d&#233;faut qui caract&#233;rise une personne)
Ligne 58 : Ligne 71 :
       ustlRole: Correspondant annuaire de l'USTL
       ustlRole: Correspondant annuaire de l'USTL
         radiusGroupName: personnel</pre>
         radiusGroupName: personnel</pre>
<p>Les alimentations et les màj peuvent se faire par une base (de scolarité pour les étudiants...), cela permet un changement de mdp interactif, etc. Les personnels passent par Harpège, et par le bouton "mise à jour" de la page annuaire de l'université.<br /> Données nominatives&#160;:
 
</p>
Les alimentations et les màj peuvent se faire par une base (de scolarité pour les étudiants...), cela permet un changement de mdp interactif, etc. Les personnels passent par Harpège, et par le bouton "mise à jour" de la page annuaire de l'université.<br/> Données nominatives&nbsp;:
<ul><li>publiées avec l’accord de la personne, </li>
 
<li>utilisées dans le cadre d ’un objectif précis, </li>
*publiées avec l’accord de la personne,  
<li>durée de conservation raisonnable, </li>
*utilisées dans le cadre d ’un objectif précis,  
<li>sécurité physique et logique des données, </li>
*durée de conservation raisonnable,  
<li>accessibles qu’aux seules personnes autorisées. </li>
*sécurité physique et logique des données,  
<li><a href="http://www.cnil.fr" alt="http://www.cnil.fr" title="http://www.cnil.fr">http://www.cnil.fr</a> </li>
*accessibles qu’aux seules personnes autorisées.  
<li><a href="http://www.educnet.education.fr/legamedia" alt="http://www.educnet.education.fr/legamedia" title="http://www.educnet.education.fr/legamedia">http://www.educnet.education.fr/legamedia</a> </li></ul>
*<a href="[http://www.cnil.fr http://www.cnil.fr]" alt="[http://www.cnil.fr http://www.cnil.fr]" title="[http://www.cnil.fr http://www.cnil.fr]">[http://www.cnil.fr http://www.cnil.fr]</a>  
<h1> Authentification web, SSO, fédération d'identités</h1>
*<a href="[http://www.educnet.education.fr/legamedia http://www.educnet.education.fr/legamedia]" alt="[http://www.educnet.education.fr/legamedia http://www.educnet.education.fr/legamedia]" title="[http://www.educnet.education.fr/legamedia http://www.educnet.education.fr/legamedia]">[http://www.educnet.education.fr/legamedia http://www.educnet.education.fr/legamedia]</a>  
<p>Il faut pouvoir gérer le contrôle d'accès aux applications web. Pour cela&#160;:
 
</p>
= Authentification web, SSO, fédération d'identités =
<ul><li>On veut restreindre l'accès à une partie du serveur à une population donnée </li></ul>
 
<p>On peut identifier l'utilisateur par son IP (pas suffisant) et en l'authentifiant.
Il faut pouvoir gérer le contrôle d'accès aux applications web. Pour cela&nbsp;:
</p>
 
<h3> Apache et les modules d'auth</h3>
*On veut restreindre l'accès à une partie du serveur à une population donnée
<p>On peut étendre les fonctionnalités du serveur web Apache en ajoutant des modules&#160;:
 
</p>
On peut identifier l'utilisateur par son IP (pas suffisant) et en l'authentifiant.
<ul><li>mod_auth&#160;: utilisation des fichiers htpasswd et htgroup </li>
 
<li>mod_ssl&#160;: gestion SSL et authentification avec certificats </li>
=== Apache et les modules d'auth ===
<li>mod_authldap&#160;: authentification LDAP </li>
 
<li>mod_authZldap&#160;: authentification avec certificats puis autorisation basée sur LDAP </li>
On peut étendre les fonctionnalités du serveur web Apache en ajoutant des modules&nbsp;:
<li>etc&#160;: <a href="http://modules.apache.org" alt="http://modules.apache.org" title="http://modules.apache.org">http://modules.apache.org</a> </li></ul>
 
<p>Authentification et autorisation sont deux processus disjoints (cf.&#160;: le haut de la page)
*mod_auth&nbsp;: utilisation des fichiers htpasswd et htgroup
</p>
*mod_ssl&nbsp;: gestion SSL et authentification avec certificats
<h3> Les briques d'un SSO</h3>
*mod_authldap&nbsp;: authentification LDAP
<ul><li>Le serveur d'authentification&#160;: c'est un élément central. Il authentifie l'utilisateur, assure la persistance de la connexion, propage l'identité vers les applications et se répose sur un ou des référentiels (LDAP, NIS...). </li>
*mod_authZldap&nbsp;: authentification avec certificats puis autorisation basée sur LDAP
<li>Les agents d'authentification&#160;: ils sont devant chaque ressource à protéger. Il servent d'interface entre le serveur et l'application&#160;: redirigent l'utilisateur vers le serveur d'authentification et transmettent sont identité vers l'application. Il peuvent être implémentés sous la forme de librairies clients ou de modules intégrés au serveur web. </li></ul>
*etc&nbsp;: <a href="[http://modules.apache.org http://modules.apache.org]" alt="[http://modules.apache.org http://modules.apache.org]" title="[http://modules.apache.org http://modules.apache.org]">[http://modules.apache.org http://modules.apache.org]</a>  
<h3> Techniques utilisées</h3>
 
<ul><li>Pour la communication vers l'utilisateur distant&#160;:  
Authentification et autorisation sont deux processus disjoints (cf.&nbsp;: le haut de la page)
<ul><li>Requêtes GET ou formulaires POST </li>
 
<li>Redirections </li>
=== Les briques d'un SSO ===
<li>JS  </li></ul></li>
 
<li>Persistence des sessions:
*Le serveur d'authentification&nbsp;: c'est un élément central. Il authentifie l'utilisateur, assure la persistance de la connexion, propage l'identité vers les applications et se répose sur un ou des référentiels (LDAP, NIS...).
<ul><li>Cookies&#160;!  </li></ul></li>
*Les agents d'authentification&nbsp;: ils sont devant chaque ressource à protéger. Il servent d'interface entre le serveur et l'application&nbsp;: redirigent l'utilisateur vers le serveur d'authentification et transmettent sont identité vers l'application. Il peuvent être implémentés sous la forme de librairies clients ou de modules intégrés au serveur web.  
<li>Protection des échanges:  
 
<ul><li>SSL </li>
=== Techniques utilisées ===
<li>Portée et durée de validité des cookies </li>
 
<li>Jetons non rejouables  </li></ul></li></ul>
*Pour la communication vers l'utilisateur distant&nbsp;:  
<p>La gestion des sessions se fait à deux niveaux&#160;:
**Requêtes GET ou formulaires POST
</p>
**Redirections
<ul><li>Avec le serveur d'authentification, ce qui évite de se réauthentifier à chaque fois </li>
**JS 
<li>Avec l'agent, ce qui évite de renvoyer l'utilisateur vers le serveur à chaque requête. </li></ul>
*Persistence des sessions:
<h3> Aports du SSO</h3>
**Cookies&nbsp;! 
<p>On y gagne en ergonomie&#160;: On ne saisit le mdp qu'une seule fois, à un seul endroit. Il faut donc sensibiliser l'utilisateur.
*Protection des échanges:  
</p><p>On y gagne en sécurité&#160;: On limite l'accès et la circulation des mots de passe, et cela permet aussi la création d'une politique des mots de passe. Enfin, on peut étendre les mode d'authentification.
**SSL
</p><p>Pour les applications, on utilise les mêmes librairies d'authentification dans toutes les applications, ce qui permet de mieux les intégrer.
**Portée et durée de validité des cookies
</p><p>On a le choix, en matière de SSO&#160;: Pas de standardisation, et les besoins deviennent vite pressants. On a une multiplication des solutions, de tous types, plus ou moins sûres...
**Jetons non rejouables 
</p>
 
<h3> Single logout</h3>
La gestion des sessions se fait à deux niveaux&nbsp;:
<p>Un utilisateur logué globalement doit pouvoir se déloguer globalement, ce qui est plus difficile que SSO à cause de la multiplication des sessions. Il faut donc gérer une base centrales des applications qui ont une session en cours. C'est une technique complexe et peu implémentée.
 
</p>
*Avec le serveur d'authentification, ce qui évite de se réauthentifier à chaque fois
<h3> Ensuite...</h3>
*Avec l'agent, ce qui évite de renvoyer l'utilisateur vers le serveur à chaque requête.  
<p>On constate donc que les limites d'un service d'authentification apparaissent lorsque l'on veut ouvrir les portes à quelqu'un de l'éxtérieur. Comment reconnaître localement l'identité de quelqu'un qui vient de dehors?
 
</p>
=== Aports du SSO ===
<h2> Fédérations d'identités</h2>
 
<h3> SAML</h3>
On y gagne en ergonomie&nbsp;: On ne saisit le mdp qu'une seule fois, à un seul endroit. Il faut donc sensibiliser l'utilisateur.
<ul><li>SAML=Security Assertion Markup Language </li>
 
<li>Standard OASIS en 2002•Répond à un besoin d’interopérabilité </li>
On y gagne en sécurité&nbsp;: On limite l'accès et la circulation des mots de passe, et cela permet aussi la création d'une politique des mots de passe. Enfin, on peut étendre les mode d'authentification.
<li>Echanges d’assertions de sécurité entre services </li>
 
<li>Indépendant des mécanismes d’authentification </li></ul>
Pour les applications, on utilise les mêmes librairies d'authentification dans toutes les applications, ce qui permet de mieux les intégrer.
<p>Types d'assertions SAML&#160;:
 
</p>
On a le choix, en matière de SSO&nbsp;: Pas de standardisation, et les besoins deviennent vite pressants. On a une multiplication des solutions, de tous types, plus ou moins sûres...
<ul><li>Authentification </li>
 
<li>Échange d’attributs </li>
=== Single logout ===
<li>Décisions d’autorisation </li></ul>
 
<h3> Liberty Alliance</h3>
Un utilisateur logué globalement doit pouvoir se déloguer globalement, ce qui est plus difficile que SSO à cause de la multiplication des sessions. Il faut donc gérer une base centrales des applications qui ont une session en cours. C'est une technique complexe et peu implémentée.
<ul><li>Consortium d’industriels produisant des spécifications sur la gestion d’identités </li>
 
<li>S’appuie sur SAML </li>
=== Ensuite... ===
<li>Implémenté dans de nombreux produits </li></ul>
 
<h3> Shibboleth</h3>
On constate donc que les limites d'un service d'authentification apparaissent lorsque l'on veut ouvrir les portes à quelqu'un de l'éxtérieur. Comment reconnaître localement l'identité de quelqu'un qui vient de dehors?
<ul><li>Norme et produit développé par Internet2 </li>
 
<li>Open source </li>
== Fédérations d'identités ==
<li>Première version en 200 </li>
 
<li>•Basé sur SAML (bibliothèque OpenSAML </li>
=== SAML ===
<li>•Utilisé surtout par des universités </li>
 
<li>Conçu pour interconnecter les SSO des universités </li>
*SAML=Security Assertion Markup Language
<li>Fonctionnalités
*Standard OASIS en 2002•Répond à un besoin d’interopérabilité
<ul><li>Délégation d’authentification </li>
*Echanges d’assertions de sécurité entre services
<li>WAYF pour orienter l’utilisateur </li>
*Indépendant des mécanismes d’authentification
<li>Propagation des attributs utilisateur </li>
 
<li>Partage de méta données </li>
Types d'assertions SAML&nbsp;:
<li>Définition de règles de confiance  </li></ul></li></ul>
 
<h3> WS-Federation</h3>
*Authentification
<ul><li>Draft porté par Microsoft et IBM, 2003 </li>
*Échange d’attributs
<li>Basée sur les spécifications WS-*
*Décisions d’autorisation
<ul><li>–WS-Security, WS-Trust, WS-Policy, WS-MetadataExchange  </li></ul></li>
 
<li>Définit l’échange d’identités et d’attributs entre domaines de sécurité </li></ul>
=== Liberty Alliance ===
<p>ET d'autres...
 
</p><p>OpenID <a href="http://openid.net/" alt="http://openid.net/" title="http://openid.net/">http://openid.net/</a>
*Consortium d’industriels produisant des spécifications sur la gestion d’identités
</p>
*S’appuie sur SAML
<ul><li>Protocole de délégation d'authentification </li>
*Implémenté dans de nombreux produits
<li>Origine&#160;: authentification sur les blogs </li>
 
<li>Principe&#160;:
=== Shibboleth ===
<ul><li>1.Saisie de l’URI de son OpenID provider </li>
 
<li>2.Redirection vers l’OpenID provider </li>
*Norme et produit développé par Internet2
<li>3.Authentification  </li></ul></li>
*Open source
<li>Développement rapide de la technologie </li>
*Première version en 200
<li>Nombreux services compatibles </li>
*•Basé sur SAML (bibliothèque OpenSAML
<li>Nombreuses implémentations </li></ul>
*•Utilisé surtout par des universités
<p>Oauth <a href="http://oauth.net" alt="http://oauth.net" title="http://oauth.net">http://oauth.net</a>
*Conçu pour interconnecter les SSO des universités
</p>
*Fonctionnalités
<ul><li>Standard récent (version 1.0, décembre 2007) </li>
**Délégation d’authentification
<li>Définit un standard permettant la délégation d'un utilisateur pour l'accès à un service </li>
**WAYF pour orienter l’utilisateur
<li>Exemple d'utilisation
**Propagation des attributs utilisateur
<ul><li>–Un utilisateur autorise un service d'impression à accéder à ses photos sur un site de gestion de photos  </li></ul></li>
**Partage de méta données
<li>Oauth est complémentaire de OpenID </li></ul>
**Définition de règles de confiance 
<h2> Apports de la fédération d'identités</h2>
 
<p>Pour l’utilisateur&#160;:
=== WS-Federation ===
</p>
 
<ul><li>–Il n’utilise que le mot de passe de son SSO </li>
*Draft porté par Microsoft et IBM, 2003
<li>–Adapté aux utilisateurs nomades </li></ul>
*Basée sur les spécifications WS-*
<p>Pour l’établissement de rattachement
**–WS-Security, WS-Trust, WS-Policy, WS-MetadataExchange 
</p>
*Définit l’échange d’identités et d’attributs entre domaines de sécurité
<ul><li>–Niveau de sécurité constant (SSO) </li>
 
<li>–Meilleure maîtrise des données personnelle </li></ul>
ET d'autres...
<p>Pour les gestionnaires de ressources
 
</p>
OpenID <a href="[http://openid.net/ http://openid.net/]" alt="[http://openid.net/ http://openid.net/]" title="[http://openid.net/ http://openid.net/]">[http://openid.net/ http://openid.net/]</a>
<ul><li>–Plus besoin de gérer des comptes utilisateurs </li>
 
<li>–Accès à des données utilisateurs fiables </li></ul>
*Protocole de délégation d'authentification
<h1> Dans la pratique</h1>
*Origine&nbsp;: authentification sur les blogs
<h2> LemonLDAP-ng</h2>
*Principe&nbsp;:
<p><a href="https://lemonldap-ng.org/documentation/latest/start" alt="https://lemonldap-ng.org/documentation/latest/start" title="https://lemonldap-ng.org/documentation/latest/start">https://lemonldap-ng.org/documentation/latest/start</a>
**1.Saisie de l’URI de son OpenID provider
</p><p>LemonLDAP::NG est un logiciel open source, créé en 2004 par la Gendarmerie nationale française, en fourchant le logiciel LemonLDAP. Il fournit une solution d'authentification unique distribuée avec gestion centralisée des droits sous licence GPL. (Wikipédia).
**2.Redirection vers l’OpenID provider
</p><p>Je pars comme toujours d'une Debian 9.
**3.Authentification 
</p><p>Dans l'installation suivante, il fournit deux sites web importants&#160;:
*Développement rapide de la technologie
</p>
*Nombreux services compatibles
<ul><li>auth.ju.lab&#160;: pour que les utilisateurs s'authentifient </li>
*Nombreuses implémentations
<li>manager.ju.lab&#160;: interface de gestion, à protéger&#160;! </li></ul>
 
<h3> Installation et configuration</h3>
Oauth <a href="[http://oauth.net http://oauth.net]" alt="[http://oauth.net http://oauth.net]" title="[http://oauth.net http://oauth.net]">[http://oauth.net http://oauth.net]</a>
<p>On commence par installer depuis les repos lemonldap (ert surtout pas les repos debian...)&#160;:
 
</p>
*Standard récent (version 1.0, décembre 2007)
*Définit un standard permettant la délégation d'un utilisateur pour l'accès à un service
*Exemple d'utilisation
**–Un utilisateur autorise un service d'impression à accéder à ses photos sur un site de gestion de photos 
*Oauth est complémentaire de OpenID
 
== Apports de la fédération d'identités ==
 
Pour l’utilisateur&nbsp;:
 
*–Il n’utilise que le mot de passe de son SSO
*–Adapté aux utilisateurs nomades
 
Pour l’établissement de rattachement
 
*–Niveau de sécurité constant (SSO)
*–Meilleure maîtrise des données personnelle
 
Pour les gestionnaires de ressources
 
*–Plus besoin de gérer des comptes utilisateurs
*–Accès à des données utilisateurs fiables
 
= Dans la pratique =
 
== LemonLDAP-ng ==
 
<a href="[https://lemonldap-ng.org/documentation/latest/start https://lemonldap-ng.org/documentation/latest/start]" alt="[https://lemonldap-ng.org/documentation/latest/start https://lemonldap-ng.org/documentation/latest/start]" title="[https://lemonldap-ng.org/documentation/latest/start https://lemonldap-ng.org/documentation/latest/start]">[https://lemonldap-ng.org/documentation/latest/start https://lemonldap-ng.org/documentation/latest/start]</a>
 
LemonLDAP::NG est un logiciel open source, créé en 2004 par la Gendarmerie nationale française, en fourchant le logiciel LemonLDAP. Il fournit une solution d'authentification unique distribuée avec gestion centralisée des droits sous licence GPL. (Wikipédia).
 
Je pars comme toujours d'une Debian 9.
 
Dans l'installation suivante, il fournit deux sites web importants&nbsp;:
 
*auth.ju.lab&nbsp;: pour que les utilisateurs s'authentifient
*manager.ju.lab&nbsp;: interface de gestion, à protéger&nbsp;!
 
=== Installation et configuration ===
 
On commence par installer depuis les repos lemonldap (ert surtout pas les repos debian...)&nbsp;:
<pre class="code">vi /etc/apt/sources.list.d/lemonldap-ng.list
<pre class="code">vi /etc/apt/sources.list.d/lemonldap-ng.list
#Ajouter&#160;:  
#Ajouter&#160;:  
Ligne 199 : Ligne 252 :
wget -O - https://lemonldap-ng.org/_media/rpm-gpg-key-ow2 | apt-key add -
wget -O - https://lemonldap-ng.org/_media/rpm-gpg-key-ow2 | apt-key add -
apt update
apt update
apt install apache2 libapache2-mod-perl libapache2-mod-fcgid
apt install apache2 libapache2-mod-perl2 libapache2-mod-fcgid
apt install lemonldap-ng  
apt install lemonldap-ng  
</pre>
</pre>
<p>Puis je change le example.org en y mettant mon domaine à la place (penser au DNS ou au fichier hosts par la suite&#160;!)
 
</p>
Puis je change le example.org en y mettant mon domaine à la place (penser au DNS ou au fichier hosts par la suite&nbsp;!)
<pre>sed -i 's/example\.com/ju.lab/g' /etc/lemonldap-ng/* /var/lib/lemonldap-ng/conf/lmConf-1.js</pre>
<pre>sed -i 's/example\.com/ju.lab/g' /etc/lemonldap-ng/* /var/lib/lemonldap-ng/conf/lmConf-1.js</pre>
<p>On modifie le fichier hosts de notre serveur:
 
</p>
On modifie le fichier hosts de notre serveur:
<pre>cat /etc/lemonldap-ng/for_etc_hosts &gt;&gt; /etc/hosts
<pre>cat /etc/lemonldap-ng/for_etc_hosts &gt;&gt; /etc/hosts
echo &quot;127.0.0.1 reload.ju.lab&quot; &gt;&gt; /etc/hosts
echo &quot;127.0.0.1 reload.ju.lab&quot; &gt;&gt; /etc/hosts
</pre>
</pre>
<p>Suite à l'installation via apt, il n'est en théorie pas nécessaire d'intégrer LemonLDAP à Apache. Il y'a juste à activer les sites et les mods&#160;:
 
</p>
Suite à l'installation via apt, il n'est en théorie pas nécessaire d'intégrer LemonLDAP à Apache. Il y'a juste à activer les sites et les mods&nbsp;:
<pre>a2ensite portal-apache2.conf
<pre>a2ensite portal-apache2.conf
a2ensite manager-apache2.conf
a2ensite manager-apache2.conf
Ligne 217 : Ligne 270 :
a2enmod fcgid perl alias rewrite headers
a2enmod fcgid perl alias rewrite headers
systemctl restart apache2</pre>
systemctl restart apache2</pre>
<p>Désormais, je peux accéder à auth.ju.lab et à manager.ju.lab.
 
</p><p>Le compte de démo par défaut est&#160;: dwho - dwho
Désormais, je peux accéder à auth.ju.lab et à manager.ju.lab.
</p><p>&#160;
 
</p><p>&#160;
Le compte de démo par défaut est&nbsp;: dwho - dwho
</p><p>&#160;
 
</p><p>&#160;
On arrive sur l'interface&nbsp;:
</p><p>&#160;
 
</p></div>
[[File:Lemoninterf.png|RTENOTITLE]]
 
Je vais ensuite installer un glpi sur la même machine. Pour résumer&nbsp;:
 
*Télécharger glpi sur la machine
*installer:
**php php-ldap php-imap php-apcu php-xmlrpc php-cas php-mysqli php-mbstring php-curl php-gd php-simplexml php-xml
**Installer mariadb et faire une base pour glpi avec un utilisateur
**Créer un fichier de vhost pour glpi
**Aller sur le site et lancer l'installation. 
 
&nbsp; &nbsp;
 
&nbsp;
 
&nbsp;
 
&nbsp;
 
&nbsp;
 
&nbsp;
 
&nbsp;

Version du 31 mars 2019 à 17:12

Single Sign-On

Liens

Panorama de solutions : <a href="http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite" alt="http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite" title="http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite">http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite</a>

Présentation

Le SSO consiste à centraliser les authentifications; on uniformise la sécurité de l'authentification, quelle que soit la plateforme. On peut ensuite appliquer une politique de mdp et gérer l'authentification via des protocoles normalisés et sécurisés (LDAP, Kerberos, CAS, RADIUS, etc). Le SSO est un début pour passer ensuite à l'authentification multi-facteurs. Les buts sont :

  • Amélioration de la sécurité
  • Simplifier l'utilisation
  • Faciliter les opérations pour les gestionnaires

AAA :

  • Authentification : Prouver son identité
  • Authorization : Qu'est-ce que j'ai le droit de faire
  • Accounting : Qu'est-ce que je fais

On a aussi une notion de single logout : je me peut me loguer et me déloguer de manière globale, ce qui est moins évident, parce que chaque application gère son authentification de façon globale. Il faut donc gérer une base centrale des applications qui ont une session d’authentification avec l’utilisateur et mémoriser une URL de déconnexion.–Le single logoutest complexe donc peu implémenté...

Technos utilisées

  • HTTP header : Pour les application proxifiées. On protège les apps, contrôle les urls, et on crée des variables multiples... (???) On a pas besoin de SLO.
    • <img src="/mediawiki/images/3/34/Http_header.png" _fck_mw_filename="Http header.png" _fck_mw_origimgwidth="781" _fck_mw_origimgheight="351" alt="RTENOTITLE" title="RTENOTITLE" style="vertical-align:middle;" />
  • SAML (Security Assertion Markup Language) :standard informatique définissant un protocole pour échanger des informations liées à la sécurité. Basé sur le langage XML, SAML a été développé par OASIS. SAML propose l'authentification unique (en anglais single sign-on ou SSO) sur le web. De cette manière, un utilisateur peut naviguer sur plusieurs sites différents en ne s'authentifiant qu'une seule fois, sans pour autant que ces sites aient accès à des informations trop confidentielles. (wikipédia)
  • Authentification formulaire : Elle est utilisée par les applications sans SSO possible, ne permet pas de SLO, et lente et non recommandée. De plus, on doit stocker les mdp utilisateurs...
  • Il reste aussi CAS, OpenID, WS-federation...

LDAP

cf : <a href="Protocoles">Protocoles</a>

Un annuraire LDAP contient de nombreuses informations relatives aux personnes : compte, mdp, etc; mais aussi aux structures. Il sert au contrôle d'accès (en donnant différents droits sur différents services). Un tas de services s'appuient sur LDAP, chez Windows comme chez Unix.

Recommandations

Recommandations nationales SUPANN (juin 2003), pour que les annuaires de la communauté 'Education Recherche' partagent un modèle identique:

  • assurer l'interopérabilité des différents annuaires (ENT),
  • faciliter la mise en place d'un méta-annuaire national

LDAP a une structure arborescente :

<img src="/mediawiki/images/4/4e/Ldap_struc.png" _fck_mw_filename="Ldap struc.png" _fck_mw_origimgwidth="960" _fck_mw_origimgheight="482" alt="RTENOTITLE" title="RTENOTITLE" style="vertical-align:middle;" />

Exemple d'une entrée 'personnel' : 

dn: uid=declercq,ou=people,dc=univ-lille1,dc=fr
objectClass: inetOrgPerson (classe d'objet par défaut qui caractérise une personne)
  objectClass: supannPerson(recommandations SUPANN)
    objectClass: posixAccount (authentification type Unix)
      objectClass: sambaAccount (ouverture de session Windows)
        objectClass: ustlPerson (interne à l'établissement)
          objectClass: radiusProfile (authentification WiFi)
cn: Declercq Patricksn: Declercq
givenName: Patrick
uid: declercquser
Password:: {CRYPT}ZZZZZZZZZZZZZ
mail: Patrick.Declercq@univ-lille1.fr
telephoneNumber: + 33 3 20 43 44 26
supannCivilite: M.
supannAffectation: CRI – Centre de Ressources Informatiques
supannListeRouge: FALSE
  uidNumber: 6304
  gidNumber: 5000
    lmPassword: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    ntPassword: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
      ustlDepartement: CRI
      ustlRole: Correspondant annuaire de l'USTL
        radiusGroupName: personnel

Les alimentations et les màj peuvent se faire par une base (de scolarité pour les étudiants...), cela permet un changement de mdp interactif, etc. Les personnels passent par Harpège, et par le bouton "mise à jour" de la page annuaire de l'université.
Données nominatives :

Authentification web, SSO, fédération d'identités

Il faut pouvoir gérer le contrôle d'accès aux applications web. Pour cela :

  • On veut restreindre l'accès à une partie du serveur à une population donnée

On peut identifier l'utilisateur par son IP (pas suffisant) et en l'authentifiant.

Apache et les modules d'auth

On peut étendre les fonctionnalités du serveur web Apache en ajoutant des modules :

Authentification et autorisation sont deux processus disjoints (cf. : le haut de la page)

Les briques d'un SSO

  • Le serveur d'authentification : c'est un élément central. Il authentifie l'utilisateur, assure la persistance de la connexion, propage l'identité vers les applications et se répose sur un ou des référentiels (LDAP, NIS...).
  • Les agents d'authentification : ils sont devant chaque ressource à protéger. Il servent d'interface entre le serveur et l'application : redirigent l'utilisateur vers le serveur d'authentification et transmettent sont identité vers l'application. Il peuvent être implémentés sous la forme de librairies clients ou de modules intégrés au serveur web.

Techniques utilisées

  • Pour la communication vers l'utilisateur distant :
    • Requêtes GET ou formulaires POST
    • Redirections
    • JS
  • Persistence des sessions:
    • Cookies !
  • Protection des échanges:
    • SSL
    • Portée et durée de validité des cookies
    • Jetons non rejouables

La gestion des sessions se fait à deux niveaux :

  • Avec le serveur d'authentification, ce qui évite de se réauthentifier à chaque fois
  • Avec l'agent, ce qui évite de renvoyer l'utilisateur vers le serveur à chaque requête.

Aports du SSO

On y gagne en ergonomie : On ne saisit le mdp qu'une seule fois, à un seul endroit. Il faut donc sensibiliser l'utilisateur.

On y gagne en sécurité : On limite l'accès et la circulation des mots de passe, et cela permet aussi la création d'une politique des mots de passe. Enfin, on peut étendre les mode d'authentification.

Pour les applications, on utilise les mêmes librairies d'authentification dans toutes les applications, ce qui permet de mieux les intégrer.

On a le choix, en matière de SSO : Pas de standardisation, et les besoins deviennent vite pressants. On a une multiplication des solutions, de tous types, plus ou moins sûres...

Single logout

Un utilisateur logué globalement doit pouvoir se déloguer globalement, ce qui est plus difficile que SSO à cause de la multiplication des sessions. Il faut donc gérer une base centrales des applications qui ont une session en cours. C'est une technique complexe et peu implémentée.

Ensuite...

On constate donc que les limites d'un service d'authentification apparaissent lorsque l'on veut ouvrir les portes à quelqu'un de l'éxtérieur. Comment reconnaître localement l'identité de quelqu'un qui vient de dehors?

Fédérations d'identités

SAML

  • SAML=Security Assertion Markup Language
  • Standard OASIS en 2002•Répond à un besoin d’interopérabilité
  • Echanges d’assertions de sécurité entre services
  • Indépendant des mécanismes d’authentification

Types d'assertions SAML :

  • Authentification
  • Échange d’attributs
  • Décisions d’autorisation

Liberty Alliance

  • Consortium d’industriels produisant des spécifications sur la gestion d’identités
  • S’appuie sur SAML
  • Implémenté dans de nombreux produits

Shibboleth

  • Norme et produit développé par Internet2
  • Open source
  • Première version en 200
  • •Basé sur SAML (bibliothèque OpenSAML
  • •Utilisé surtout par des universités
  • Conçu pour interconnecter les SSO des universités
  • Fonctionnalités
    • Délégation d’authentification
    • WAYF pour orienter l’utilisateur
    • Propagation des attributs utilisateur
    • Partage de méta données
    • Définition de règles de confiance

WS-Federation

  • Draft porté par Microsoft et IBM, 2003
  • Basée sur les spécifications WS-*
    • –WS-Security, WS-Trust, WS-Policy, WS-MetadataExchange
  • Définit l’échange d’identités et d’attributs entre domaines de sécurité

ET d'autres...

OpenID <a href="http://openid.net/" alt="http://openid.net/" title="http://openid.net/">http://openid.net/</a>

  • Protocole de délégation d'authentification
  • Origine : authentification sur les blogs
  • Principe :
    • 1.Saisie de l’URI de son OpenID provider
    • 2.Redirection vers l’OpenID provider
    • 3.Authentification
  • Développement rapide de la technologie
  • Nombreux services compatibles
  • Nombreuses implémentations

Oauth <a href="http://oauth.net" alt="http://oauth.net" title="http://oauth.net">http://oauth.net</a>

  • Standard récent (version 1.0, décembre 2007)
  • Définit un standard permettant la délégation d'un utilisateur pour l'accès à un service
  • Exemple d'utilisation
    • –Un utilisateur autorise un service d'impression à accéder à ses photos sur un site de gestion de photos
  • Oauth est complémentaire de OpenID

Apports de la fédération d'identités

Pour l’utilisateur :

  • –Il n’utilise que le mot de passe de son SSO
  • –Adapté aux utilisateurs nomades

Pour l’établissement de rattachement

  • –Niveau de sécurité constant (SSO)
  • –Meilleure maîtrise des données personnelle

Pour les gestionnaires de ressources

  • –Plus besoin de gérer des comptes utilisateurs
  • –Accès à des données utilisateurs fiables

Dans la pratique

LemonLDAP-ng

<a href="https://lemonldap-ng.org/documentation/latest/start" alt="https://lemonldap-ng.org/documentation/latest/start" title="https://lemonldap-ng.org/documentation/latest/start">https://lemonldap-ng.org/documentation/latest/start</a>

LemonLDAP::NG est un logiciel open source, créé en 2004 par la Gendarmerie nationale française, en fourchant le logiciel LemonLDAP. Il fournit une solution d'authentification unique distribuée avec gestion centralisée des droits sous licence GPL. (Wikipédia).

Je pars comme toujours d'une Debian 9.

Dans l'installation suivante, il fournit deux sites web importants :

  • auth.ju.lab : pour que les utilisateurs s'authentifient
  • manager.ju.lab : interface de gestion, à protéger !

Installation et configuration

On commence par installer depuis les repos lemonldap (ert surtout pas les repos debian...) : 

vi /etc/apt/sources.list.d/lemonldap-ng.list
#Ajouter : 
# LemonLDAP::NG repository
deb&nbsp;&nbsp;&nbsp;&nbsp; https://lemonldap-ng.org/deb 1.9 main
deb-src https://lemonldap-ng.org/deb 1.9 main
#Puis
apt install apt-transport-https
wget -O - https://lemonldap-ng.org/_media/rpm-gpg-key-ow2 | apt-key add -
apt update
apt install apache2 libapache2-mod-perl2 libapache2-mod-fcgid
apt install lemonldap-ng

Puis je change le example.org en y mettant mon domaine à la place (penser au DNS ou au fichier hosts par la suite !) 

sed -i 's/example\.com/ju.lab/g' /etc/lemonldap-ng/* /var/lib/lemonldap-ng/conf/lmConf-1.js

On modifie le fichier hosts de notre serveur: 

cat /etc/lemonldap-ng/for_etc_hosts >> /etc/hosts
echo "127.0.0.1 reload.ju.lab" >> /etc/hosts

Suite à l'installation via apt, il n'est en théorie pas nécessaire d'intégrer LemonLDAP à Apache. Il y'a juste à activer les sites et les mods : 

a2ensite portal-apache2.conf
a2ensite manager-apache2.conf
a2ensite handler-apache2.conf
a2enmod fcgid perl alias rewrite headers
systemctl restart apache2

Désormais, je peux accéder à auth.ju.lab et à manager.ju.lab.

Le compte de démo par défaut est : dwho - dwho

On arrive sur l'interface :

RTENOTITLE

Je vais ensuite installer un glpi sur la même machine. Pour résumer :

  • Télécharger glpi sur la machine
  • installer:
    • php php-ldap php-imap php-apcu php-xmlrpc php-cas php-mysqli php-mbstring php-curl php-gd php-simplexml php-xml
    • Installer mariadb et faire une base pour glpi avec un utilisateur
    • Créer un fichier de vhost pour glpi
    • Aller sur le site et lancer l'installation.

   

 

 

 

 

 

 

Récupérée de « https://wiki.squi.fr/index.php?title=SSO&oldid=830 »