Separate people, accounts and entitlements in your own tenant

Setup

1. Finish the previous lab first: the groups Print support, Photo moderation and Print incident reviews exist, and Ben holds the Help desk management role.

2. Have the email address you use to sign in to Beyond the Login ready. Step 2 uses it for a tenant user, then deletes that user.

3. Press Start on the lab page.

Walkthrough

1. One person, two accounts. On Users, create [email protected] with first name Ben and last name "Okafor (admin)". Set a password, keep it in your password manager, and assign it the Help desk management role. Users now lists two rows for Ben. Open both: no field links them, and nothing in the tenant knows they are the same person.

Why it matters: this is "One person, many accounts". Like Jordan's everyday and administrator accounts, both belong to Ben, but the tenant holds accounts, not identities. Linking them is the identity system's job.

2. A matching email is not identity. Create one more tenant user with exactly your Beyond the Login sign-in email and no management roles, and set it a password. In a private window, sign in at $ISSUER/account with that tenant user, then open $ISSUER/manage. The tenant gives it no management pages, and the tenant password does not sign you in to beyondthelogin.dev. Close the window and delete this user.

Why it matters: correlating accounts on a matching email would hand one account's authority to another. Here the BTL account and the tenant user share an address and nothing else, because authority comes only from role assignments.

3. Name the four kinds of entitlement. Write one example of each from your tenant:

   • Permission: one entry from the catalog on the Roles page, such as tenant.users.lock.

   • Role: Help desk, a named bundle of three permissions.

   • Group: Photo moderation. A tenant group carries no management permissions. It is a named set of people that applications could grant something to.

   • Client entitlement: a scope assigned to a client on OAuth > Clients, such as prints.create on lab-print-orders if you did the OAuth track. The directory lab gives lab-provisioning a SCIM scope.

Why it matters: this is "What an entitlement is". When someone asks what Ben can do, the honest answer mixes all four kinds.

4. How far a change reaches. In a private window, sign in at $ISSUER/manage as [email protected], open Photo moderation > Members, and leave the dialog open. In your own window, open Roles and remove tenant.groups.update from Help desk. Now add Cora to the group from the open dialog and save. The tenant refuses with access_denied, and Audit records tenant.groups.members rejected. Ben's everyday account lost the same permission in the same moment.

Why it matters: removing a role permission changes every holder at once. Removing one group membership changes one person. Knowing which kind of entitlement you are touching tells you how far a change will reach.

Restore: add tenant.groups.update back to Help desk and save.

5. Connect accounts by an ID that never changes. Open Ava's details on Users and copy her User ID. Edit Ava: change her last name to Brooks and her email to [email protected]. Search Audit (Source User directory) for the User ID: her group changes from the previous lab and today's tenant.users.update all appear under one subject. Now search for [email protected]. Nothing comes back, because Audit search matches identifiers, not names or addresses.

Why it matters: this is "Connecting accounts to people". A system that keyed Ava's records on her email would have lost them at the rename. The ID both sides hold is what keeps her history together.

6. Spot an uncorrelated account. Create [email protected] (first name J, last name Smith) in the portal and add it to Print support. Look at the Source column on Users: every account so far says Tenant, created by hand. Open the new account's details. It has no external ID, no owner and no description.

Why it matters: correlation needs a stable identifier that both sides hold. No source system knows this account, so it would appear in nobody's identity view, exactly like the lesson's jsmith2.

7. Write the catalog. For Print support, Photo moderation, Print incident reviews and Help desk, write a table with owner, a plain description of what it allows, and sensitivity. Then try to record the owner on the group or role in the portal. There is no field for it.

Why it matters: this is "Owners and descriptions". A reviewer shown "Help desk" can only rubber-stamp it unless someone wrote down what it allows and who answers for it.

8. See the whole picture. For Ava, list every account and entitlement you can find: her tenant user, her groups, any OAuth grants from other tracks. Mark each row with how it is tied to Ava (User ID, email, or nothing).

Why it matters: this is "Seeing the whole picture". Rows tied by the stable ID survive a rename; rows tied by email or by nothing are the ones to distrust.

Break it

1. Open Roles and try to delete Help desk while Ben and his admin account still hold it. The portal refuses with role_in_use, and Audit records tenant.roles.delete rejected. An entitlement that is still held cannot vanish silently.

Check your work

Press Check my progress. The checks look for, in order:

• tenant.users.create succeeded (step 1)

• tenant.users.management_roles.assign succeeded (step 1)

• tenant.roles.update succeeded (step 4, the removal)

• tenant.groups.members rejected with access_denied (step 4)

• tenant.users.update succeeded (step 5)

• tenant.roles.delete rejected with role_in_use (Break it)

In Audit, confirm that Ava's tenant.users.update has the same subject ID as her earlier group changes.

Cleanup

1. Edit Ava back to last name Archer and email [email protected]. Later labs use that address.

2. Delete [email protected] and [email protected], and confirm the user with your BTL email is gone.

3. Keep your catalog table. The access review lab asks you to show it to a reviewer.

Missing infrastructure

• G52: groups, management roles and clients have no owner, description or sensitivity fields. With them, step 7 would edit real records, and later review labs would show the description to the reviewer instead of asking you to keep a table.