Access & Identity on ResorsIT Tools Catalog

Forward-auth

Mon, 01 Jan 0001 00:00:00 +0000

Forward-auth (proxy-gated, no native SSO)

Some tools cannot speak OIDC or SAML at all, yet must not be left open behind a separate login. Forward-auth covers them: the tool is placed behind the ResorsIT reverse proxy, and the proxy – not the tool – authenticates the user against the platform IdP before any request reaches the application.

This means a tool with no SSO support whatsoever can still be gated by platform identity. The user signs in once at the IdP, and the proxy carries that proven identity forward.

Directory / LDAP

Mon, 01 Jan 0001 00:00:00 +0000

Many tools predate OIDC and SAML but can authenticate against an LDAP directory. For these, ResorsIT does not need a browser SSO redirect: the tool binds to the platform directory and checks the user’s login there, so the credential is still centrally held and centrally governed.

LDAP is a genuine platform access method, not a fallback bookmark. The account lives in one place, is disabled in one place, and the tool reads it live.

Vaulted credential

Mon, 01 Jan 0001 00:00:00 +0000

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.

Non-SSO identities

Mon, 01 Jan 0001 00:00:00 +0000

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
Email	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.

Local host account

Mon, 01 Jan 0001 00:00:00 +0000

Local host account

Some tools run locally on a host – a desktop application, a command-line tool, or a service on a workstation or server – and have no login of their own. The user reaches them simply by being signed in to the machine. On ResorsIT that local operating-system account is not unmanaged: it is an IGAP-governed identity, so a tool that trusts the logged-in user is still governed centrally.

Provisioned account

Mon, 01 Jan 0001 00:00:00 +0000

Provisioned account (SCIM / ConnID)

Authentication is how a user proves who they are at login; provisioning is how the account they log in to comes to exist in the first place. For many tools the login stays local to the tool, but the account behind it is created, updated, and disabled automatically by the platform – so access is governed even when sign-in is not federated.

This is the joiner / mover / leaver lifecycle: when a person is hired, moves role, or leaves, their accounts across connected tools follow, without an operator touching each one.

Key-based access

Mon, 01 Jan 0001 00:00:00 +0000

Key-based access (SSH / age)

Not all access is a password or a browser login. SSH and age keys are access credentials in their own right, and the platform manages them as such – so reaching a host over SSH, or decrypting a payload with age, is a governed access path alongside the identity-based methods.

Keys are tracked separately from a user’s identities. A person’s login accounts and their keys are related but distinct: a key can be added, rotated, or revoked without touching the accounts, and vice versa.

Access & Identity on ResorsIT Tools Catalog

Forward-auth

Forward-auth (proxy-gated, no native SSO)

Directory / LDAP

Directory / LDAP login

Vaulted credential

Vaulted / governed credential

Non-SSO identities

Non-SSO identities (email, Windows)

Why identities are kept apart

How ResorsIT integrates it

When a tool uses this

Local host account

Local host account

Provisioned account

Provisioned account (SCIM / ConnID)

Key-based access

Key-based access (SSH / age)