Okta Workforce Identity: set up cleanly and ready to delegate
Okta is my second platform next to Microsoft Entra ID, useful wherever Okta is the leading directory or runs alongside Entra. I set up groups, policies and roles so that they stay understandable and your team can run them on its own.
Typical starting point
Grown groups and rules
Apps are assigned directly to people, group rules were created along the way. Nobody can say any more why someone has access to what.
Administrator rights that are too wide
Support needs password resets and gets a large role for it. A role that can manage only one user group does not exist.
Policies on two levels
Global session policy and authentication policy work together. Without a clean separation you open gaps or lock users out.
What I implement
- Universal Directory, custom attributes and group rules with Okta Expression Language
- Assigning apps through groups rather than people
- Global session policy, authentication policy, password policy and network zones
- Delegated administration: custom role plus resource set
- Single sign-on through SAML 2.0 and OIDC
- Lifecycle management and provisioning through SCIM
- Analysis in the System Log
What matters
Okta separates what sits together in Entra. The global session policy decides whether a user may enter the org at all and how long the session lasts; the authentication policy decides per app what is required for it. A custom session policy has to sit above the default policy, or it has no effect. Delegated administration also consists of two objects: the role says what someone may do, and the resource set what they may do it to.
Small details decide in operation: a group rule is inactive after saving and has to be activated first. Someone who joins a group through a rule cannot be removed by hand. That is why tests always run from the user's side in a private window, and the System Log shows which rule applied.
Approach
1. Understand
An inventory of apps, groups, roles and policies. Which rule really applies, what is left over, what is intended?
2. Design
Group and role model, order of the policies and provisioning per app. In an Okta and Entra environment also: which system leads which attribute?
3. Implement
Changes in scoped steps, each tested from the user's side in a private window and checked in the System Log.
4. Hand over
Documentation of the structure and a runbook, so that your team creates new apps and roles to the same pattern.
What you get
- An understandable group and role model
- Documented policies in their order
- An integration data sheet per connected app
- Runbook and handover to your operations team
The same concepts, different names
| Microsoft Entra | Okta |
|---|---|
| Dynamic group | Group rule |
| Conditional Access | Global session policy + authentication policy |
| Named locations | Network zones |
| Roles + administrative units | Custom role + resource set |
| Sign-in logs | System Log |
Backed by
Built in two of my own Okta orgs alongside the performance exams, which are taken in real Okta orgs. The lab shows group rules, a delegated helpdesk, policies and SAML federation with screenshots.
Common questions
Okta or Entra ID?
Both are possible, and I do not decide that for you up front. I work with both platforms and can set up or clean up your existing environment.
Is just-in-time creation enough instead of provisioning?
Often for a start, but JIT only creates users at first login and never removes anyone. If a user is disabled at the source, their account stays at the target. That takes provisioning.
Do you also support a migration between identity providers?
I have not delivered such a migration for a client so far. With Okta I work on existing environments and in scoped packages.