A jointly scoped pilot with agreed systems, examples and acceptance criteria.
Connect one agreed sign-in protocol to one identity provider
Define the scope of SCIM provisioning and deactivation for users or groups
Test role changes, disabled accounts and tenant isolation
Scope, project price, schedule and required provider services are agreed before commissioning. Handover includes the agreed technical documentation and introduction.
Maintain one identity integration through certificate changes, synchronisation errors and changed roles.
Technical takeover of the agreed existing solution
Agreed monitoring, troubleshooting and change maintenance
Documented handover of open issues and completed changes
Monthly price, allowance, service hours, term and cancellation are agreed separately. Infrastructure, licences and on-call support are included only when explicitly offered.
Application, identity provider and required protocol
Tenant model, role rules and expected offboarding behaviour
A description is enough for your first enquiry. We will then agree suitable ways to exchange files and arrange access.
What the scope covers
SSO and SCIM serve different purposes. The protocol, identity provider and session rules are defined for each pilot. Licences, existing product capabilities and required changes are checked beforehand.
We check the package against your project. Your enquiry is non-binding; commissioning and scheduling are agreed afterwards.
UNDERSTAND THE TOPIC
SSO is not offboarding: why SCIM has a separate job.
Central sign-in establishes how a person authenticates. SCIM standardises the provisioning and management of identity data between systems. An application can support SSO while still retaining outdated accounts or groups.