Review every place your tenant decides which account this is

Setup

1. Press Start on this page.

2. In Lab Mail, create a user with the same address as Cora, [email protected], and give it an administrator password. It is a different person at a different provider who happens to use the same address.

3. In Lab Photos, open Provisioning, turn on the SCIM API if it is off, and create the provisioning client lab-provisioning with the one-click option if you do not have it. In OAuth > Flow policy, allow the client credentials grant. Keep the client's values in your shell:

SCIM="$ISSUER/scim/v2"
PROV_ID=<lab-provisioning client ID>
read -rs PROV_SECRET
SCIM_SCOPE=<the SCIM scope that can write users>

Walkthrough

1. Sign in as Cora at $ISSUER/token-decoder and note the ID token's iss, sub and email. Then sign in as the Lab Mail user at $ISSUER2/token-decoder and note the same three claims.

Why it matters: the email is identical and the people are different. Only the pair of issuer and subject tells them apart, which is why an application that links on email would hand one person's account to the other.

2. In Lab Photos Users, change Cora's email to [email protected]. Sign in as Cora through the Token Decoder again with her new address. email changed; sub did not.

Why it matters: an email describes the account at a moment in time and can change hands. The subject your tenant assigned never does, so an application that stored iss and sub still finds the right account.

3. In Provisioning, read the setting "When a new user's email matches an existing user." It is Refuse the new user by default. Create a temporary user by hand in Users named Temp Link with the address [email protected]. Then send a provisioning request for the same address.

SCIM_TOKEN=$(curl -s -u "$PROV_ID:$PROV_SECRET" -d grant_type=client_credentials -d scope="$SCIM_SCOPE" "$ISSUER/oauth/token" | jq -r .access_token)
curl -s -H "Authorization: Bearer $SCIM_TOKEN" -H 'Content-Type: application/scim+json' \
  -d '{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"userName":"[email protected]","externalId":"hr-9001","name":{"givenName":"Temp","familyName":"Link"},"emails":[{"value":"[email protected]","primary":true}]}' \
  "$SCIM/Users" | jq .

Why it matters: with the default, a matching email is refused, so a provisioning source cannot take over an account someone else created just by sending its address.

4. Change the setting to Link a user created by an administrator and save. Send the same request again. This time the tenant adopts the hand-made user: its record now says it was provisioned by lab-provisioning.

Why it matters: linking by email is safe only when the source owns those addresses, such as your own HR system for your own domain. Decide whether your tenant needs it, and write down that condition.

Restore: set the option back to Refuse the new user and save.

5. Open Access Token Management and ID Token Management and review each claim mapping. Confirm none derives identity or authority from a value users can edit themselves, such as a display name. Try adding a mapping named acr and see it refused as a reserved name.

Why it matters: the lesson's quieter route is a mapping that turns an editable attribute into authority. Reserved names stop a static mapping from claiming an assurance level or delegation no sign-in produced.

6. In Audit, source User directory, open the two tenant.provisioning.update events and the scim.user.link event. Each names who made the change and when.

Why it matters: trust configuration decides who can sign in as whom. Changes are rare, so each one deserves a record and, ideally, an alert.

Break it

1. In a private window, sign in as Ben (who holds only lab-support) and open $ISSUER/manage/provisioning directly, since his navigation does not offer it. The page loads, but the tenant refuses to return the settings. Changing trust settings needs a permission Ben was never given, so nothing needs restoring.

Check your work

• Check my progress confirms Cora's email change, the temporary user, the provisioning change and Ben's refusal.

• Your notes show two different iss and sub pairs for the same email, and one sub for Cora before and after her email change.

• In Audit, the first provisioning request for [email protected] is scim.user.create rejected, and the second is scim.user.link succeeded.

Cleanup

1. Change Cora's email back to [email protected].

2. Delete the user [email protected] in Users.

3. Delete the Lab Mail user you created for this lab.

4. Confirm the provisioning option is Refuse the new user, and clear the shell: unset SCIM_TOKEN PROV_SECRET.

Missing infrastructure

• G26: there are no external identity providers and no account linking, so "add a provider" and "link only after the person signs in with the account's own methods" cannot be practiced. Once it exists, the lab will add Lab Mail as a provider to Lab Photos, confirm sign-ins are matched on Lab Mail's issuer and subject, and confirm adding the provider raises an Audit event.

• G25: there is no SAML trust or signing certificate to review. Once it exists, the lab will compare a partner's published certificate with the configured one.

• G21: group and role claims are limited and directory roles are fixed to member, so "a group that maps to an administrator role" has no tenant counterpart. Once it exists, the lab will review which groups produce which role claims.

• G66 Second lab tenant: this lab uses Lab Mail, a second tenant. Additional tenants currently need a paid subscription or a BTL grant, so an ordinary learner can do only the Lab Photos steps until every learner can have a second lab tenant.