Vaulted / governed credential
Some tools federate no identity at all – no SSO, no directory bind – and keep their own local login. Left alone, that is an unmanaged password the user sets and the platform never sees. ResorsIT closes that gap by taking custody of the credential rather than the identity: the platform holds and delivers the login, so even a fully standalone tool has a governed, non-personal credential behind it.
Crucially, this credential is not the user’s SSO password. The platform deliberately keeps each such login isolated, so a leak from one tool cannot replay against the rest of the estate.
How ResorsIT integrates it
- The account on the tool is created and governed by the platform, even though the tool authenticates it locally
- The credential is held by the platform – hashes in the user store, and, only where a system genuinely needs the plaintext, sealed in a platform secrets vault and referenced, never kept in the clear
- An on-host agent delivers the credential next to the tool at set time; the governance engine never handles the secret itself
- Lifecycle still applies: when the user is deactivated, the governed account is disabled
When a tool uses this
Vaulted credentials fit legacy and vendor-locked tools that cannot participate in SSO or LDAP but whose accounts should still be created, rotated, and revoked under platform control. It is the difference between “a separate login the user manages alone” and “a separate login the platform governs.”
If the tool can be fronted by the proxy, forward-auth avoids a stored credential entirely and is preferred. A tool that is only ever a public bookmark – no login to govern – stays a plain link.
