jperezduerto.info
Security in depth · Unit 25 · Lesson 8 of 12
Federation needs a specific subject
Decide whether a valid external token represents the particular job your trust record accepts.
Helpful before thisCloud identity
After this lesson you can
- Distinguish a trusted issuer from an accepted workload subject and its later permissions.
Recognizing the issuer does not approve every job it identifies.
Follow identity across systems
Workload identity federation lets a cloud identity service accept external identity evidence according to a configured trust relationship. The external token is exchanged for an access token; permission to use a resource remains a separate decision.
For a standard Microsoft Entra federated identity credential, issuer, subject, and audience must match the configured values, including case. The issuer identifies the token authority; the subject identifies the workload; the audience identifies the intended recipient.
Compare the supplied records
F1: The production identity trusts issuer BuildID, subject release-prod, and audience ExchangeA. These labels stand for complete exact values.
F2: A validated external token has issuer BuildID, subject release-preview, and audience ExchangeA. Its signature and time checks pass.
F3: The owner approves only the production release workload. No other federation rule accepts preview jobs.
Assume the standard exact-match configuration described above, with no alternate rule or additional mismatch. F2 fails the subject condition. A familiar issuer and correct audience do not make release-preview equivalent to release-prod.
The sound response is to preserve the production boundary and investigate why the preview workload requested that identity. Broadening trust merely to make the exchange succeed would change F3’s approved scope.
Write a field comparison showing two matches and one mismatch, followed by the expected rejection. For a later production acceptance record, require the intended subject and the other validation checks, then evaluate the resulting identity’s resource permissions separately. A successful identity exchange would not prove that every deployment action is authorized, or that the build’s contents were reviewed.
Check yourself
No timer. No penalties. Read the explanation and try again whenever you like.
This lesson’s questions have changed. Your reading progress is saved; review the updated questions.
-
Why should the token exchange in F2 fail under the supplied standard trust record?
Show the answer
Correct answer: Its subject differs from F1 even though the issuer, audience, signature, and time checks pass. F1 accepts a specific subject using exact matching. A valid token for release-preview does not satisfy trust configured for release-prod.
Try it
- WriteWrite a three-field comparison of F1 and F2: issuer, subject, audience. State the exchange decision, the mismatching evidence, and why a successful exchange would still require resource authorization.