Domain 5 · Identity and Access Management · Lesson 5 of 8
Manage identities, federation and privileged access
About 16 minutes · Introductory draft · Checked 2026-10-22
AI editorial review for introductory study; independent review and complete exam alignment remain pending. Read course scope and remaining gaps.
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
What you will learn
- Separate authentication, authorization and accountability.
- Explain federation trust and access lifecycle changes.
- Constrain privileged and automated identities.
Separate proof from permission
Identification presents an identity claim. Authentication evaluates proof of that claim. Authorization decides what a subject may do with a resource. Accountability requires trustworthy records tied to identities and actions. A successful login should not be treated as permission to access every record.
Use authentication methods appropriate to the risk, with protected enrollment and recovery. Multi-factor methods combine different factor types rather than two variants of the same secret. Session handling matters after login: revocation and expiry must have the intended effect on subsequent requests.
Understand trust and lifecycle
Federation allows a service to rely on an identity assertion from a trusted provider under agreed rules. The relying service must validate the assertion for its intended use, including signature, audience and validity conditions as applicable. It still needs to make its own resource-authorization decision. Trusting an identity provider does not mean accepting any token for any application.
Joiner, mover and leaver processes should update permissions from an approved source. A job change often requires removal of obsolete access, not merely a new group membership. Periodic reviews with resource owners can find drift, but should not replace timely changes when a person leaves or a role changes.
Limit elevated and automated authority
Role-based access groups permissions around responsibilities; attribute-based decisions can also consider resource, subject and environmental attributes. Regardless of the model, test how combinations of permissions behave. A harmless-looking pair of roles can permit both requesting and approving a sensitive action.
Privileged accounts, services and AI agents need distinct owners, scoped permissions and appropriate credential handling. Use time-limited elevation where suitable and retain records of its approval and use. A service credential should be retired when its workload ends. Shared administrator credentials make it harder to attribute an action and revoke one person’s access.
Work through a scenario
Fictional facts for learning. This exercise is not scored.
A former contractor’s identity provider account is disabled, but an application continues accepting an existing long-lived session. What should the identity review examine?
Compare your reasoning
Examine the application’s session lifetime, revocation and federation behavior against the agreed termination requirements. Disabling the upstream account may not terminate every issued application session immediately. Define and test the required end-to-end loss of access, including privileged and automated credentials where relevant.
Applied study · Added 2026-10-22
Evaluate federation and privilege as effective access
Continue beyond the introduction. Work through the evidence before opening the model answer.
See it · Try it · Recall it
Picture the topic
Remember this: A door badge and a system permission protect different boundaries.
Explore the anchors
Control access to spaces and equipment.
Concept matching activity
Match this task or description to its concept:
Control identities sessions and permissions.
Choose a concept before checking the explanation.
Access-decision sandbox
Try to edit a fictional record as a reader. Then change one condition and evaluate again. This simplified policy requires authentication, object scope and action permission; real policies have more conditions.
Change the request, then evaluate it.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
Visual recap for topic 5.1. Open its full syllabus chapter.
Separate federation, delegation and authorization
Federation lets a relying service use trusted identity information, but that service still needs an authorization decision. OAuth supports delegated authorization; OpenID Connect adds an identity layer for authentication scenarios. Token audience, issuer, signature, expiry and intended use all matter. A valid token for one API should not automatically work against another. Single sign-on can simplify use and administration while concentrating dependence on the identity provider; plan and test that dependency.
Govern privileged and non-human access
Privileged access should be approved, limited to the required task, monitored and revoked when no longer needed. Service identities also need an owner, purpose, secret or credential lifecycle and review. A human departure can leave automation credentials or delegated application grants active. Review effective permissions across groups and roles rather than looking only at the friendly role name. Emergency access needs protected custody and after-use review, not an undocumented permanent bypass.
Evidence case
Fictional facts for learning; no real organization or person is described.
- An API accepts a correctly signed token issued for a different application.
- The team believes signature validation alone establishes that the request is authorized.
Your task
- Identify the missing trust checks.
- Define a negative test for the correction.
Compare with the model answer
Validate the intended audience and other token conditions, then enforce the caller’s permission for the requested resource and action. A trusted signature alone does not make a token appropriate for this API. Test an authorized token for the API and rejection of a token for another audience, using the approved test issuer and synthetic data.
This case has two original scenario questions in the expanded practice bank. Practice this course · Edition, coverage and remaining study
Remember
- Identity proof and resource permission are separate decisions.
- Federation requires explicit trust validation and session rules.
- Review combinations of access and revoke obsolete authority promptly.
Orientation and further reading
Original examples and explanations. Background references do not establish complete exam coverage.