Technical Guide · Business Email and Collaboration
SCIM and SSO: Joiner, Mover and Leaver Lifecycle
SSO handles sign-in; provisioning manages application accounts and roles. SAML/OIDC deployment does not prove automatic creation or deactivation of target accounts. SCIM can transmit…
Technical review:
Architecture and operating model
SSO handles sign-in; provisioning manages application accounts and roles. SAML/OIDC deployment does not prove automatic creation or deactivation of target accounts. SCIM can transmit these account changes through a standard API model.
Google Workspace automated provisioning depends on application/edition support. Entra provisioning also relies on connectors, mappings and scope rules. Distinguish source identity, immutable target ID and email changes; email is not always a stable key.
Setting active=false at offboarding does not guarantee immediate revocation of sessions or API keys. Check data ownership, licenses, delegation and service identities separately. Deletion and suspension do not provide the same recovery options.
- 1Source identity
- 2Scope/mapping
- 3SCIM target account
- 4Session/data checks
Design parameters
- Identity key
- Separate stable IDs from mutable usernames; pilot renames.
- Scope
- Define which group/OU assignments include/exclude users.
- Session revocation
- Handle SSO, target sessions and API tokens with separate revocation steps.
Worked example
Create a test employee, move departments and remove them from the scope group. Measure account, role and session changes after each step. If provisioning completes in 15 minutes but an application session stays active, offboarding acceptance is incomplete.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Duplicate accounts | Matching key changes during rename. | Check source ID and target externalId mapping. |
| Account disabled but API works | Separate token or service identity. | Inspect token owner and target revocation behavior. |
Acceptance checks
- Complete joiner testing.
- Test department/role changes.
- Verify rename matching.
- Distinguish suspension and deletion.
- Measure session/token revocation.
- Transfer data ownership.
Related concepts
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. An unrepresentative test environment can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the actual runtime user, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Least privilege and separation of duties
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behaviour. A log describes an event, a metric shows behaviour over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.