Single sign-on lets users enter several applications through an authentication session managed by an identity provider. The SaaS product relies on that provider to identify the user, while the product still decides what the authenticated account may see and do. Replacing the product therefore involves both identity and application access rules.
What single sign-on does
The identity provider authenticates the user and sends identity information to the application through an agreed protocol. The application matches that information to an account and assigns access. The connection may also create accounts on first sign-in or rely on a separate provisioning process.
| Part | Responsibility | Replacement check |
|---|---|---|
| Identity provider | Authenticates the user | New application is registered correctly |
| Identity claim | Identifies the account | Stable identifier maps to the right user |
| Application role | Controls permitted actions | Role rules match required work |
| Session | Maintains authenticated access | Timeout and logout behaviour are defined |
| Provisioning | Creates and removes accounts | Joiner and leaver flows still operate |
Single sign-on reduces repeated authentication, but it does not unify the applications themselves. Users can still move between different workflows, data models, and interfaces after signing in once.
Why it matters during replacement
A SaaS replacement changes the application registered with the identity provider. Redirect addresses, certificates, client credentials, claims, group mappings, and account identifiers may all change. The old and new applications may coexist during migration, so their names and access assignments must remain distinguishable.
The identity provider may be the single source of truth for a person's sign-in identity while the replacement owns application-specific roles. Recording that boundary prevents authentication from being mistaken for authorization.
What needs to be migrated
The transition plan covers:
- Account matching: connect existing destination accounts to stable identity-provider identifiers.
- Role mapping: translate groups or claims into the permissions the replacement requires.
- Provisioning: create, update, suspend, and remove accounts through the intended process.
- Session policy: set timeouts, logout behaviour, and reauthentication rules.
- Recovery access: define how administrators enter the system if the identity connection fails.
- Audit evidence: retain records needed to explain access changes and sign-in failures.
An API integration may manage provisioning separately from the sign-in protocol. Both paths need owners, credentials, failure monitoring, and a cutover sequence.
Testing and cutover
Testing should cover active users, new users, disabled users, changed roles, invalid claims, expired credentials, and logout. It should also confirm that direct vendor accounts cannot bypass the intended access model after the switch.
The discussion of staff moving between SaaS login screens shows the limit of treating sign-in as the whole user experience. Single sign-on can preserve centralized authentication during replacement. The replacement must still provide coherent workflows, correct permissions, and clear ownership of user access.
