SSO - Historique des versions

Justine le 22 juin 2022 à 11:58

2022-06-22T11:58:19Z

← Version précédente		Version du 22 juin 2022 à 11:58
Ligne 1 :		Ligne 1 :
			[[Category:reseau]]
			[[Category:linux]]
			[[Category:windows]]
	= Single Sign-On =		= Single Sign-On =

Justine le 1 avril 2019 à 18:51

2019-04-01T18:51:31Z

← Version précédente		Version du 1 avril 2019 à 18:51
Ligne 82 :		Ligne 82 :
	*<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>		*<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>



	= Authentification web, SSO, fédération d'identités =		= Authentification web, SSO, fédération d'identités =
Ligne 95 :		Ligne 96 :
	== Résumé du principe, notamment avec LemonLDAP ==		== Résumé du principe, notamment avec LemonLDAP ==

	Le principe est plutôt simple, en réalité : notre SSO va servir de proxy. L'utilisateur se connecte au SSO, et une fois que c'est fait, celui-ci le laisse accéder à la ressource demandée.		Le principe est plutôt simple, en réalité : notre SSO va servir de proxy. L'utilisateur se connecte au SSO, et une fois que c'est fait, celui-ci le laisse accéder à la ressource demandée.

	Par exemple, avec LemonLDAP, je vais m'y connecter en rentrant mes logins. Une fois que c'est fait, je vais récupérer un token qui me permet d'accéder à mon GLPI.		Par exemple, avec LemonLDAP, je vais m'y connecter en rentrant mes logins. Une fois que c'est fait, je vais récupérer un token qui me permet d'accéder à mon GLPI.
Ligne 232 :		Ligne 233 :

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

	= Dans la pratique =		= Dans la pratique =
Ligne 277 :		Ligne 278 :
	a2ensite manager-apache2.conf		a2ensite manager-apache2.conf
	a2ensite handler-apache2.conf		a2ensite handler-apache2.conf
	a2enmod fcgid perl alias rewrite headers		a2enmod fcgid perl alias rewrite headers proxy_http
	systemctl restart apache2</pre>		systemctl restart apache2</pre>

Ligne 297 :		Ligne 298 :
	**Aller sur le site et lancer l'installation.		**Aller sur le site et lancer l'installation.

	~~ ~~		=== Lien avec GLPI ===

			Dans un deuxième temps, nous allons faire en sorte que l'authentification GLPI passe par LemonLDAP.

			L'architecture est simple, pour rappel :

			-J'ai un serveur avec LemonLDAP.<br/> -J'ai un serveur glpi, qui sert glpi depuis son adresse IP (192.168.1.15 ici) et pas depuis une url (c'est important !)

			Nous allons donc proxyfier glpi à travers LemonLDAP. Pour cela :

			Sur le serveur lemonldap, ajouter l'hôte virtuel apache suivant :
			<pre>###Fichier pour proxifier le glpi à travers LemonLDAP
			<VirtualHost *:80>
			ServerName glpi.ju.lab #L'utilisateur se connecte ici, rentre ses identifiants...
			PerlHeaderParserHandler Lemonldap::NG::Handler #La requête est prise en compte...

			ProxyPass / http://192.168.1.15/ #Et renvoie vers GLPI.

			ErrorLog /var/log/apache2/proxysite_glpi_error.log #Logs custom, assez utiles !
			CustomLog /var/log/apache2/proxysite_glpi_access.log combined
			</VirtualHost>

			#Ensuite, ne pas oublier a2ensite et systemctl restart apache2
			</pre>

			Ensuite de quoi, nous allons configurer cet hôte virtuel depuis le manager de LemonLDAP :

			Je créée ici l'hote virtuel de glpi :

			[[File:Lemonvh1.png]]

			Je modifie la règle d'accès par défaut en "accept":

			[[File:Lemonvh2.png.png]]

			Je modifie l'en-tête exportée :

	~~ ~~		[[File:Lemonvh3.png.png]]

			Une fois que tout ça est sauvegardé, je n'ai plus qu'à me rendre sur GLPI (via son ip pour le moment) pour modifier la méthode d'authentification.

			[[File:Lemonlgpi1.png]]

	~~ ~~		[[File:Lemonglpi2.png]]

	~~ ~~		Enregistrer. Il est désormais possible de lancer une fenêtre de navigation privée et de se rendre sur glpi.ju.lab pour se retrouver face à l'interface d'authentification de LemonLDAP.

	~~ ~~		Ici, je me suis connectée avec dwho, l'utilisateur de démo de lemonldap :

	~~ ~~		[[File:LemonGLPI.png]]

Justine le 31 mars 2019 à 19:25

2019-03-31T19:25:16Z

← Version précédente		Version du 31 mars 2019 à 19:25
Ligne 81 :		Ligne 81 :
	*<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>		*<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>
	*<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>		*<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>


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

			<pdf>Fichier:Sso.pdf</pdf>

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

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

			== Résumé du principe, notamment avec LemonLDAP ==

			Le principe est plutôt simple, en réalité : notre SSO va servir de proxy. L'utilisateur se connecte au SSO, et une fois que c'est fait, celui-ci le laisse accéder à la ressource demandée.

			Par exemple, avec LemonLDAP, je vais m'y connecter en rentrant mes logins. Une fois que c'est fait, je vais récupérer un token qui me permet d'accéder à mon GLPI.

	=== Apache et les modules d'auth ===		=== Apache et les modules d'auth ===
Ligne 223 :		Ligne 232 :

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

	= Dans la pratique =		= Dans la pratique =

Justine le 31 mars 2019 à 17:12

2019-03-31T17:12:19Z

Voir les modifications

Justine le 31 mars 2019 à 15:47

2019-03-31T15:47:18Z

Voir les modifications

Justine le 31 mars 2019 à 13:06

2019-03-31T13:06:23Z

← Version précédente		Version du 31 mars 2019 à 13:06
Ligne 1 :		Ligne 1 :

	= Single Sign-On =		= Single Sign-On =

			== Liens ==

			Panorama de solutions : http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Authentification-federation-et-de-gestion-d-identite

	== Présentation ==		== Présentation ==
Ligne 80 :		Ligne 84 :
	= Authentification web, SSO, fédération d'identités =		= 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 :		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 veut restreindre l'accès à une partie du serveur à une population donnée
Ligne 88 :		Ligne 92 :
	=== Apache et les modules d'auth ===		=== Apache et les modules d'auth ===

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

	*mod_auth : utilisation des fichiers htpasswd et htgroup		*mod_auth : utilisation des fichiers htpasswd et htgroup
	*mod_ssl : gestion SSL et authentification avec certificats		*mod_ssl : gestion SSL et authentification avec certificats
	*mod_authldap : authentification LDAP		*mod_authldap : authentification LDAP
	*mod_authZldap : authentification avec certificats puis autorisation basée sur LDAP		*mod_authZldap : authentification avec certificats puis autorisation basée sur LDAP
	*etc : http://modules.apache.org		*etc : [http://modules.apache.org http://modules.apache.org]

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

	=== Les briques d'un SSO ===		=== 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...).		*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.		*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 ===		=== Techniques utilisées ===

	*Pour la communication vers l'utilisateur distant :		*Pour la communication vers l'utilisateur distant :
	**Requêtes GET ou formulaires POST		**Requêtes GET ou formulaires POST
	**Redirections		**Redirections
	**JS		**JS
	*Persistence des sessions:		*Persistence des sessions:
	**Cookies !		**Cookies !
	*Protection des échanges:		*Protection des échanges:
	**SSL		**SSL
Ligne 116 :		Ligne 120 :
	**Jetons non rejouables		**Jetons non rejouables

	La gestion des sessions se fait à deux niveaux :		La gestion des sessions se fait à deux niveaux :

	*Avec le serveur d'authentification, ce qui évite de se réauthentifier à chaque fois		*Avec le serveur d'authentification, ce qui évite de se réauthentifier à chaque fois
Ligne 123 :		Ligne 127 :
	=== Aports du SSO ===		=== 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 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.		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.		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...		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 ===		=== Single logout ===
Ligne 148 :		Ligne 152 :
	*Indépendant des mécanismes d’authentification		*Indépendant des mécanismes d’authentification

	Types d'assertions SAML :		Types d'assertions SAML :

	*Authentification		*Authentification
Ligne 184 :		Ligne 188 :
	ET d'autres...		ET d'autres...

	OpenID http://openid.net/		OpenID [http://openid.net/ http://openid.net/]

	*Protocole de délégation d'authentification		*Protocole de délégation d'authentification
	*Origine : authentification sur les blogs		*Origine : authentification sur les blogs
	*Principe :		*Principe :
	**1.Saisie de l’URI de son OpenID provider		**1.Saisie de l’URI de son OpenID provider
	**2.Redirection vers l’OpenID provider		**2.Redirection vers l’OpenID provider
Ligne 196 :		Ligne 200 :
	*Nombreuses implémentations		*Nombreuses implémentations

	Oauth http://oauth.net		Oauth [http://oauth.net http://oauth.net]

	*Standard récent (version 1.0, décembre 2007)		*Standard récent (version 1.0, décembre 2007)
Ligne 206 :		Ligne 210 :
	== Apports de la fédération d'identités ==		== Apports de la fédération d'identités ==

	Pour l’utilisateur :		Pour l’utilisateur :

	*–Il n’utilise que le mot de passe de son SSO		*–Il n’utilise que le mot de passe de son SSO

Justine le 31 mars 2019 à 13:05

2019-03-31T13:05:59Z

Voir les modifications

Justine : Page créée avec « = Single Sign-On = == Présentation == Le SSO consiste à centraliser les authentifications; on uniformise la sécurité de l'authentification, quelle que soit la plate... »

2019-03-26T19:20:20Z

Page créée avec « = Single Sign-On = == Présentation == Le SSO consiste à centraliser les authentifications; on uniformise la sécurité de l'authentification, quelle que soit la plate... »

Nouvelle page

= Single Sign-On =

== 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.
**[[File:Http header.png]]
*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 : [[Protocoles|Protocoles]]

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 :

[[File:Ldap struc.png]]

Exemple d'une entrée 'personnel' :
<pre>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</pre>

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 :

*publiées avec l’accord de la personne,
*utilisées dans le cadre d ’un objectif précis,
*durée de conservation raisonnable,
*sécurité physique et logique des données,
*accessibles qu’aux seules personnes autorisées.
*http://www.cnil.fr
*http://www.educnet.education.fr/legamedia

 

SSO - Historique des versions

Justine le 22 juin 2022 à 11:58

Justine le 1 avril 2019 à 18:51

Justine le 31 mars 2019 à 19:25

Justine le 31 mars 2019 à 17:12

Justine le 31 mars 2019 à 15:47

Justine le 31 mars 2019 à 13:06

Justine le 31 mars 2019 à 13:05

Justine : Page créée avec « = Single Sign-On = == Présentation == Le SSO consiste à centraliser les authentifications; on uniformise la sécurité de l'authentification, quelle que soit la plate... »

Justine : Page créée avec « = Single Sign-On = == Présentation == Le SSO consiste à centraliser les authentifications; on uniformise la sécurité de l'authentification, quelle que soit la plate... »