Non-SSO identities (email, Windows)
Not every way a person reaches a tool should run through the single sign-on password – and on ResorsIT, some deliberately do not. A person is one user, but that user can hold several identities, each with its own credential, where security demands the isolation. These extra identities are non-SSO access paths by design, not by limitation.
Why identities are kept apart
- Email – mail clients (desktop and mobile) store the password on each device. If that were the SSO password, one lost device would expose everything. Email gets its own identity and its own password.
- Windows – Windows and file-sharing protocols store and transmit credentials in weaker forms than the SSO flow. The Windows login is a separate identity so an attack on it cannot yield the SSO password.
How ResorsIT integrates it
- Each identity is provisioned and de-provisioned with the user, in step, so all of a person’s identities are disabled together when they leave
- Each has its own credential and its own password rules; the passwords are not synced to one another
- The user store presents them as one person with multiple identities, not several unrelated accounts
| Identity | Reaches | Credential |
|---|---|---|
| Primary | SSO tools (OIDC / SAML), the Hub, MFA | strong; never stored on devices |
| IMAP / SMTP / CalDAV / CardDAV | own password; kept on mail clients | |
| Windows | Windows logon, SMB file shares, Kerberos | own password; separate from SSO |
When a tool uses this
A tool reached over a mail protocol (an IMAP/SMTP client) or over Windows file-sharing is accessed through the matching identity, not the SSO login. This is the platform’s answer to tools that authenticate outside the browser and must not share the primary password.
Reaching a tool by its Windows or email account often goes hand in hand with a provisioned account, which creates and governs those accounts, and a vaulted credential, which holds their passwords.
