CoursIUTOrsayv 2021 Etudiants

13/01/2021
Cours Sécurité Réseaux

Service d’annuaires LDAP
Identité fédérée & Authentification unique
Nouha OUALHA, oualha@gmail.com
Séances
• Cours (8h)
• Mercredi 13/01/2020 : 8h30 --> 12h30 (4h)
13h30 --> 17h30 (4h)
• Skype Business
• Travaux Pratiques (4h)

• Mercredi 20/01/2020 : 8h30 --> 12h30 (4h) – Gr1
13h30 --> 17h30 (4h) – Gr2
• En présentiel en salle S215
Service d'annuaire LDAP - N. Oualha 2
1
13/01/2021
1ère partie
Service d’annuaires LDAP
Plan
1. Introduction
2. Modèle de données
3. Modèle de nommage
4. Protocole de communication
5. Modèle fonctionnel
6. Modèle de sécurité
2
13/01/2021
1. Introduction
LDAP
• LDAP: Lightweight Directory Access Protocol
• Protocole permettant l'interrogation et la modification d'annuaires
• Un annuaire électronique est une base de données spécialisée qui
permet de partager des informations et les rendre disponibles à des
applications, des systèmes d'exploitation ou des utilisateurs, dans un
réseau
• p. ex. des coordonnées téléphoniques, des données systèmes
• Service 'write-once-read-many-times‘ : performant en lecture mais moins en
écriture (≠ système de gestion de bases de données)
Standards
• Développements menés par l’Internet Engineering Task Force (IETF)

• LDAP, LDAPv2, LDAPv3 [RFC 4510]
• LDAP: Technical Specification Road Map [RFC 4510]
• LDAP: The Protocol [RFC4511]
• LDAP: Directory Information Models [RFC4512]
• LDAP: Authentication Methods and Security Mechanisms [RFC4513]
• LDAP: String Representation of Distinguished Names [RFC4514]
• LDAP: String Representation of Search Filters [RFC4515]
• LDAP: Uniform Resource Locator [RFC4516]
• LDAP: Syntaxes and Matching Rules [RFC4517]
• LDAP: Internationalized String Preparation [RFC4518]
• LDAP: Schema for User Applications [RFC4519]
3
13/01/2021
Exemple : Authentification par LDAP
Annuaire LDAP
Requête
Comptes :
login/pw
…
Réponse (Profil utilisateur)
Exemple : Gestion de données

d’authentification centralisée
Annuaire LDAP
Comptes :
login/pw
…
login
password
4
13/01/2021
Modèles
• Modèle de données décrivant les informations contenues dans

l’annuaire
• Modèle de nommage décrivant comment les informations dans
l’annuaire peuvent être référencées
• Modèle fonctionnel qui décrit comment les informations peuvent
être accédées
• Protocole d’accès aux informations dans l’annuaire
• Retourner un ou plusieurs attributs d'un objet grâce à des fonctions de recherche multi-
critères
• Méthodes pour se connecter, se déconnecter, rechercher des informations,
comparer des informations, insérer des entrées, modifier des entrées,
supprimer des entrées
• Modèle de sécurité pour protéger les informations et leur accès
• ..
2. Modèle de données
Base de données
DIB (Directory
Information Base)
Annuaire
Configuration, LDAP
droits d’accès,
Serveur LDAP schémas, …
Client LDAP
DUA (Directory User DSA (Directory

Agent) System Agent)
5
13/01/2021
Base de données
• Exemple de structure tableaux

Id Nom Email Tel. Fax. Id Unité
1 Jean Dupont dupont@xyz.com +33123456 +33123456 1 Finance
2 Michel Jean miller@xyz.com +33123456 +33123456 2 IT
• Exemple de structure hiérarchique (arbre inversé)

dc=xyz,dc=com
ou=finance ou=IT
cn=Jean Dupont cn=Michel Jean
DIB
• DIB: Directory Information Base

• DIB est composée d'un ensemble d'entrées organisées
hiérarchiquement avec une structure d'arbre DIT : Directory
Information Tree
• DIB contient deux types d'informations:

• Informations sur les utilisateurs
• Elles peuvent être modifiées par les utilisateurs
• p. ex. e-mail, numéro de téléphone
• Informations opérationnelles
• Elles sont liées au fonctionnement de l’annuaire
• Elles ne sont pas accessibles aux utilisateurs
• P. ex. Date d’ajout de l’information
6
13/01/2021
DIT
• Les informations sont présentées sous forme d'une arborescence
d'informations hiérarchique DIT (Directory Information Tree)
• Les informations, dites entrées DSE (Directory Service Entry) sont
représentées sous forme de branches de l’arbre DIT
• Une branche située à la racine d'une ramification est appelée racine ou
suffixe (root entry)
• Chaque entrée de l’arbre contient des informations sur un objet :
– Ensemble de classes d’objets qui spécifient
l’objet (au moins une classe d’objets)
– Ensemble d'attributs (paires type/valeur)
permettant de caractériser l'objet: attributs
obligatoires ou optionnels
Identificateur d’objet
• L’identificateur d’objet OID (Object Identifier) est un identifiant unique

• Objet
• Chaque classe d’objet
• Chaque type d’attribut
• Syntaxes et règles de comparaison
• L'objectif des OID est d'assurer l'interopérabilité entre plusieurs implémentations
oid = descr / numericoid
• <descr> généralement préférable
• <numericoid> utilisé lorsque les <descr> peuvent identifier plusieurs types d'objets ou un
nom court (short name) sans ambiguïté (descripteur) n'est pas disponible
• <numericoid> est composé d'une suite d'entiers séparés par un point (entiers
organisés sous forme hiérarchiques)
• Tous les attributs du standard commencent par 2.5.4. Short names
• Toutes les classes d’objet commencent par 2.5.6. DN distinguished name
CN common name
• Exemples d’OID d’attributs: DC domain components
cn;lang-de;lang-en SN surname
O organization
2.5.4.3 OU organizational unit
UID user ID
St State or Province Name
7
13/01/2021
Attribut
• Attribut : une description d'attribut (un type avec zéro ou plusieurs

options) et une ou plusieurs valeurs associées
• Chaque type d'attribut est identifié par un OID et un ou plusieurs
descripteurs (noms abrégés: short names)
• La valeur (ou les valeurs) est conforme à la syntaxe définie par le type
d'attribut
• Si l’attribut est utilisé pour nommer l'entrée, une seule valeur de l'attribut est utilisée,
dite valeur distinctive
• Deux types:
• Attributs obligatoires (requis): doivent être présents dans l’entrée (p. ex. le
nom d’une personne)
• Attributs optionnels: peuvent être présents dans l’entrée (p. ex. un numéro
de fax)
• L’ensemble d’attributs obligatoires et optionnels est spécifié par la
classe d’objets associée à l’entrée
Exemple 1/2 : Attribut
OID Nom
attributetype ( 2.5.4.5 NAME 'serialNumber'

Courte description de l’attribut
DESC 'RFC2256: serial number of the entity'
EQUALITY caseIgnoreMatch Critères de comparaison et filtres
SUBSTR caseIgnoreSubstringsMatch utilisés lors d’une recherche
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
Syntaxe décrivant le type de données

(OID du type + chaîne de caractères
longue d’au plus 64 caractères)
8
13/01/2021
Exemple 2/2 : Attribut
attributetype ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainComponent' )

DESC 'RFC1274/2247: domain component'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
Si un type attribut accepte uniquement une

seule valeur (par défaut, les attributs
acceptent plusieurs valeurs), ceci doit être
défini explicitement dans sa définition
Classe d’objets
• Classe d’objets: famille d’objets qui partagent certaines

caractéristiques
• Définit l’ensemble d’attributs nécessaires et l’ensemble d’attributs optionnels
de ces objets
• La classe d’objets hérite les attributs des classes d’objet dont elle hérite
• Une classe est identifiée par un OID + descripteur(s)
• Trois types:
• Classe abstraite: fournit les caractéristiques de base pour les autres types
de classes
'top' object class: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
• Une entrée ne peut pas uniquement appartenir à une classe abstraite, mais elle peut
appartenir à une classe qui hérite d’une classe abstraite
• Classe structurelle: utilisée pour spécifier la structure du DIT
• Sous-classe (directement ou indirectement) de la classe d'objet abstrait 'top'
• Classe auxiliaire: utilisée pour augmenter les caractéristiques des entrées
9
13/01/2021
Exemple : Classe d’objets 1/3

OID Nom
une courte description de la classe
objectclass ( 2.5.6.6 NAME 'person'
DESC 'RFC2256: a person' La classe dont elle est dérivée
SUP top STRUCTURAL
Son type (ABSTRACT, STRUCTURAL, AUXILIARY)
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ Liste des attributs
seeAlso $ description ) ) obligatoires (MUST)
Liste des attributs facultatifs (MAY)
Héritage de classes d’objets

• Pas d’héritage multiple: une classe ne peut dériver directement que d’une seule classe
• La classe top ne possède qu’un seul attribut : objectClass
top
objectclass
country person organization dcObject

c sn o dc
searchGuide cn userPassord
description userPassword telephoneNumber
telephoneNumber
seeAlso
organizationalPerson residentialPerson
Street l
PostalAddress street
PostalCode PostalCode
10
13/01/2021
objectclass ( 2.5.6.7 NAME 'organizationalPerson'

SUP person La classe est dérivée d’une classe
d’objets ‘person’
STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
ou $ st $ l ) )
objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'

SUP top
AUXILIARY
MUST dc )
11
13/01/2021
Schéma Exemple d’un schéma : “core.schema”

attributetype ( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
• Un schéma d'annuaire LDAP est un
ensemble de définitions et de attributetype ( 2.5.4.49 NAME 'distinguishedName'
contraintes sur la structure de la DIT EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
• Il permet de garantir la validité et …
l’intégrité des données attributetype ( 2.5.4.16 NAME 'postalAddress'
EQUALITY caseIgnoreListMatch
• La spécification d’un schéma dépend SUBSTR caseIgnoreListSubstringsMatch
des logiciels déployés SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
• p. ex. le logiciel OpenLDAP utilise un attributetype ( 2.5.4.17 NAME 'postalCode'

fichier de configuration slapd.conf EQUALITY caseIgnoreMatch
pour définir les schémas SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
…
objectclass ( 2.5.6.0 NAME 'top' ABSTRACT
MUST objectClass )
…
objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL
MUST c
MAY ( searchGuide $ description ) )
….
Serveurs LDAP distribués
• L’accès au DIT est fourni conjointement par un ou plusieurs serveurs

• Le serveur qui détient les informations d'origine est appelé le maître
• Les serveurs qui contiennent des copies de l'information d'origine
sont appelés shadows ou serveurs de mise en cache
• Chaque serveur a des attributs différents dans rootDSE (root DSA-
Specific Entry)
12
13/01/2021
rootDSE
• Attributs du rootDSE
• altServer: serveurs alternatifs
• namingContexts: sous-arbre d’entrées
• supportedControl: les contrôles LDAP reconnus
• supportedExtension: opérations LDAP étendues reconnues
• supportedFeatures: caractéristiques LDAP reconnus
• supportedLDAPVersion: version LDAP supportée
• supportedSASLMechanisms: mécanismes d’authentification SASL reconnus
LDIF
• LDIF : LDAP Interchange Format

• Standard de représentation des entrées sous format texte (RFC 2849)
• Imports/exports de l’annuaire ou d’une partie de l’annuaire
• Créer, ajouter, ou modifier des entrées de manière automatisée tout en
obéissant aux règles définies dans le schéma de l’annuaire
dn: cn=bar,dc=exemple,dc=fr
objectClass: top
Serveur …
LDAP dn: cn=oualha,ou=Personnel,
dc=exemple,dc=fr
objectClass: person
cn:Nouha Oualha
sn: oualha
Serveur …
LDAP
13
13/01/2021
Exercice 1
• Donnez les attributs obligatoires et optionnels de la classe d’objet

suivante :
objectClass ( 1.3.6.1.1.1.2.7
NAME 'ipNetwork'
DESC 'Standard LDAP objectclass'
SUP top
STRUCTURAL
MUST ( ipNetworkNumber $ cn )
MAY ( ipNetmaskNumber $ manager $ l $ description )
X-ORIGIN 'RFC 2307' )
3. Modèle de nommage
• Une entrée dans DIT représente un objet particulier

• RDN (relative distinguished name (s)) : désigne une entrée depuis une
position particulière de l’arbre
• RDN d'une entrée doit être unique parmi tous les subordonnés immédiats de son
supérieur hiérarchique direct
• DN (distinguished name) : le nom de l’entrée sous la forme d’un chemin
d’accès à celle-ci depuis le sommet de l’arbre DIT
• DN d’une entrée est la concaténation de son RDN avec le DN de son supérieur
hiérarchique direct
• Exemple:
UID=nobody@example.com,DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
• Chaque entrée est référencée de manière unique par son distinguished

name (DN)
• Unicité obtenue par la combinaison des attributs
14
13/01/2021
Exemple
• Dans la norme X500, le niveau top est le pays et vient ensuite le nom de
l'organisation, ce qui donne par exemple comme suffixe : dc=exemple,dc=fr
dc=fr
dc=exemple dn: dc=exemple,dc=fr
ou=Personnel ou=Groupe ou=Machines
cn=oualha cn=jean dn: cn=jean,ou=Personnel,dc=exemple,dc=fr
Exercice 2
• Donnez les DNs des quatre entrées illustrées dans le graphe suivant:
dc=fr
objectClass: top
objectClass: organization
objectClass: dcObject dc=ups
dc: ups
o: ups
objectClass: top objectClass: top

objectClass: organizationalUnit objectClass: organizationalUnit
description: la ville de Paris
ou=paris ou=marseille
description: la ville de Marseille
ou: paris ou: marseille
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: 1 uid=1
cn: Jean Dupont
sn: Dupont
givenName: Jean
userPassword: 2Mzrhc9cAR0RQ
15
13/01/2021
Referrals et Aliases
• Deux objets particuliers sont abstraits : referral et alias

• alias est un nom alternatif pour une entrée d'objet ou un objet qui est fournie par
l'utilisation d'entrées d'alias, elle permet à une entrée de l'annuaire de pointer vers une
autre entrée
• Exemple :
dn: cn=bar,dc=exemple,dc=fr
objectClass: top
objectClass: alias
objectClass: extensibleObject
cn: bar
aliasedObjectName: cn=foo,dc=exemple,dc=fr bar foo
• referral permet à une entrée de l'annuaire de pointer vers une entrée dans un autre
annuaire
• Utilisant un URI p. ex. URL
• Syntaxe: scheme://domain:port/path?query_string#fragment_id
• Exemple :
dn: o=UPS,dc=exemple,dc=fr
objectClass: referral
objectClass: extensibleObject
o: UPS
ref: ldap://ldap2.exemple.fr/o=UPS,dc=exemple,dc=net
4. Protocole de communication
• Communication client-serveur
• Modèle client/serveur
• (dé)connexion: bind, unbind, abandon
• Le client envoie des requêtes d'opération au serveur et le serveur envoie en
retour des réponses
• Communication serveur-serveur
• Liens entre différents annuaires (service referral)
• Transport des données
• Protocole TCP/IP (port 389, port 636 pour LDAPs)
• Basic Encoding Rules (BER)
16
13/01/2021
Requête/Réponse LDAP 1/2

LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE { • Chaque opération traitée comme
bindRequest BindRequest, action atomique
bindResponse BindResponse,
unbindRequest UnbindRequest, • Chaque réponse doit inclure le
searchRequest SearchRequest, messageID inclut dans la requête
modifyRequest ModifyRequest, correspondante
addRequest AddRequest,
delResponse DelResponse, • Typiquement, chaque client
compareRequest CompareRequest, incrémente un compteur
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
... }, • Synchronisation entre client et
controls [0] Controls OPTIONAL } serveur pas nécessaire
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- • Réponses aux requêtes peuvent
arriver dans n’importe quel ordre,
l’ordre des réponses peut être
contrôlé par l’application chez le client
Requête/Réponse LDAP 2/2
(1) Requête
(2) Réponse {Referral}
Serveur
Client LDAP
LDAP
Serveur
LDAP
• Au moins un URI (p. ex. URL) est présent dans le referral
17
13/01/2021
5. Modèle fonctionnel
• Les opérations classiques sont :

• Start TLS : permet l’utilisation de la couche Transport Layer Security (TLS) pour
sécuriser la connexion
• Bind : permet d’indiquer la version du protocole utilisé et authentifier l'utilisateur
• Un bind anonyme est possible (le client ne fournit pas ni nom d'utilisateur ni mot de passe )
• Search : permet la recherche dans l'annuaire et l’extraction des données
• Compare : permet de déterminer si une entrée contient un attribut avec une
valeur donnée
• Add : permet d’ajouter une nouvelle entrée
• Delete : permet de supprimer une entrée
• Modify : permet de modifier une entrée
• Modify DN : permet de déplacer ou de renommer une entrée
• Abandon : permet l’annulation de la requête précédente
• Extended Operation : opération qui permet de définir d'autres opérations
• Unbind : permet la clôture de la session
• Unsolicited Notifications: notifications non sollicitées envoyées par le serveur
(p.ex. pour vérifier si la session LDAP est toujours en vie)
Requête “Search”
SearchRequest ::= [APPLICATION 3] SEQUENCE {

baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2), ... },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeSelection }
18
13/01/2021
Scope de la requête
• Scope permet de définir la profondeur de la recherche dans le DIT

• baseObject: Le champ d'application de la requête est limité à l'entrée
nommée par baseObject
• singleLevel: Le champ d'application de la requête est limité aux subordonnés
immédiats de l'entrée nommée par baseObject
• wholeSubtree: Le champ d'application de la requête est limité à l'entrée
nommée par baseObject et à tous ses subordonnés
• Recherche récursive dans toutes les branches du sous-arbre prenant racine à la base
considérée
Filtre
• Un filtre définit les conditions qui doivent être remplies pour que la
recherche correspond à une entrée donnée
• Forme : <attribut operateur valeur>
Type Operateur Exemple(s)
Equality = cn=Bob Johnson
Substring =string* string cn=Bob* cn=*Johnson cn=*John* cn=B*John
Greater than or equal to >= buildingname >= alpha
Less than or equal to <= buildingname <= alpha.
Presence =* cn=* telephonenumber=* manager=*.
Approximate ~= cn~=suret l~=san
• Il est composé d’un ensemble de conjonctions et/ou de disjonctions de

filtres
• Exemples:
"cn=John Browning"
"cn=John*"
"roomNumber<=300"
"(!(cn=John Browning))" or "(!(roomNumber<=300))"
19
13/01/2021
Modification
• Les opérations de modification (ajout, suppression, modification, etc) à

effectuer sur une entrée doivent être effectuées dans l'ordre des
requêtes reçues
• Chaque opération est effectuée comme une seule opération atomique
• Les serveurs LDAP doivent s'assurer que les entrées restent toujours
conformes aux règles d'utilisation (p. ex. syntaxe), le schéma du système,
et autres contraintes du modèle de données
6. Modèle de sécurité
Couche message LDAP  LDAP PDU
 Données protégées
Application Couche SASL
par SASL
 Données protégées par

Couche TLS
TLS
Transport Connexion transport
20
13/01/2021
Attaques
1) Accès non autorisé aux données de l'annuaire en contrôlant l'accès d’autres clients (c.
à. d. en regardant les réponses destinées à d’autres clients)
2) Accès non autorisé aux données d'annuaire via des opérations de récupération de
données (p. ex. opération Search)
3) Accès non autorisé à l'information d'authentification d’un client qui peut être
réutilisable (p. ex. mot de passe en clair)
4) Toute modification non autorisée de données de l'annuaire
5) Toute modification non autorisée d'informations de configuration
6) Déni de service: utilisation des ressources (souvent en excès) d'une manière destinée à
refuser le service à d'autres clients
7) Spoofing:
• Tromper un utilisateur ou un client en lui faisant croire que l'information qui est fausse venait de
l’annuaire (en modifiant les données en transit ou leur destination)
• Inciter un utilisateur ou client à envoyer une information privilégiée (p. ex. mot de passe) à une
entité hostile en se faisant passer pour un serveur d'annuaire
• Tromper un serveur d'annuaire en lui faisant croire que l'information venant en réalité d’une
entité hostile, vient d'un client particulier
8) Détournement (Hijacking): un attaquant prend le contrôle d'une session établie
Mécanismes de sécurité
• Authentification au moyen de l'opération de liaison Bind qui fournit

plusieurs méthodes d'authentification
• Contrôle d'accès aux données: généralement basé sur des listes de contrôle
d’accès
• Intégrité et confidentialité des données (couches de sécurité TLS ou

mécanismes SASL)
• Limitation de l'utilisation des ressources du serveur par des limites

administratives configurées sur le serveur
• Authentification du serveur au moyen du protocole TLS ou les mécanismes

SASL
• D’autres moyens de sécurité sont possibles p. ex. IPsec
21
13/01/2021
TLS 1/2
• Le protocole est composé de deux niveaux:

• Protocole de poignée de mains TLS (Handshake Protocol) : permet au serveur et
au client de s'authentifier mutuellement, de négocier un algorithme de
chiffrement/intégrité, et d’échanger une clé cryptographique
• Protocole de niveau inférieur TLS (Record Protocol): encapsule le message et
assure sa confidentialité et son intégrité
Client LDAP Serveur LDAP
SYN
SYN ACK
TCP
ACK
ClientHello
ServerHello Certificate
ServerHelloDone SSL/TLS poignée de mains
ClientKeyExchange
(Handshake)
ChangeCipherSpec Finished
ChangeCipherSpec Finished
Application LDAP / TLS Application sur SSL/TLS

Application LDAP / TLS
niveau inférieur (Record)
TLS 2/2
• Pour demander l’établissement d’un canal sécurisé TLS

• Le client envoie une requête StartTLS au serveur
• La requête est définie comme extendedRequest
• requestName : "1.3.6.1.4.1.1466.20037", requestValue absent
• Si le serveur supporte TLS, il envoie une réponse StartTLS au demandeur
• responseName : "1.3.6.1.4.1.1466.20037", responseValue absent
• resultCode succès
• Par la suite, le client et le serveur peuvent commencer la négociation
(poignée de mains) TLS
• Canal sécurisé en TLS peut être aussi établi et utilisé (d’une manière
implicite) sans les requêtes/réponses StartTLS de LDAP
• Le client vérifie l'identité du serveur qui est utilisée pour établir la connexion
TLS (identité de référence)
• Le client peut se servir d’autres moyens p. ex. nom ou adresse IP dans DNS
(Domain Name System)
22
13/01/2021
Exemple : Modèle de connexion avec TLS

Client Serveur
StartTLS Request
StartTLS Response
Handshake TLS
Bind Request
Bind Response
Search/Add/Delete … Request
Response done
…
Unbind Request
Requête “Bind”
BindRequest ::= [APPLICATION 0] SEQUENCE {

version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {

simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
SaslCredentials ::= SEQUENCE {

mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
23
13/01/2021
Authentification simple
• Méthode d'authentification simple spécifiée dans la requête Bind fournit trois

mécanismes :
• Mécanisme d'authentification anonyme : requête Bind contenant une valeur
de nom de longueur nulle avec une valeur de mot de passe de longueur nulle
• Mécanisme d'authentification en mode non authentifié : requête Bind
contenant une valeur de nom de longueur non nulle avec une valeur de mot
de passe de longueur nulle
• Mécanisme d'authentification nom/mot de passe : requête Bind contenant
une une valeur de nom de longueur non nulle avec une valeur de mot de
passe de longueur non nulle
• Nom de longueur non nulle est sous forme de chaîne de caractères et est
distinctif dans le serveur LDAP (c. à. d. DN)
• Valeur de mot de passe de longueur non nulle est sous forme d’octets
• Une association « non authentifiée » est considérée comme équivalent à une

association anonyme
Recommandations [RFC 4513]
• Implémentations du serveur LDAP doivent prendre en charge le

mécanisme anonyme d'authentification simple de la requête Bind
• Implémentations LDAP qui soutiennent un deuxième mécanisme

d'authentification doivent prendre en charge le mécanisme
d'authentification nom/mot de passe et doivent être capable de
protéger cette authentification en utilisant TLS établie par
l'opération StartTLS
• Implémentations de support TLS doivent prendre en charge la

suite de chiffrement (ciphersuite)
TLS_RSA_WITH_3DES_EDE_CBC_SHA et soutenir la suite
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
24
13/01/2021
SASL
• SASL : Simple Authentication and Security Layer
• SASL est supporté par LDAPv3
• LDAPv2 ne supporte pas SASL
D’autres
SMTP LDAP
protocoles …
Couche d’abstraction SASL
D’autres
EXTERNAL GSSAPI
mécanismes …
Mécanismes d’authentification SASL
• Quelques mécanismes d’authentification SASL :

• EXTERNAL: authentification dérivée du contexte (p. ex. par les protocoles
IPsec ou TLS)
• DIGEST-MD5: mécanisme basé sur MD5 et compatible HTTP. Il fournit en
plus une couche d'intégrité des données
• Rendue obsolète
• GSSAPI: authentification Kerberos v5 via GSSAPI. GSSAPI fournit aussi une
couche d'intégrité des données
• OTP, SRP, …
• Le client récupère l'attribut 'supportedSASLMechanisms' de la rootDSE

avant ou après l'échange d'authentification SASL
• Le client vérifie si les mécanismes qu’il supporte, y figurent
• P. ex.: L’application client JXplorer supporte une authentification simple et
authentification SASL avec les mécanismes EXTERNAL et GSSAPI
25
13/01/2021
Exemple: Authentification SASL avec DIGEST-

MD5
Client Serveur
Bind_Request(DIGEST-MD5)
Bind_Response(Challenge) Challenge=nonce
HA1=MD5(username:realm:password)
HA2=MD5(method:digestURI)
response=MD5(HA1:nonce:HA2) Bind_Request(Response)
Bind_Response(Success/Failure)
Contrôle d’accès
• LDAP n'offre pas un mécanisme de contrôle d'accès standard

• Implémentation dépend du fournisseur du service LDAP
• Généralement, au moins deux niveaux d’accès

• Lecture seulement (read-only) p.ex. search, compare
• Lecture-écriture (mise à jour) p. ex. modify, add, delete
26
13/01/2021
Contrôle d’accès (implémenté par OpenLDAP)
access to <quoi> by <qui> <type_d’acces_autorisé>

• Quoi ? Exemples :
* : toutes les entrées de l’annuaire access to dn.subtree="dc=example,dc=com"
dn.<scope>=<expression régulière> by self write
attrs=<liste d’attributs> by dn.children="dc=example,dc=com" search
filter=<filtre ldap> by anonymous auth
access to *
• Qui ? by * read
* : tous les utilisateurs anonymes ou authentifiés
Anonymous : utilisateur non authentifié et donc anonyme
Self : utilisateur associé à l’entrée ciblée
Users : utilisateur authentifié
dn.<scope>=<expression régulière>
• type_d’acces_autorisé ?
write : modifier/renommer
read : lecture des résultats de recherche
search : requis pour l’application de filtre de recherche
compare : requis pour les comparaisons
auth : autorisé à accéder à un attribut uniquement pour s’authentifier (bind)
none : aucun accès
disclose: autorise la divulgation d’information en cas d’erreur
rwx …
Exercice 3
• Donnez la règle d’accès qui autorise les access to attrs=userPassword

actions suivantes sur l’attribut
"userPassword" : by self =xw (mettre à jour uniquement)
by anonymous auth
• "Modification uniquement" par les
utilisateurs des entrées associées by * none
• "Demande d’authentification" pour les
utilisateurs anonymes
• "Rien" pour tout le reste
• Donnez la règle d’accès qui autorise les access to dn.subtree="dc=example,dc=com"

actions suivantes sur l’attribut attrs=homePhone
"homePhone" dans les entrées "dn: by self write
dc=example,dc=com" : by dn.children="dc=example,dc=com" search
• "Écriture" par les utilisateurs des by anonymous auth
entrées elles mêmes "dn:
dc=example,dc=com"
• "Recherche" par les enfants des
entrées "dn: dc=example,dc=com"
• "Demande d’authentification" pour les
utilisateurs anonymes
27
13/01/2021
Identité d’autorisation 1/2
• SASL met en œuvre deux sortes d’identités :

• Identité associée au processus d’authentification (identité d’authentification)
• P. ex.: nom de l’utilisateur/login, identité Kerberos, …
• Identité spécifiant l’utilisateur réel (identité d’autorisation) c. à. d. : DN
• Si cette identité est absente, l’identité d’authentification joue le rôle de
l’identité d’autorisation
• Lors de l’échange SASL, le client fournit, de manière optionnelle, une chaîne de

caractères représentant l’identité d’autorisation demandée
• Si cette chaîne de caractères est omise ou bien est vide, le client demande à
agir en tant qu’utilisateur associé à l’identité d’authentification
• Généralement, l'identité d'autorisation d'une session LDAP est
sémantiquement la même que l'identité d'authentification présentée par le
client
Identité d’autorisation 2/2
• Après authentification, le client établit une identité d’autorisation en

utilisant les informations d’authentification échangées avec le serveur
• L’identité est automatiquement dérivée de de celle utilisée par la couche
de sécurité inférieure (assertion implicite)
• P. ex.: si le client s’authentifie avec SASL avec le mécanisme EXTERNAL en utilisant
un certificat X.509, le DN du certificat client est utilisé comme identifiant
d’authentification de l’utilisateur (le DN du certificat devrait être identique au DN
de l’entrée correspondante à l’utilisateur dans l’annuaire LDAP)
• Le client demande une nouvelle identité en se basant sur celle dérivée de
la couche de sécurité inférieure ou une nouvelle identité désirée
(assertion explicite)
• P. ex. en utilisant des règles de correspondance
• Exemple (OpenLDAP) :
authz-regexp
"cn=client jxplorer,ou=telecom,o=ups,l=orsay,st=essonne,c=fr"
dn:cn=clientJXplorer,ou=applications,o=UPS,c=FR
28
13/01/2021
Règles de correspondance
• Règles de correspondance permettent de faire correspondre des

identités d’authentification avec des entrées de l’annuaire LDAP
• Leur réalisation dépend de l’implémentation du serveur LDAP
• Exemple OpenLDAP:
• DN obtenu de SASL est représentée sous la forme :
uid=<username>,cn=<mechanism>,cn=auth
• username: nom d’utilisateur communiqué par SASL
• mechanism: nom du mécanisme utilisé par le client lors de l’authentification
• Utilisation de « authz-regexp » dans le fichier de configuration
• Exemple :
authz-regexp
uid=(.*),cn=digest-md5,cn=auth
ldap:///o=UPS,c=FR??sub?(uid=$1)
Stockage des mots de passe
• LDAP supporte le stockage de mots de passe hachés

• Plusieurs algorithmes de hachage sont supportés:
• {CRYPT} utilise un hachage basé sur DES (algorithme de chiffrement symétrique)
Mode faible
• {MD5} hachage par MD5 puis encodage en base64
• {SHA} hachage par SHA-1 puis encodage en base64
• {SSHA} (Salted SHA) : avec une meilleur gestion du seed
Mode recommandé
• Exemple:
dn: cn=oualha,ou=Personnel,dc=exemple,dc=fr
objectClass: person
cn:Nouha Oualha
userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ...
• Certaines implémentations du serveur LDAP peuvent offrir des extensions

pour gérer les mots de passe p. ex.:
• Contrôler la durée de vie d’un mot de passe
• Contrôler le nombre d’échecs de saisie, verrouillage du mot de passe en
cas d’échecs consécutifs
29
13/01/2021
Conclusions
• LDAP est un système d’annuaire distribué local et global grâce à l’URL

• Nommage DNS utilisé pour les éléments de base de l'annuaire (racine et premières
branches) [RFC 2247]
P. ex. : DN LDAP "DC=CRITICAL-ANGLE,DC=COM"
Nom de domaine "CRITICAL-ANGLE.COM"
• Les problèmes de performance sont résolus par les serveurs primaires et

secondaires et l’utilisation de serveurs de cache
• LDAP permet de mettre en place un référentiel unique d’authentification

et donc de fédérer plusieurs sources et protocoles d’authentification
• p. ex. authentification unifiée dans des environnements Unix/Windows (par
le biais de stockage de mots de passe)
Références
• K. Zeilenga. Lightweight Directory Access Protocol (LDAP): Technical Specification

Road Map. IETF RFC 4510, June 2006
• LDAP: Technical Specification Road Map [RFC 4510]
• LDAP: The Protocol [RFC4511]
• LDAP: Directory Information Models [RFC4512]
• LDAP: Authentication Methods and Security Mechanisms [RFC4513]
• LDAP: String Representation of Distinguished Names [RFC4514]
• LDAP: String Representation of Search Filters [RFC4515]
• LDAP: Uniform Resource Locator [RFC4516]
• LDAP: Syntaxes and Matching Rules [RFC4517]
• LDAP: Internationalized String Preparation [RFC4518]
• LDAP: Schema for User Applications [RFC4519]
30
13/01/2021
2ème partie
Identité fédérée & Authentification unique
Plan
1. Système de gestion d’identités

• Identité
• Modèles de gestion d’identités
2. Protocoles pour la fédération d’identités et l’authentification

unique
• SAML
• OAuth
• OpenID Connect
31
13/01/2021
1. Système de gestion d’identités

L’identité
• L'identité d'un utilisateur (application, service, machine, personne)
• Un ensemble de renseignements personnels qui caractérise l’utilisateur dans
des contextes différents
• Une combinaison de sous-ensembles appelés identités partielles dont
certaines identifient de façon unique l’utilisateur (p. ex. le numéro de
sécurité sociale)
• La combinaison peut changer selon le contexte et la situation
• Un système de gestion d'identités : fournit des outils pour la gestion

de ces identités partielles
• Un ensemble de fonctions p. ex. la gestion, la découverte et l'échange
d'informations
Système de gestion d’identités
• Un système de gestion d'identités est caractérisé par les

éléments suivants:
• Utilisateur : celui qui veut accéder à un service
• Identité : un ensemble d'attributs d'un utilisateur
• Fournisseur d'identité (Identity Provider - IdP) : enregistre es

utilisateurs et délivre une identité associée à un utilisateur
d’une manière sécurisée
• Exemple: basé sur l’annuaire LDAP
• Fournisseur de services (Service Provider - SP) : fournit des

ressources à des utilisateurs après les avoir authentifiés (ou
identifiés) et autorisés à accéder à ces ressources
32
13/01/2021
Modèles de gestion d’identités 1/3

Fournisseur de
services +
• Modèle classique : les identités sont individuellement Fournisseur
prises en charge par chaque SP qui joue également le d’identités
rôle d'un IdP
• Utilisateur crée son identité numérique pour chaque SP Utilisateur
• Coûteux pour les utilisateurs et SPs (gestion des identités
log(n))
Fournisseurs de services
• Modèle centralisé : partage des identités des utilisateurs
• Tous les SPs ont une relation de confiance avec IdP
• IdP est responsable de l'authentification des utilisateurs et
la fourniture d’informations sur les attributs des utilisateurs
aux SPs
• Concept d'authentification unique (SSO : Single Sign-on)
Fournisseur
Utilisateur d’identités

• Modèle d'identités fédérées : répartition de l'authentification des
utilisateurs au près de plusieurs IdPs appartenant à différents domaines
administratifs
• Relations de confiance établis entre les IdPs et les domaines correspondants
pour que les identités émises dans un domaine soient reconnues par les SPs
dans les autres domaines
Fournisseurs de services Fournisseurs de services
Fournisseur Fournisseur
Utilisateur Utilisateur d’identités
d’identités
Domaine administratif 1 Domaine administratif 2
33
13/01/2021

• Modèle centré sur l'utilisateur (user-centric) : l'utilisateur a un contrôle
total sur ses identités numériques
• Les identités d'un utilisateur destinés à plusieurs SPs sont stockés sur un
dispositif physique maintenu par l' utilisateur (p. ex. carte à puce, un
téléphone cellulaire)
• L'utilisateur s'authentifie avec ce dispositif physique qui communique
des renseignements sur l'utilisateur selon le souhait de ce dernier
Fournisseurs
de services
Utilisateur
Service d’authentification “classique”
Utilisateur Fournisseur de services

1
2 8
Ressources
3 protégées
9
10
Domaine
administratif local 4 5
Serveur
d’authentification LDAP
7 6 Login/PW
34
13/01/2021
Service d’auth. pour identité fédérée

Utilisateur 1 Fournisseur de services
2 6
Ressources
5 protégées
7
8
2 5
Serveur
d’authentification
3 4
LDAP
Login/PW
Domaine
administratif local
2. Protocoles pour la fédération d’identités et

l’authentification unique
• L’identité fédérée « est le moyen de relier l'identité électronique et les attributs d'une
personne stockés dans de multiples systèmes distincts de gestion de l'identité »
• Authentification unique (SSO- Single Sign On) est une « méthode permettant à un
utilisateur d'accéder à plusieurs applications informatiques ou sites web sécurisés en ne
procédant qu'à une seule authentification » « dans laquelle le ticket d'authentification
unique d'un utilisateur, ou jeton, est reconnu par plusieurs systèmes informatiques ou
organisations »
• « SSO est lié à l’identité fédérée et il ne serait pas possible sans une sorte de fédération »
(Wikipédia)
• Plusieurs standards SSO ont été créés: CoSign (Weblogin), Pubcookie, Webauth, CAH, CAS,
WebID, BrowserID (Persona), SAML, WS-*, Liberty alliance, SAML 2, Shibboleth, OpenID,
OpenID Connect...
• Aujourd'hui, seuls quelques-uns sont véritablement utilisés

• SAML 2 (basé sur XML)
• OpenID Connect (basé sur OAuth 2.0, JWT)
• CAS (crée par l’université de Yale)
35
13/01/2021
Service d’auth. pour identité fédérée
Redirection pour
Premier s’authentifier
accès
Jeton Jeton
d’accès d’accès
LDAP
Validation du
jeton d’accès/
assertion Portail
Application
Web d’authentification
Jetons d’accès
• SAML (ou l'espace WS*)

• Basé sur XML
• De nombreuses options de cryptage et de signature
• Expressif mais nécessite une stack XML assez avancée
• SWT (Simple Web Token)

• Créé en réaction directe à la création d'une version beaucoup plus simple de
SAML (par Microsoft, Google, Yahoo)
• Possède des options cryptographiques simples, pas assez nombreuses (juste
symétriques)
• JWT (JSON Web Tokens)

• Basé sur JSON (largement supporté)
• Possède des options de signatures symétriques et asymétriques et cryptage
• Possède moins d'options/flexibilité que SAML mais plus que SWT
• JWT est un protocole émergent et de plus de plus adopté
36
13/01/2021
SAML
• SAML : Security Assertion Markup Language

• Standard développé par OASIS (Organization for the Advancement of
Structured Information Standards)
• SAML permet d’associer et de contrôler différentes identités d'un sujet
• Il permet une authentification unique (SSO) des utilisateurs sur le Web
• SAML définit un protocole de sécurité d’échange d’informations
d'identités entre des applications diverses
• Authentification, autorisation et attributs
• Les informations de sécurité, dites assertions, sont représentées sous
format XML
Assertions SAML
• Informations de sécurité relatives à un sujet (p.ex. une personne, une

organisation, ordinateur)
• Authentication assertion: permet d'exprimer des informations

d'authentification basés sur plusieurs technologies p. ex les certificats X.509,
tickets Kerberos et Signature XML
• Attribute Assertion: contient les attributs associés au sujet, telles que le nom,
affiliation, certificat numérique
• Authorization Decision Assertion: indique des actions (formulaires d'accès)

que le sujet a l’autorisation d’exécuter sur certaines ressources
37
13/01/2021
Exemple d’une assertion SAML
Protocoles SAML
• Protocoles SAML sont définies en deux couches:

• Couche supérieure : est composée de schémas XML de messages
• Authentication Request Protocol
• Assertion Query and Request Protocol
• Single Logout Protocol (SLO Protocol)
• …
• Couche inférieure : est composée de spécifications définissant comment
utiliser les protocoles sous-jacents (SOAP, HTTP, etc) pour transporter ces
messages SAML
• SAML SOAP
• HTTP Redirect
• HTTP POST
• …
38
13/01/2021
Exemple: Requête/Réponse SAML
• Requête d’authentification :
<authnRequest>
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_1" Version="2.0"
IssueInstant="2004-12-05T09:21:59Z" AssertionConsumerServiceIndex="1">
<saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
• Réponse d’authentification :
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_2"
InResponseTo="identifier_1" Version="2.0" IssueInstant="2004-12-05T09:22:05Z" Destination="https://sp.example.com/SAML2/SSO/POST">
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_3" Version="2.0" IssueInstant="2004-12-05T09:22:05Z">
…
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
Composants SAML
• SAML est spécifié en cinq composants
Profils
Combinaison d’assertions, protocoles, et bindings pour un cas d’utilisation particulier
Bindings
Mappage des protocoles à des messages standards et des protocoles de communication
Protocoles
Requêtes et réponses pour obtenir des assertions et pour la gestion des identités
Assertions
Authentification, attribut, informations sur les droits
39
13/01/2021
Exemple : Profil Web SSO

Utilisateur Fournisseur de Fournisseur
service d’identité
1. Utilisateur veut accéder à Pas de contexte de

une ressource chez un sécurité avec l’utilisateur,
fournisseur de service j’ai besoin d’acquérir un
HTTP GET 2. SP détermine l’IdP à
contacter (en utilisant le
certificat de l’utilisateur, ou
3. Message par d’autres moyens)
<samlp:AuthnRequest> émis
par le SP à l’IdP
HTTP 302 Redirect
4. Utilisateur présente un certificat x.509 sur TLS à l’IdP

L’IdP authentifie l’utilisateur avec TLS ou un autre mécanisme d’auth.
5. Message <samlp:Response> émis par l’IdP au SP via l’utilisateur sur

TLS
6. En se basant sur la réponse

de l’IdP, le SP retourne le
service (sinon une erreur)
HTTP OK
OAuth
• OAuth est utilisé chez de nombreux fournisseurs de services p. ex. Gmail,

Twitter, Facebook
• REST (Representational State Transfer, architecture orientée ressource)
• OAuth ouvert au domaine de l'entreprise et le Cloud avec cas

d'utilisation spécifiques (OAuth 2.0)
• OAuth 2.0 (RFC 6749) n’est pas compatible avec les versions précédentes
OAuth 1.x
• OAuth permet à un client tiers d’avoir un accès limité à des ressources

pour le compte de l’utilisateur
• Orchestrant une interaction d'approbation avec le propriétaire via un serveur
d’autorisation
• Ressources hébergées par un serveur de ressources
40
13/01/2021
Architecture d’OAuth
• Quatre rôles dans l’architecture:

• Propriétaire des ressources: entité capable de
fournir l'accès à une ressource ou un service
protégé
• Serveur des ressources: serveur hébergeant la

ressource qui est capable d'accepter l'accès à
cette ressource
• Client: application ou un service qui demande

d’accéder aux ressources protégées en faveur du
propriétaire et avec sa permission
• Serveur d’autorisation: serveur qui permet au

client d'accéder à la ressource en fournissant un
jeton d'accès après l’authentification du client et
obtention l’approbation du propriétaire
Opérations d’OAuth
Authorisation Request Propriétaire de la
Authorisation Grant ressource
Authorisation Grant Serveur

Client
Access Token d’autorisation
Access Token Serveur des

Protected Ressource ressources
• Accord d'autorisation : obtenu en utilisant un serveur d'autorisation en tant

qu'intermédiaire entre le client et le propriétaire de la ressource
• Jeton d'accès : un champ spécifique avec durée de vie et d'autres attributs d'accès
• Jeton d'accès est de courte durée, lorsqu’il expire, le client envoie une requête au serveur
d'autorisation pour rafraichir le jeton (Refresh Token)
• Informations d'authentification (ou d'identification) du client peuvent être utilisées lorsque la
portée de l'autorisation est limitée à des ressources contrôlées par le client
• OAuth spécifie l'utilisation de HTTP, les redirections HTTP, et TLS pour la sécurité
41
13/01/2021
Exemple : Google délégation d’autorisation

Go to authorization server
Redirect URI: toto.com/callback
Response type: code
Scope: profile contacts
contacts.google.com
Request
Request profile consent
and contacts with
access token
accounts.google.com
toto.com/callback Back to redirect URI autorisez-vous toto.com à
With authorization code accéder à votre profile et
contacts ?
Non Oui
Exemple : Facebook Connect

• Facebook Connect est basé sur OAuth 2.0
Navigateur Application Facebook

utilisateur Web API
HTTP GET HTTP REDIRECT
Bouton “login Facebook” Redirigé vers URL de
dialogue Facebook
HTTP REDIRECT
Utilisateur accepte, il est redirigé avec l’accord d’autorisation
HTTP GET HTTP GET
Avec l’accord d’autorisation /oauth/authorize
Jeton d’accès
HTTP GET ?access_token

Réponse API
42
13/01/2021
Flux OAuth 2.0
• Flux serveur Web

• Flux Javascript
• Flux application mobile
• Flux objets & TV
OpenID Connect
• OpenID Connect est une couche d'identification basée sur OAuth 2.0
• Scope: openid profile
OpenID Connect
OAuth 2.0
HTTP
• OpenID Connect permet à l’application “Client” d’authentifier un utilisateur
• OpenID Connect est un standard géré par la fondation OpenID
• OpenID Connect introduit deux jetons

• ID token pour l’identification
• userInfo pour plus d'informations sur l'utilisateur
• Les jetons d’OpenID Connect sont basés sur JWT (JSON Web Token)
43
13/01/2021
OpenID Connect : Flux de messages
• La spécification OpenID Connect définit trois rôles:

• Utilisateur
• Application client
• Fournisseur OpenID ayant trois points:
• Point d'autorisation gère l'authentification et l'autorisation d'un utilisateur
• Point de jetons est utilisé pour obtenir des jetons
• Point userInfo est utilisé pour récupérer les attributs de l'utilisateur
• La spécification OpenID Connect définit trois flux d'autorisation
• Flux de code d'autorisation (ou flux de base) est un flux OAuth 2.0 dans
lequel un code d'autorisation est renvoyé par le point d'autorisation et tous
les jetons sont renvoyés par le point de jetons
• Flux implicite est un flux OAuth 2.0 dans lequel tous les jetons sont renvoyés
par le terminal d'autorisation
• Flux hybride est un flux OAuth 2.0 dans lequel un code d'autorisation est
renvoyé par le point d'autorisation, certains jetons sont renvoyés par le point
d'autorisation et d'autres par le point de jetons
OpenID Connect : Flux de code d’autorisation
Fournisseur OpenID
Application Point Point de Point de
Utilisateur client d’autorisation jetons userInfo
Requête d’accès
Requête d’authentification
OpenID
Authentification de l’utilisateur
Réponse d’authentification OpenID + code d’autorisation
Code d’autorisation
Jeton d’ID + jeton d’accès
Jeton d’accès
Information utilisateur
44
13/01/2021
OpenID Connect : Flux implicite
Fournisseur OpenID
Application Point Point de Point de
Utilisateur client d’autorisation jetons userInfo
Requête d’accès
Requête d’authentification
OpenID
Authentification de l’utilisateur
Réponse d’authentification OpenID + Jeton d’ID + jeton

d’accès
Jeton d’accès
Information utilisateur
Conclusions
• SAML est un protocole complexe (utilisé surtout pour SaaS-Software

as a service)
• Bonne sécurité, bien établi
• Construit sur un protocole avec une couche XML, coût est moins
important si les données transportées sont plus larges
• SAML est de plus en plus remplacé par OAuth et OpenID Connect

• Adoption facile d’OAuth avec les nouvelles technologies, mobile-
ready
45
13/01/2021
Références
• Identity Management System Limitation and Requirements and

Prospective AAIs. SecFuNet Project Delivrable D3.1, September 09, 2012
• David Chadwick. Federated identity management. Foundations of

Security Analysis and Design V, pages 96–120, 2009
• Assertions and Protocols for the SAML 2.0. OASIS
• D. Hardt. The OAuth 2.0 Authorization Framework. IETF RFC 6749,

October 2012
• OpenID Connect: https://openid.net/connect/
Séances
• Cours (8h)
• Mercredi 13/01/2020 : 8h30 --> 12h30 (4h)
13h30 --> 17h30 (4h)
• Skype Business
• Travaux Pratiques (4h)

• Mercredi 20/01/2020 : 8h30 --> 12h30 (4h) – Gr1
13h30 --> 17h30 (4h) – Gr2
• En présentiel en salle S215
46

CoursIUTOrsayv 2021 Etudiants

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CoursIUTOrsayv 2021 Etudiants

Transféré par

Droits d'auteur :

Formats disponibles

13/01/2021

Cours Sécurité Réseaux

Nouha OUALHA, oualha@gmail.com

• Travaux Pratiques (4h)

• En présentiel en salle S215

Service d'annuaire LDAP - N. Oualha 2

Service d'annuaire LDAP - N. Oualha 4

Service d'annuaire LDAP - N. Oualha 5

• Développements menés par l’Internet Engineering Task Force (IETF)

Service d'annuaire LDAP - N. Oualha 6

Exemple : Authentification par LDAP

Service d'annuaire LDAP - N. Oualha 7

Exemple : Gestion de données

Service d'annuaire LDAP - N. Oualha 8

• Modèle de données décrivant les informations contenues dans

Service d'annuaire LDAP - N. Oualha 9

DUA (Directory User DSA (Directory

Service d'annuaire LDAP - N. Oualha 10

• Exemple de structure tableaux

• Exemple de structure hiérarchique (arbre inversé)

cn=Jean Dupont cn=Michel Jean

Service d'annuaire LDAP - N. Oualha 11

• DIB: Directory Information Base

• DIB contient deux types d'informations:

Service d'annuaire LDAP - N. Oualha 12

Service d'annuaire LDAP - N. Oualha 13

• L’identificateur d’objet OID (Object Identifier) est un identifiant unique

Service d'annuaire LDAP - N. Oualha 14

• Attribut : une description d'attribut (un type avec zéro ou plusieurs

Service d'annuaire LDAP - N. Oualha 15

Exemple 1/2 : Attribut

attributetype ( 2.5.4.5 NAME 'serialNumber'

Syntaxe décrivant le type de données

Service d'annuaire LDAP - N. Oualha 16

Exemple 2/2 : Attribut

attributetype ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainComponent' )

Si un type attribut accepte uniquement une

Service d'annuaire LDAP - N. Oualha 17

• Classe d’objets: famille d’objets qui partagent certaines

Service d'annuaire LDAP - N. Oualha 18

Exemple : Classe d’objets 1/3

Liste des attributs facultatifs (MAY)

Service d'annuaire LDAP - N. Oualha 19

Héritage de classes d’objets

country person organization dcObject

Service d'annuaire LDAP - N. Oualha 20

Exemple : Classe d’objets 2/3

objectclass ( 2.5.6.7 NAME 'organizationalPerson'

Service d'annuaire LDAP - N. Oualha 21

Exemple : Classe d’objets 3/3

objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'

Service d'annuaire LDAP - N. Oualha 22

Schéma Exemple d’un schéma : “core.schema”

• p. ex. le logiciel OpenLDAP utilise un attributetype ( 2.5.4.17 NAME 'postalCode'

Service d'annuaire LDAP - N. Oualha 23

Serveurs LDAP distribués

• L’accès au DIT est fourni conjointement par un ou plusieurs serveurs

Service d'annuaire LDAP - N. Oualha 24

Service d'annuaire LDAP - N. Oualha 25

• LDIF : LDAP Interchange Format

Service d'annuaire LDAP - N. Oualha 26

• Donnez les attributs obligatoires et optionnels de la classe d’objet

Service d'annuaire LDAP - N. Oualha 27