📖 Report📚 Glossary🗺️ Concepts💡 Examples🃏 Flashcards✅ Quiz🎯 Tricks
Chapter 96 · Tricks

Identity and Access Management — Exam Tricks

Four high-yield patterns: the OAuth vs. OpenID Connect authentication trap, SAML mobile failure, LDAP container vs. leaf object identification, and the three identity proofing stages mapped to scenario keywords.

Trick 1 OAuth vs. OpenID Connect — Authorization vs. Authentication

The single most common IAM trap on the exam: a scenario requires knowing who the user is and offers both OAuth and OpenID Connect as answer choices. Picking OAuth is wrong every time the scenario involves identity.

  • OAuth 2.0 → Authorization only: grants an application permission to access resources on behalf of the user. Does not tell the application WHO the user is.
  • OpenID Connect → Authentication + Authorization: built on top of OAuth; adds an ID token (JSON Web Token) confirming the user's identity. Tells the application who the user is AND grants resource access.

Exam trigger phrases and their answer:

  • “Application needs to know who the user is” → OpenID Connect
  • “Log in with Google / Facebook” (identity federation) → OpenID Connect
  • “Grant a third-party app access to my calendar without sharing my password” → OAuth 2.0
  • “Mobile SSO with identity verification” → OpenID Connect (not SAML)

Memory hook: OAuth = O for Operations (what the app can DO). OpenID Connect = ID is in the name (who you ARE).

Rule: WHO = OpenID Connect. WHAT (resource access) = OAuth. If the scenario says “identity” or “who the user is,” OAuth alone is wrong.
Trick 2 SAML Mobile Failure — Browser Redirects Don't Work in Native Apps

The exam will present a SAML implementation scenario and add the word “mobile” or “native app” somewhere. SAML immediately becomes the wrong answer.

Why SAML fails on mobile:

  • SAML exchanges XML assertion documents via browser HTTP redirects (POST/redirect bindings)
  • Native mobile apps are not browsers — they do not have a URL bar, cannot process HTTP redirect chains the same way, and cannot present SAML assertion POSTs to service providers
  • SAML was designed in 2002 when mobile apps did not exist — it was built exclusively for browser-based web SSO

What to choose instead:

  • Mobile authentication → OpenID Connect (uses JSON tokens over standard OAuth flows that native apps can handle natively)
  • Mobile authorization → OAuth 2.0

The only SAML question you say yes to: “An enterprise deploys SSO for web-based applications using a standards-based XML assertion protocol.” Web + XML + assertions = SAML. Everything else involving mobile = OpenID Connect.

Rule: SAML = web browsers only. Mobile app = OpenID Connect. If you see “mobile” and “SAML” in the same question, SAML is the wrong answer.
Trick 3 LDAP Directory Objects — Container vs. Leaf, CN vs. DN

The exam presents an LDAP scenario and asks either what type of object something is, or what identifier uniquely locates an object globally. Two rules cover all variations:

Rule 1: Container vs. Leaf classification

  • Container objects (hold other things): Country, Organization, Organizational Unit (OU). If you can put something inside it, it is a container.
  • Leaf objects (represent actual entities): Users, computers, printers, service accounts. If it IS something (a person, a device), it is a leaf. Leaves cannot contain other objects.

Rule 2: CN vs. DN — local vs. globally unique

  • Common Name (CN): identifies an object within its immediate parent container only. Not globally unique — CN=John Smith can appear in multiple OUs.
  • Distinguished Name (DN): full path from leaf to root. Globally unique. Format: CN=John Smith,OU=Sales,O=Acme,C=US. If a question asks how to uniquely identify a specific user in the entire directory, the answer is DN.

Port reminder: LDAP = 389. LDAPS (over TLS) = 636. These port numbers appear on the exam.

Rule: Can you put things inside it? Container (Country/Org/OU). Does it represent an entity? Leaf (user/computer/printer). Unique in entire directory? DN. Unique only within parent? CN.
Trick 4 Identity Proofing Stages — Map the Scenario Keyword Instantly

The exam describes an identity proofing step and asks which stage it represents. The mapping is determined by one question: what action is being performed?

  • Collecting information to identify the person (name, DOB, employee ID, SSN) → Resolution
  • Checking that the provided information is real (validating ID against government database, confirming document authenticity) → Validation
  • A qualified person formally certifying that verification occurred (HR manager signs off, creates auditable record) → Attestation

Memory device: R-V-A (Resolve → Verify → Approve)

  • R: Resolve who this person is (collect identifiers)
  • V: Verify that the identifiers are genuine (authenticate documents)
  • A: Approve with a formal signature/record (attestation)

Common distractors: “Authentication” is not an identity proofing stage — it is what happens when an already-provisioned user logs in. “Authorization” is what happens after authentication. Identity proofing happens BEFORE the account exists.

Rule: Resolution = collect identifiers. Validation = confirm they are genuine. Attestation = authorized person formally certifies it. R-V-A happens before the account is created, not at login time.
Practice Scenarios
Scenario A: A company is reviewing access rights for 500 employees and discovers: (1) an account for an employee who left 8 months ago is still active and was used to access the CRM system last week; (2) a senior developer has accumulated read access to Finance, HR, IT, and Legal systems over five years of internal transfers; (3) a new hire in Sales has not yet received access to the CRM they need to do their job. Identify the IAM problem for each situation and the corrective action required.
Answer: Situation 1 — employee who left 8 months ago still has an active account: Orphaned account. The offboarding process failed to disable the account at separation. Active use of the account last week means either the departed employee retained access (insider threat risk), or an attacker discovered the active credentials (external threat). Corrective action: immediately disable the account across all systems (not just the CRM — all systems), revoke all active sessions and tokens associated with the account, investigate who used the account last week and for what purpose, and review all access logs for the account over the past 8 months. Situation 2 — developer with access to Finance, HR, IT, and Legal: Access creep (privilege creep). Each internal transfer provisioned new access without revoking previous role access, violating least privilege. Corrective action: conduct an access review, determine which permissions are actually needed for the current role, and revoke all permissions not required. This is often implemented as a formal access recertification process where managers must periodically attest to which access rights their team members actually need. Situation 3 — new hire in Sales cannot access CRM: Provisioning failure (under-provisioning). The onboarding process did not include the required access for the job role. Corrective action: provision the CRM access using a role-based provisioning process where “Sales representative” has a defined standard access package. Going forward, role-based provisioning prevents this by automatically granting access consistent with the job role rather than requiring manual ad-hoc requests.
Scenario B: A company has deployed SAML for SSO across its web-based SaaS applications. They now want to extend SSO to their new mobile application for iOS and Android. The mobile app needs to: verify who the user is (so the app can personalize the experience), allow the app to access the user's calendar from the corporate Exchange server (without requiring the user to enter Exchange credentials in the app), and work with the company's existing Google Workspace identity for the “Log in with Google” flow. Can SAML be used for any of these requirements? Which protocol handles each requirement?
Answer: SAML cannot be used for any of the three mobile requirements. SAML relies on browser-based HTTP redirect flows and XML assertion documents. Native iOS and Android apps do not use browser redirect chains for their core flows, making SAML incompatible with native mobile authentication. Requirement 1 — verify who the user is (identity for personalization): OpenID Connect. OIDC is built on OAuth 2.0 and adds an ID token (a JSON Web Token) that the mobile app can parse to learn who the authenticated user is — name, email, profile attributes from the identity provider. The mobile app uses a standard OAuth 2.0 authorization code flow with PKCE (Proof Key for Code Exchange), which is designed for native apps. Requirement 2 — allow the app to access the Exchange calendar without exposing credentials: OAuth 2.0. OAuth grants the mobile app an access token scoped to calendar access on behalf of the user. The user authenticates to the identity provider (not to the app), and the app receives a token it can present to the Exchange API. The user's Exchange credentials are never exposed to the mobile app. Requirement 3 — “Log in with Google”: OpenID Connect. Google acts as the Identity Provider. The mobile app uses OIDC to request an ID token from Google, which the app uses to verify the user's Google identity and establish the session. This is the standard mechanism behind all “Login with [provider]” flows on mobile.
Scenario C: A new employee, Alex Rivera, joins the company as a financial analyst. Describe the complete IAM process from identity verification through provisioning, including what specific steps are taken during identity proofing, how role-based provisioning works, what happens if Alex transfers to the IT department after two years, and what complete deprovisioning looks like if Alex leaves the company three years later.
Answer: Identity proofing for Alex Rivera before account creation: Resolution — HR collects name, date of birth, government ID number, and employee ID to uniquely identify Alex among all individuals. Validation — HR verifies Alex's government ID against an authoritative source (state database), confirms the ID document is genuine and belongs to Alex (not a forged document), and cross-references against background check results. Attestation — the HR manager formally signs off that identity verification was completed for Alex Rivera on the hire date, creating an auditable record. Role-based provisioning: Alex is assigned to the “Financial Analyst” role. This role has a pre-defined access package: Active Directory account, email, access to the financial reporting system, access to the accounts payable portal, read access to the Finance shared drive, and access to the budgeting tool. All of this access is provisioned automatically from the role assignment, not requested and approved individually for each system. Transfer to IT after two years: Transfer provisioning must include both deprovisioning and provisioning. Remove: financial reporting system access, accounts payable portal, Finance shared drive, budgeting tool access (no longer needed for IT role). Add: IT ticketing system, server management portal, network monitoring tools, IT shared drive. Failure to remove Finance access would create access creep — Alex would retain access to financial systems they no longer need. Deprovisioning when Alex leaves: Immediately upon separation, not scheduled: Disable the Active Directory account (preventing any further login). Revoke all active sessions, SSO tokens, OAuth access tokens, and API keys. Remove from all security groups and distribution lists. Disable email and forward to manager if needed. Recover: company laptop, mobile device, hardware MFA token if issued, access badge. Document completion of each step in the HR/IAM system for audit purposes.