Meet the first digital identities in your lab tenant

Setup

This is the first lab in the course. It turns one of your tenants on beyondthelogin.dev into the Lab Photos tenant, the identity provider for a small photo-sharing service that every later lab builds on.

1. Sign in at https://beyondthelogin.dev with your BTL account. Every account gets one tenant: rename it Lab Photos from the tenant switcher. Labs that also use a second tenant, Lab Mail, say so at the top, because additional tenants currently need a paid subscription or a BTL grant.

2. Open the tenant portal for Lab Photos. On Overview, choose Reset tenant, keep the default to preserve Audit and Logs, and select the Lab Photos preset. The preset creates the lab scopes and three people, Ava, Ben and Cora, without passwords.

3. On this lab page choose Lab Photos as the lab tenant and press Start.

4. Copy the issuer from Overview and keep it in your shell. Use bash, or Git Bash on Windows.

ISSUER=https://tenant-<id>.beyondthelogin.dev

5. Open Authentication and confirm that Password is Required, the default for a tenant.

Walkthrough

1. Open Users and then Ava Archer's View details. Note her ID (a UUID), email [email protected], status Active and Last sign-in Never.

Why it matters: the ID distinguishes this subject within this one system. The name, email and status are attributes that describe her. Together they are a digital representation of Ava, not Ava herself.

2. Open Ben Okafor and Cora Diaz the same way. The attribute names are the same, the values differ, and each record has its own ID.

Why it matters: a directory is a set of digital representations, each with its own identifier. Ava is one person in many systems; here she is one record in one tenant.

3. On Ava's record choose Set password. Pick a strong test password, store it in your password manager, and keep it in the shell without echoing it:

read -rs AVA_PASSWORD

Look for a way to view the password afterwards. There is none, only a way to set a new one.

Why it matters: the password is evidence for proving control of the account. It is not one of the attributes that describe Ava, so the tenant keeps only what it needs to check it.

4. In a private browser window open $ISSUER/token-decoder. Request the scopes openid profile email, start the flow and sign in as Ava. In the decoded ID token find sub, given_name, family_name, email and email_verified.

{
  "iss": "https://tenant-<id>.beyondthelogin.dev",
  "sub": "<Ava's directory ID>",
  "given_name": "Ava",
  "family_name": "Archer",
  "email": "[email protected]",
  "email_verified": false,
  "amr": ["pwd"]
}

Why it matters: the token's sub is the identifier from step 1, and the profile claims come straight from the directory record.

5. Look again at "email_verified": false. An administrator typed that address and nobody has checked that Ava can receive mail there.

Why it matters: this is the lesson's point about claims and evidence. The tenant states the claim and reports honestly that it holds no evidence for it. An application that needs a verified address can tell the difference.

6. In the portal, edit Ava's record and change the first name to Avery. In the Token Decoder start the flow again. You are not asked for a password because the tenant session is still active, and the new ID token shows "given_name": "Avery" with the same sub.

Why it matters: attributes change during an identity's life while the identifier stays stable. Maintaining those records is part of identity and access management.

7. You are not your account. On Users, find yourself listed as an administrator of type BTL and Ava as type Tenant. In the private window open $ISSUER/login and try your BTL email address with a made-up password. Never type your real BTL password into a tenant page. Sign-in is refused.

Why it matters: you are one person with two accounts in two separate systems. Your BTL account manages the tenant; it is not a tenant user, and its credentials never work there.

8. Open Audit and find the events from steps 3 to 7: the password set, the authorization requests and the update to Ava's record. Open one and read its actor and subject.

Why it matters: an IAM system records changes to a representation with who made them and whom they affected, so "who changed this identity?" has an answer.

Break it

1. Create another user with the email [email protected]. The portal refuses with a duplicate email error, and Audit shows tenant.users.create rejected.

2. On Ava's record choose Lock. In the private window sign in as Ava at $ISSUER/login. The page shows the same general error as a wrong password, while Audit records account.sign_in rejected with reason account_locked.

Why it matters: account status is an attribute with consequences. The sign-in page does not reveal it to whoever is typing, but the audit trail does.

Restore: choose Unlock on Ava's record and confirm she can sign in again.

Check your work

Press Check my progress. It looks for these events after you pressed Start:

• tenant.users.credentials.set succeeded for Ava.

• oauth.authorize succeeded with reason code_issued for Ava (the Token Decoder sign-in).

• tenant.users.update succeeded for Ava (the rename).

• tenant.users.create rejected (the duplicate email).

• account.sign_in rejected with reason account_locked.

In Audit you can also find tenant.users.lock and tenant.users.unlock succeeded for Ava.

Cleanup

1. Rename Avery back to Ava and make sure she is unlocked.

2. Keep Ava's password, and keep Ava, Ben and Cora. Later labs use them.