CISSP · Réussir du premier coup
Domaine 5, deuxième partie : l'identité fédérée (SAML, OAuth, OIDC) et tous les modèles d'autorisation avec leurs critères de choix.
La fédération d'identité étend le SSO (chapitre 13) au-delà d'une seule organisation : un utilisateur s'authentifie une fois auprès de son fournisseur d'identité et accède à des services tiers qui font confiance à ce fournisseur. Trois rôles :
| Rôle | Fonction |
|---|---|
| IdP (Identity Provider) | Authentifie l'utilisateur et émet une assertion attestant de son identité |
| SP / RP (Service Provider / Relying Party) | Le service consommé ; il fait confiance à l'assertion de l'IdP au lieu d'authentifier lui-même |
| Trust relationship | Le lien de confiance préétabli (métadonnées, certificats) entre IdP et SP |
Modèles de déploiement : on-premise (IdP interne, ex. AD FS), cloud (IDaaS — Identity as a Service, ex. Okta, Entra ID) et hybride. Bénéfice : moins de mots de passe, révocation centralisée. Risque : l'IdP devient un point de défaillance et une cible de choix — sa compromission ouvre tous les services fédérés (à protéger par MFA, chapitre 13).
La distinction entre ces trois protocoles est l'un des pièges majeurs du domaine 5 — retenez d'abord ce que chacun fait :
| Protocole | Fait quoi | Format | Terrain |
|---|---|---|---|
| SAML 2.0 | Authentification + autorisation (fédération, SSO) | XML (assertions) | SSO web d'entreprise, B2B |
| OAuth 2.0 | Autorisation déléguée — accès à des ressources | Jetons (access token) | « Se connecter avec… », API, apps mobiles |
| OIDC | Authentification — couche au-dessus d'OAuth 2.0 | id_token (JWT) | Authentification moderne web/mobile |
L'utilisateur demande un service (SP) → le SP le redirige vers l'IdP → l'IdP l'authentifie → l'IdP renvoie une assertion SAML signée (identité + attributs) → le SP la vérifie et accorde l'accès. La signature XML garantit l'intégrité et l'authenticité de l'assertion.
OAuth 2.0 permet à une application d'accéder à des ressources au nom d'un utilisateur, sans connaître son mot de passe. Ses rôles : resource owner (l'utilisateur), client (l'application), authorization server (émet les jetons), resource server (héberge les données). Il repose sur des grants (authorization code, client credentials…) et des tokens (access token, refresh token). Point critique : OAuth seul n'est pas de l'authentification — l'utiliser pour « prouver qui est l'utilisateur » est une erreur de conception classique.
OpenID Connect ajoute à OAuth 2.0 une couche d'identité : il émet un id_token (un JWT signé décrivant l'utilisateur) qui, lui, authentifie. C'est ce qui alimente les boutons « Se connecter avec Google ».
« SAML c'est le XML de l'entreprise ; OAuth donne les clés (autorisation) ; OIDC dit qui tu es (authentification). » Réflexe : « autorisation/accès à une API » → OAuth ; « authentification/qui es-tu » → OIDC (ou SAML si c'est du web XML d'entreprise).
| Modèle | Qui décide | Fondé sur | Usage type |
|---|---|---|---|
| DAC | Le propriétaire de l'objet | ACL, à la discrétion du propriétaire | Systèmes de fichiers (Windows, Unix) |
| MAC | Le système (politique centrale) | Labels de classification + need-to-know (treillis, chapitre 6) | Militaire, environnements très sensibles |
| RBAC | L'organisation, par rôle | Fonction/poste de l'utilisateur | Entreprise (le plus courant) |
| Rule-based | Des règles globales | Conditions identiques pour tous | Pare-feu, filtrage horaire |
| ABAC | Des attributs et politiques | Attributs sujet + objet + environnement | Le plus fin et dynamique (XACML) |
| Risk-based / adaptive | Le contexte évalué en temps réel | Risque, comportement, appareil, localisation | Zero trust, authentification adaptative |
« DAC = le Détenteur décide · MAC = la Machine impose · RBAC = le Rôle · ABAC = les Attributs. » Réflexe d'énoncé : « le propriétaire du fichier accorde l'accès » → DAC ; « labels de classification » → MAC ; « selon le poste » → RBAC ; « selon le contexte/attributs » → ABAC.
| Composant | Rôle |
|---|---|
| PAP (Policy Administration Point) | Là où les politiques sont écrites et gérées |
| PDP (Policy Decision Point) | Là où la décision d'accès est calculée (permit/deny) |
| PEP (Policy Enforcement Point) | Là où la décision est appliquée (la porte qui s'ouvre ou non) |
| PIP (Policy Information Point) | Là où le PDP puise les données (attributs, contexte) |
Le flux : le PEP intercepte la demande → interroge le PDP → qui évalue les politiques (du PAP) en récupérant les attributs (au PIP) → renvoie permit ou deny → le PEP exécute. Deux principes transverses : l'implicit deny (tout ce qui n'est pas explicitement autorisé est refusé) et la constrained interface (l'utilisateur ne voit/n'invoque que ce que ses droits permettent — menus grisés, commandes masquées, chapitre 6).
La matrice de contrôle d'accès croise sujets (lignes) et objets (colonnes), chaque cellule listant les droits. On la découpe de deux façons — piège récurrent :
| Découpage | Contenu | Associé à |
|---|---|---|
| Ligne (par sujet) | Ce qu'un sujet peut faire sur tous les objets | Capability table — liée au sujet (ex. ticket Kerberos) |
| Colonne (par objet) | Qui peut agir sur un objet donné | ACL — liée à l'objet (ex. permissions d'un fichier) |
« La ligne suit le sujet (Capability), la colonne garde l'objet (ACL). » Capability = « voici ce que je peux faire » (attaché au sujet) ; ACL = « voici qui peut me toucher » (attaché à l'objet). Question fréquente sur le sens de lecture de la matrice.
Enfin, le contrôle peut être content-dependent (la décision dépend de la donnée demandée — masquer une colonne « salaire ») ou context-dependent (elle dépend du contexte — heure, séquence, localisation ; le firewall stateful en est un exemple).
Awa unifie les identités des deux entités fusionnées via un IDaaS : l'ancien annuaire de Berlin et l'AD du siège se fédèrent, l'IdaaS devient l'IdP unique, protégé par MFA. Les applications SaaS RH et finance se branchent en SAML (web d'entreprise, XML) ; la nouvelle app mobile client s'authentifie en OIDC, et son accès aux API de paiement passe par des jetons OAuth — Awa reprend un développeur qui voulait « authentifier avec OAuth seul », en imposant OIDC par-dessus. Côté autorisation, elle remplace le patchwork de droits individuels par du RBAC aligné sur les fonctions — un changement de poste réattribue les droits en bloc, fini le privilege creep. Pour les données de paiement les plus sensibles, elle ajoute une couche ABAC : approbation possible seulement pour un rôle donné, depuis un appareil géré, aux heures ouvrées, sous un certain montant. La décision est centralisée dans un PDP, appliquée par les PEP devant chaque service, alimentée par un PIP — le tout se terminant par un implicit deny.
Conditions réelles : 30 minutes, une seule passe, réponses notées avant de consulter le corrigé.
In a federated identity system, what is the role of the identity provider (IdP)?
L'IdP authentifie et émet l'assertion d'identité que les services consommeront. Héberger la ressource (A) est le rôle du SP.
What does a service provider (relying party) do in a federation?
Le SP/RP fait confiance à l'assertion de l'IdP au lieu d'authentifier lui-même — c'est le principe même de la fédération. A décrit l'authentification directe qu'on cherche à éviter.
Which protocol is XML-based and commonly used for enterprise web single sign-on?
SAML 2.0 : XML, fédération et SSO web d'entreprise. OAuth (A) est de l'autorisation, RADIUS/Kerberos (C, D) sont d'autres mécanismes.
What is the PRIMARY purpose of OAuth 2.0?
OAuth 2.0 délègue l'autorisation : une app accède aux ressources au nom de l'utilisateur, sans son mot de passe. Ce n'est pas de l'authentification (A) — la confusion à ne jamais faire.
A developer uses OAuth 2.0 alone to verify who a user is. Why is this a design error?
OAuth est un cadre d'autorisation : l'utiliser seul pour « savoir qui est l'utilisateur » est un contresens — il faut OIDC par-dessus. B, C, D sont factuellement faux.
What does OpenID Connect (OIDC) add to OAuth 2.0?
OIDC ajoute la couche d'authentification et émet un id_token (JWT) décrivant l'utilisateur. Les autres options n'ont rien à voir avec OIDC.
A mobile app offers "Sign in with Google." Which technology authenticates the user?
« Se connecter avec Google » sur mobile = OIDC (authentification au-dessus d'OAuth). SAML (A) serait du web d'entreprise XML — pas le cas ici.
What is a PRIMARY security risk of federated identity?
La fédération concentre le risque sur l'IdP : le compromettre ouvre tous les services fédérés — d'où l'exigence de MFA. A décrit l'inverse du bénéfice (moins de mots de passe).
In which access control model does the owner of a resource decide who may access it?
Le propriétaire qui décide = DAC (ACL à sa discrétion). MAC (A) est imposé par le système ; « le propriétaire du fichier » pointe toujours vers DAC.
Which access control model uses classification labels and need-to-know, enforced by the system rather than the owner?
Labels de classification + need-to-know imposés par le système = MAC. Ni le propriétaire ni l'utilisateur ne peuvent contourner les étiquettes.
A company assigns permissions based on employees' job functions, so a role change reassigns rights automatically. Which model is this?
Droits par fonction, réattribués au changement de poste = RBAC — ce qui combat le privilege creep. Ne pas confondre avec le rule-based (règles globales).
Which access control model evaluates attributes of the subject, object, and environment for the most granular, dynamic decisions?
ABAC combine attributs du sujet, de l'objet et de l'environnement : le modèle le plus fin et dynamique (XACML). Les autres sont moins expressifs.
A firewall applies the same rule set to all traffic regardless of user identity. Which access control type is this?
Des règles identiques pour tous, indépendantes de l'identité = rule-based (le pare-feu en est l'exemple type). Le RBAC (A) dépend du rôle de chacun.
Access tightens automatically when a user logs in from an unusual country on an unknown device. Which model is this?
L'accès qui se durcit selon le contexte (pays, appareil, comportement) = risk-based/adaptive — le socle du zero trust. Les autres modèles sont statiques.
Which is a KEY weakness of discretionary access control?
En DAC, le propriétaire peut propager les droits : la donnée peut se répandre sans contrôle central. C'est la faiblesse structurelle du modèle, absente du MAC.
In an XACML-based system, which component actually enforces the access decision?
Le PEP applique la décision — c'est la « porte ». Le PDP décide (B), le PAP écrit les politiques (A), le PIP fournit les données (D).
Which component evaluates policies and returns a permit or deny decision?
Le PDP calcule la décision (permit/deny) à partir des politiques et des attributs. C'est le « juge » de la chaîne.
Where does the PDP retrieve the attributes and contextual data it needs for a decision?
Le PDP puise attributs et contexte au PIP (Policy Information Point). Le PEP (A) ne fait qu'appliquer ; il n'est pas la source des données.
Reading an access control matrix by ROW (per subject) produces what structure?
Par ligne (par sujet) = capability table : « ce que je peux faire ». Par colonne (par objet) donnerait une ACL — la distinction testée.
Reading an access control matrix by COLUMN (per object) produces what structure?
Par colonne (par objet) = ACL : « qui peut toucher cet objet ». La capability (A) se lit par ligne, côté sujet.
A Kerberos ticket that lists what a subject may access is an example of what?
Un ticket qui liste ce que le sujet peut atteindre est une capability attachée au sujet. Une ACL (A) serait attachée à l'objet.
A control that hides a "salary" column from users not authorized to see it is which type?
Décision fondée sur la donnée demandée (la colonne salaire) = content-dependent. Le context-dependent (A) dépendrait de l'heure ou de la séquence, pas du contenu.
Which principle dictates that any access not explicitly permitted is denied?
Implicit deny : tout ce qui n'est pas explicitement autorisé est refusé (deny by default). L'implicit allow (A) et le fail-open (D) ouvriraient l'accès par défaut.
A constrained interface achieves security by doing what?
La constrained interface ne montre que ce que les droits permettent (menus grisés, commandes masquées) : l'utilisateur ne peut même pas tenter l'interdit. Les autres options décrivent d'autres contrôles.
Which statement correctly distinguishes RBAC from rule-based access control?
RBAC = droits par rôle/fonction ; rule-based = règles globales appliquées à tous. D inverse les deux définitions — le piège de l'acronyme partagé.
≥ 20/25 : passez au chapitre 15. Entre 15 et 19 : récitez la distinction SAML/OAuth/OIDC et la table des modèles d'autorisation. < 15 : relisez le chapitre ; ces deux tableaux sont parmi les plus rentables de l'examen.