Least-Privilege SSO Group Mapping and a Contractor Access Audit
Globex has 300 Instana users across five teams: platform, payments, checkout, data, and contractors. Okta is the SAML identity provider, and SCIM provisioning is enabled. Instana agent zones separate prod, staging, and dev. Contractors must have read-only access to production dashboards but no access to staging or dev, and no ability to change alert configs. The data team needs to manage retention settings but should not administer users. The payments team needs edit rights in production but only view rights in staging. Okta groups currently map one-to-one to Instana teams, but all users receive the Editor role by default. An audit found two terminated contractors still active and one payment user who can administer SSO. You must fix access without disrupting 300 users during a quarterly close.
1. Design the Okta group → Instana team/role mapping. Explain how you enforce least privilege for each team and why a single Editor default fails.
Read the worked answer
The single Editor default fails because it grants change rights everywhere and ignores team scope; it also makes the payments staging requirement impossible. Create Okta groups that encode team, environment, and role, for example instana-prod-payments-editor, instana-staging-payments-viewer, instana-prod-contractors-viewer, instana-data-retention-admin, and instana-platform-sso-admin.
Map each to an Instana team scoped to the matching zone/application and assign the minimum built-in role: Viewer for contractors in prod only; Editor for payments in prod; Viewer for payments in staging; a retention/data role for the data team that can manage data settings but not users; and Admin only for platform SSO administrators. Do not assign roles directly to users; let group membership drive access. This enforces least privilege and makes quarterly review a group review. The trade-off is more groups to manage, but it is the only way to express prod-edit/staging-view without custom roles if the built-in roles are coarse.
2. How do you handle the terminated contractors and the over-privileged payment user, and prevent recurrence?
Read the worked answer
Immediate: deactivate the two contractors in Okta first, confirm SCIM deprovisions them in Instana, and if SCIM failed, disable them manually in Instana. Remove the SSO admin role from the payment user and assign it only to the platform identity group; verify the change in the audit log. Then investigate why SCIM did not deprovision: check the SCIM connector status, group assignment, and whether the users were created locally rather than via SCIM.
Prevent recurrence with a quarterly access review, no direct user assignments, a rule that Admin/Owner roles are limited to a small platform group, and monitoring or alerting on role changes. During quarterly close, do not do a big-bang remap; stage the group changes, verify a pilot team, then migrate the rest.
3. Users report SAML login failures after the mapping change. What do you check?
Read the worked answer
Check the SAML assertion first: NameID format, email attribute, and group attribute name must match what Instana expects. A common failure is that the IdP sends groups under a different claim after an Okta group rename, so the user authenticates but lands with no team or role. Check the Instana SSO configuration, the Okta app assignment, and the SCIM sync status.
Also check certificate expiry, clock skew, and whether the user is in the new group while the old group still grants a conflicting role. Use IdP logs and Instana authentication/audit logs to distinguish 'no assertion' from 'assertion accepted but no authorization'. Test with one pilot user before migrating all 300.