IAM

Introduction
Architecture du SI

Application 1 Application 2 DB 2

Annuaire entreprise

Application 3

Application 4 Annuaire 4
Architecture du SI

Application 1

Application 2
Annuaire entreprise IAM

Application 3

Application 4
IAM = Qui à accès à quoi ?
Pourquoi une gestion centralisée des identités et des accès ?

- Simplification du processus d’inscription

- Eviter les répertoires multiples
- Permettre le SSO
- Respecter les réglementations, suivre l’évolution
- Evolution des personnes dans l’entreprise
- Contrôler le cycle de vie des identités
Avantages du SSO
- Unifier les politiques de mots de passe

- Sécurité renforcée : un seul identifiant à retenir

- Gestion des accès simplifié et centralisé

- Réduction des coûts informatiques avec un seul compte à maintenir

- Meilleure expérience utilisateur, moins de perte de temps

- Réduire le recours au Help Desk

Risques du SSO
- Vol d’un compte → vol de tous ses accès et de toutes les données accessible
(exemple : piratage Sécurité Sociale)
- SPOF

- S’assurer de la confiance des applications connectés

IAM - Fonctionnalités
● Gestion des identités : unifier la gestion des identités dans les différents
référentiels
● (De)Provisionning des utilisateurs : gérer le cycle de vie de la création à la
suppression
● Authentification : mécanisme pour déterminer qu’une personne est bien la
propriétaire d’une identité
● SSO
● Authorization : centraliser la gestion des accès aux différentes applications
Cycle de vie d’une identité

Création > assignation de rôles > modification > désactivation > réactivation >
changement de rôles > suppression de rôles > changement de mots de passe >
changement d’authentification > désactivation > suppression
Authentification
3 catégories différentes d’authentification

- Ce que je sais : mot de passe, PIN, OTP (One Time Password), question de
sécurité, …
- Ce que je possède : un smartphone, générateur de token, un certificat …
- Ce que je suis : empreinte digitale, reconnaissance faciale, authentification par
la voix, …
Authentification
3 types de méthode d’authentification

- SFA : Authentification à facteur simple

- 2FA : Authentification à deux facteurs

- MFA : Authentification multifacteur

Équilibre entre contraintes de sécurité, expérience utilisateur et le budget

Autorisation
X PEUT FAIRE Y SUR LA RESSOURCE Z
Autorisation
● RBAC = Contrôle d’accès basé sur des rôles
● Un rôle donne accès à plusieurs applications potentiellement
● Permet de suivre le changement de postes des employés
● Les rôles doivent suivre l’évolution de l’entreprise, risque de complexification
● Inconvénient = pas de cas particulier
● Attention aux rôles non compatibles entre eux
Autorisation
ABAC = Contrôle d’accès basé sur les attributs

En fonction des attributs de l’utilisateur, de l’environnement …

Plus grande flexibilité que RBAC, plus précis, plus complexe à mettre en place

Dans tous les cas, appliquez le principe du moindre privilège

PAM
Gestion des accès privilégiés

Niveaux supplémentaires d’authentification pour les utilisateurs privilégiés

Un audit fréquent des activités des utilisateurs privilégiés

Le stockage des identifiants des utilisateurs privilégiés dans des coffre-forts de mots
de passe

C’est une solution logicielle à part de l’IAM

Question
Accès à une salle à l’aide d’un badge :

- Authentification ?
- Autorisation ?
L’importance de l’authentification
Piratage des mails de députés

Les attaques viennent aussi (et surtout) de l’intérieur

La fraude au président

Pourquoi ? on fait confiance

aux connaissances et à la
hiérarchie
Terminologie
IdP
● IdP = Identity Provider

● Responsable du stockage et de la gestion des identités numériques

● Responsable de l’authentification des utilisateurs

● Fournit aux applications les données utilisateurs nécessaires

● Permet de gérer les privilèges

SP
● SP = Service Provider

● Généralement une application web

● Il offre des services ou ressources aux utilisateurs après leur authentification

par un IdP
JWT
● JWT - JSON Web Token

● Norme ouverte

● 3 parties sous forme de JSON : Header, Payload, Signature

● 2 manière de signer : HMAC SHA256 (clé secrète) ou RSA (clé public / clé privé)

● Le JWT est encodé en base64UrlEncode : https://jwt.io/

JWT
Kerberos
Présentation de Kerberos
Créer par le MIT pour résoudre le problème de SSO

Système complexe mais transparent pour l’utilisateur

On se connecte à sa session Windows et on accède aux applications sans avoir à

s’authentifier de nouveau

Les mots de passe ne circulent jamais, échange de clés privées uniquement

Les acteurs
● Le client : initie la demande lors de la connection d’un utilisateur (navigateur
par exemple)

● Serveur hôte : serveur hébergeant une application

● Serveur d’authentification (AS) : effectue l’authentification d’un user et lui
donne un TGT (Ticket Granting Ticket)
● Serveur d’émission de tickets (TGS) : émet des tickets de service à partir d’un
TGT
● Centre de distribution de clés (KDC) : AS + TGS
Le flux
En pratique
Dans un environnement Windows en entreprise, lorsqu’un utilisateur ouvre sa
session Windows, login et mot de passe sont vérifiés par un Contrôleur de Domaine
(DC), et un ticket Kerberos est généré

A partir de là, ce ticket pourra lui servir pour accéder aux ressources autorisées sans
avoir à s’authentifier de nouveau

Utilisation possible sur Linux, mais plus largement utilisé sous Windows
SAML
SAML 2.0
Security Assertion Markup Language

Norme ouverte / inter opérabilité des systèmes

SSO inter-domaine

Utilise XML pour présenter les données de l’utilisateur

Date de 2005 (en version 2.0)

SAML 2.0
● Le fournisseur d’identité va créer un document XML avec les attributs
utilisateurs et le signer numériquement, c’est une assertion SAML
● Le service (ou Partie de Confiance, Relying Party, RP) reçoit l’assertion, vérifie la
signature, et récupère les données utilisateurs
● Le service n’a pas à stocker les attributs utilisateurs demandés, ces attributs
sont constamment à jour
SAML 2.0 - exemple de response
SAML 2.0
SAML 2.0
L’assertion peut être signée, encrypté, ou les deux à l’aide de certificat

Le flux d'authentification SAML est asynchrone. Le fournisseur de services ne

conserve aucun état des demandes d’authentification générées. Lorsque le SP reçoit
une réponse d'un IdP, la réponse doit contenir toutes les informations nécessaires.
SAML 2.0
Le SP nécessite au moins les éléments suivants :
● Certificat : le SP doit obtenir le certificat public de l'IdP pour valider la
signature. Le certificat est stocké côté SP et utilisé chaque fois qu'une réponse
SAML arrive.
● ACS Endpoint – Assertion Consumer Service URL – souvent appelé simplement
URL de connexion SP. Il s'agit du point de terminaison fourni par le SP où les
réponses SAML sont publiées. Le SP doit fournir ces informations à l’IdP.
● URL de connexion IdP : il s'agit du point de terminaison du côté IdP où les
requêtes SAML sont publiées. Le SP doit obtenir ces informations auprès de
l’IdP.
OAuth 2.0
OAuth 2.0
● OAuth (Open Authorization) est un protocole d'autorisation et non

d’authentification

● Conçu pour accorder l’accès à des ressources : API, données utilisateurs …

OAuth 2.0 - Les rôles
Propriétaire des ressources (Resource owner)

Client : système qui souhaite accéder aux ressources protégées

Serveur d’autorisation (Authorization server) : reçoit les demandes de jetons d’accès

du client, et qui les délivre après authentification et consentement du propriétaire

Serveur de ressources (Resource server) : un serveur qui protège les ressources et les
délivre après validation d’un jeton d’accès
OAuth 2.0 - Les rôles
OAuth 2.0
Le client doit être enregistré par dans le serveur d'autorisation

Il faut :

- l’identifiant du client
- mot de passe ou paire de clés
- URL de redirection
OAuth 2.0
2 types de token :

- Access token : token a durée de vie limitée avec un portée limitée, consommé
par le client
- Refresh token : token à durée de vie beaucoup plus élevé, permet d’obtenir un
access token lorsque celui-ci a expiré, sans l’intervention du propriétaire de la
ressource. Ils sont plus complexes que les access token. Un refresh token peut
être révoqué. Permet de réduire le nombre de demande d’autorisation
OAuth 2.0 - Type de clients
Clients confidentiels :

- Ils sont capables de maintenir la confidentialité de leurs identifiants (client ID) et

de leur secrets (client secret) afin de s’authentifier face à un IdP

- En général, les applications back-end non exposés aux utilisateurs finaux

OAuth 2.0 - Type de clients
Clients publics:

- Ils ne sont pas capables de maintenir la confidentialité de leurs identifiants

(client ID) et de leur secrets (client secret) afin de s’authentifier face à un IdP

- Par exemple, les applications Javascript côté client, applications mobiles

s’exécutant sur les appareils
OAuth 2.0 - 4 scénarios d’autorisation

● Authorization code grant

● Implicit grant

● Resource owner password credentials grant

● Client credentials grant

OAuth 2.0 - Authorization Code Grant
Pour les clients confidentiels

Côté serveur d’autorisation, 2 endpoints sont nécessaires:

- Authorization endpoint : pour obtenir un code d’autorisation après

authentification
- Tokens endpoint : pour obtenir un access token
OAuth 2.0 - Authorization Code Grant
OAuth 2.0 - Implicit Grant
Pour les clients publics, qui ne peuvent pas s’authentifier de manière fiable
OAuth 2.0 - Resource Owner Passwords
Credentials Grant
Méthode à envisager si et seulement si le serveur d’autorisation et le client sont
issus d’une même entité.

Il doit y avoir une relation de confiance absolue entre ces deux acteurs car le
propriétaire de la ressource doit fournir ses identifiants au client.
OAuth 2.0 - Resource Owner Passwords
Credentials Grant
OAuth 2.0 - Client Credentials Grant
Implication du client et du serveur d’autorisation uniquement, dans le cadre d’API
par exemple
OpenID Connect
OpenID Connect
● OIDC est un protocole d’authentification

● Il se base sur OAuth 2.0 (dans la mécanique, pas dans la fonctionnalité)

● Il utilise des tokens JWT

● Il intègre le consentement des utilisateurs

OpenID Connect
3 types de tokens:

- jeton d’identification, au format JWT, contenant les informations de l'utilisateur

- Access Token

- Refresh Token
OpenId Connect -
Authorization code
flow
Le flux de code d’autorisation offre une
sécurité optimale, car :

- le secret de l’application, résidant sur

le serveur, est protégé,

- l’application cliente peut être

authentifiée, tout comme l’utilisateur
final,

- la signature du jeton lie de façon

indissoluble : l’identité de l’utilisateur
final, l’identité de l’application, la portée
(scope) de l’autorisation.
OpenId Connect -
Implicit flow
Pour des clients publics, qui ne peuvent
être identifé
OpenId Connect -
Implicit flow
Pour des clients publics, qui ne peuvent
être identifé
OpenId Connect -
Implicit flow
Pour des clients publics, qui ne peuvent
être identifé
OpenId Connect -
Hybrid flow
OpenId Connect - Hybrid et implicit flow
Les flux Implicite et Hybride sont implémentés par OAuth mais leur usage est
découragé car ils ne présentent pas les avantages de sécurité attachés à OpenID
Connect :

- ils exposent les jetons au navigateur de l’utilisateur final, ce qui rend possible une
exploitation par un malware,

- ils ne permettent pas d’authentifier l’application cliente.