Practice: Setting up SSO and provisioning with Okta and Entra ID
Generated by Claude (Fable 5.1) by hand from the identity and integration ops spike, Scout learning center on 2026-10-14.
Main tool: Okta and Entra ID consoles (reader-only), Keycloak and scim2 as stand-ins · The vendors' consoles are the actual job and their official pages give the exact field names, so the steps transcribe those and mark them 'needs a free account; not run by the learning center'; everything protocol-shaped is rehearsed against Keycloak, which the OIDC and SAML paths already ran, and the SCIM side against python-scim's server, client and compliance tester, which stand in for a vendor's provisioning engine. · Alternatives: A customer's sandbox tenant, when offered, beats every stand-in; Auth0 and Ping also offer free developer tenants with similar consoles; for SCIM, elimity-com/scim and imulab/go-scim are Go server libraries and 15five/scim2-filter-parser parses the filter grammar when you write your own endpoint.
Every step links into the tool's own documentation; links were checked on 2026-10-14 · version 1
Setup (one time)
1. Decide which of the three routes you will take: a real Okta Integrator Free Plan organisation and a free Entra tenant (both need an account of your own; the learning center created none and the vendor steps below are reader-only until you do), or the Keycloak stand-in from the OpenID Connect and SAML practice paths, or both.
The vendor consoles are the job; Keycloak is where the protocol parts can be rehearsed without an account.
Explained in: Okta Developer: Integrator Free Plan sign-up (developer.okta.com), checked 2026-10-14
Done when: You have either a vendor admin console open, or Keycloak on 127.0.0.1:18080 with the realm from the earlier paths, or both.
2. Create a scratch Python virtual environment and install scim2-server, scim2-cli and scim2-tester for the provisioning steps (no global install).
A local SCIM endpoint, a client that sends what an IdP sends, and a compliance tester are the SCIM stand-in.
Explained in: RFC 7644: SCIM Protocol (datatracker.ietf.org), checked 2026-10-14
Done when: scim2-server --help and scim2 --help both print usage.
Steps
1. Okta (needs a free account; not run by the learning center): read the Integrator Free Plan sign-up page and note the inactivity expiry; if you proceed, create the organisation with your own details.
Knowing the free route exists, and its limits, lets you rehearse the console before a customer call.
Explained in: Okta Developer: Integrator Free Plan sign-up (developer.okta.com), checked 2026-10-14
Done when: You can state the plan's expiry rule and, if you signed up, you can open the Admin Console.
2. Okta (needs a free account; not run by the learning center): create an OIDC app integration of type Single-Page Application with Authorization Code and Refresh Token, the sign-in redirect URI http://127.0.0.1:18081/callback, a sign-out redirect URI, a Trusted Origin for http://127.0.0.1:18081, and an assignment to yourself; then read the Client ID, the PKCE setting and the client authentication method on the General tab. Keycloak stand-in (run): the public client web-pkce with the same switches.
These are the fields you will fill in with every customer's administrator; the names on the page are what you will be reading aloud.
Explained in: Okta help: Create OIDC app integrations (help.okta.com), checked 2026-10-14
Done when: You have the client id, the issuer URL and the registered redirect URI written down, and the discovery document of the issuer answers 200.
3. Okta (needs a free account; not run by the learning center): create a SAML 2.0 app integration with the Single sign-on URL set to your SP's ACS, the Audience URI to the SP's entity ID, Name ID format EmailAddress, an attribute statement email = user.email and a group attribute statement groups filtered to a group name; preview the assertion; download the certificate on the Sign On tab; assign the app. Keycloak stand-in (run): the SAML client from the SAML path with its mappers.
This is the SAML half of the setup call; the preview is where claim mapping is fixed before a single real login.
Explained in: Okta help: Create SAML app integrations (help.okta.com), checked 2026-10-14
Done when: The previewed assertion shows your audience, the NameID as an email and the two attributes, and you hold the IdP certificate and metadata.
4. Okta (needs a free account; not run by the learning center): on a custom authorization server add a claim (for example department from user.department) to the ID token, and a groups claim with a filter; test with the token preview. Keycloak stand-in (run): a user attribute mapper and the group membership mapper on the client.
Custom and group claims are the usual second request from a customer; the filter is what keeps tokens small and roles explicit.
Explained in: Okta Developer: Customize tokens returned from Okta with a custom claim (developer.okta.com), checked 2026-10-14
Done when: The previewed or real token carries the custom claim and a groups array with the filtered group names.
5. Entra ID (needs a free account; not run by the learning center): in the admin center register an application (single tenant), record the Application (client) ID and the Directory (tenant) ID, add a Web platform with the redirect URI http://127.0.0.1:18081/callback, create a client secret and note its expiry, and fetch the tenant's v2.0 discovery document.
An app registration is Entra's OIDC client; the two ids and the secret expiry are what every later ticket will ask for.
Explained in: Microsoft Entra: Quickstart - register an application (learn.microsoft.com), checked 2026-10-14
Done when: The discovery document for your tenant answers 200 and its issuer contains the tenant id; the secret expiry date is in your note.
6. Entra ID (needs a free account; not run by the learning center): create a non-gallery enterprise application, open Single sign-on, SAML, set the Identifier to your SP's entity ID and the Reply URL to its ACS, download the certificate and note the Login URL, the Microsoft Entra Identifier and the App Federation Metadata Url; under Attributes and Claims set the Name identifier to the email with format Email address and add a group claim for groups assigned to the application; assign a user; run 'Test single sign-on'.
This is the Entra SAML setup call end to end, including the test button the troubleshooting lesson relies on.
Explained in: Microsoft Entra: Enable single sign-on for an enterprise application (learn.microsoft.com), checked 2026-10-14
Done when: The test sign-on succeeds (or reports an error you can read), and you have the three URLs, the certificate expiry and the claim configuration written down.
7. Entra ID (needs a free account; not run by the learning center): read the provisioning page for what the Entra service sends to a SCIM endpoint (the resources, the filters, the PATCH operations, active for soft delete) and the endpoint requirements; compare with Okta's SCIM concept page and list the differences you would need to handle in one endpoint that serves both.
A SCIM endpoint is written once and called by several vendors' engines; the differences are what make it hard.
Explained in: Microsoft Entra: Use SCIM to provision users and groups (learn.microsoft.com), checked 2026-10-14
Done when: Your note lists at least three concrete behaviours (for example the lookup filter, the active flag handling, DELETE vs deactivate) with which vendor does what.
8. Keycloak stand-in (run in the OIDC and SAML paths): confirm you have done, against Keycloak, the OIDC client with PKCE and exact redirect URIs, the SAML client with NameID and mappers, a group claim, and one login of each with the messages decoded. Write the mapping table 'Keycloak field, Okta field, Entra field' for the ten fields you touched.
The table is the artifact that lets you run a customer's console you have never seen: same fields, different labels.
Explained in: Microsoft Entra: Customize SAML token claims (learn.microsoft.com), checked 2026-10-14
Done when: The table has ten rows with all three columns filled from the vendor pages.
9. Start scim2-server on 127.0.0.1 and, with scim2-cli, create a user alice@example.test, query by a userName filter, PATCH active to false, read the user back, and delete it; read the server's log for each request. (Read, not run by the learning center.)
Doing the five operations by hand once is the fastest way to read a vendor's provisioning log later.
Explained in: RFC 7644: SCIM Protocol (datatracker.ietf.org), checked 2026-10-14
Done when: Each of the five operations returns the status code RFC 7644 prescribes (201, 200, 200, 200, 204) and the log shows the exact JSON the client sent.
10. Run scim2-tester against the local endpoint and read its report; then write down which checks a hand-written endpoint of yours would need to pass before a vendor's 'test connection' would succeed. (Read, not run by the learning center.)
The compliance tester stands in for the vendor's provisioning engine; it fails on the same things Okta and Entra fail on.
Explained in: RFC 7643: SCIM Core Schema (datatracker.ietf.org), checked 2026-10-14
Done when: The tester reports no failures against scim2-server, and your note lists the checks (discovery endpoints, filter on userName, PATCH semantics, error codes).
11. Write the deprovisioning decision for a product: what happens on active false, on DELETE, to live sessions, to API keys, to the user's data and after how long; and the offboarding runbook for a customer who uses JIT only.
This is the question every security review asks about provisioning; having the answer written is the difference between a pass and a follow-up.
Explained in: Okta Developer: SCIM (developer.okta.com), checked 2026-10-14
Done when: A one-page note a customer's security reviewer could accept, with both the SCIM and the JIT-only case covered.
Back to Setting up SSO and provisioning with Okta and Entra ID