How a person reaches a tool
Each tool carries a ResorsIT usage label that says how the platform adopts it – as a web app, a deployment payload, a device, and so on. That is one axis. This section covers the other: once a tool is adopted, how a person actually authenticates and reaches it.
The two are independent. Knowing a tool is a “Web App” does not tell you how a user signs in to it, and single sign-on is only one of several answers.
Access is not only SSO
IGAP – the platform’s identity suite – targets both SSO and full IAM, for SSO and non-SSO tools alike. A tool that speaks no OIDC or SAML is not left as an unmanaged bookmark: it can still be gated, provisioned, and governed by the platform through other paths.
The access methods
| Method | How a user reaches the tool |
|---|---|
| Single sign-on | One login via the platform IdP (OIDC/SAML) |
| Forward-auth | No SSO; the proxy authenticates and gates |
| Directory / LDAP | The tool binds to the platform directory |
| Vaulted credential | A governed platform-held login |
| Non-SSO identities | Separate email and Windows logins |
| Local host account | Signed in to a managed host |
| Provisioned account | Account lifecycle is automated |
| Key-based access | SSH or age keys |
Access is authenticate and authorize
Reaching a tool is two steps, not one. Authentication proves who the user is (the methods above); authorization then decides what they may see and do. On the platform, the Hub shows each user only the tools they are entitled to, and that filtering is a policy decision separate from how they logged in. A tool can be reachable by any method here and still be withheld from a user who lacks the entitlement.
Several methods often apply to the same tool at once – an app may accept SSO and have its account provisioned and be reachable over LDAP. The usage label records the single richest integration; this section describes the full set of paths available.
