What you'll learn
- →Understand how identities are used in the StrongDM network
- →Understand how credentials are handled and protected
- →Explain the role that Identity Providers (IdP) play in authentication
- →Explain the role that secret stores play in authentication
How Proxies Work
Proxies connect to resources on behalf of the user. Because a resource needs to verify that a requester is authorized, it typically checks credentials (e.g., username & password). When a proxy is involved, the proxy must possess the credentials so the resource will accept requests on the user's behalf.
In StrongDM, the proxy network consists of the StrongDM client and a Gateway / Relay. The user sends traffic through the client; the Gateway/Relay logs on to the resource and forwards traffic. The control plane handles routing.
- User → StrongDM client: The user presents credentials to log on to the StrongDM client.
- Gateway/Relay → Resource: The Gateway/Relay uses its own credentials to connect to the resource. From the resource's perspective, it is the Gateway/Relay—not the user—that is logging in.
Flow: User → Resource
Click each step to see what happens at that stage.
StrongDM client
details from client
resource
resource
Logging in identifies the user to the StrongDM network. User identity is associated with one or more Roles, which determine which resources the client can access. In a properly-configured environment, no resources appear by default (Zero Standing Privileges).
After access is approved, the resource appears in the StrongDM client UI (e.g.,
127.0.0.1:10006). Users can use any compatible tool (SSH client, DB client, browser) to connect using that address. Access requests go through the Catalog at Access → Request Access → Catalog.
StrongDM uses a proprietary routing protocol in the control plane to find the optimal route from the client to the Gateway/Relay to the resource. Roles define access; Policies (if enabled) add an additional security layer governing what a user can do. The Gateway/Relay uses leased credentials or identity aliases for the last-mile hop.
Once connected, traffic flows to the resource. StrongDM continues monitoring via session logs (SSH, RDP, Queries, etc.) uploaded to the control plane. PBAC (Policy-Based Action Controls) can inspect instructions/data in transit. Critically, future traffic is only permitted if previous session logs were successfully uploaded.
Identities on the StrongDM Network
Gateways and Relays that proxy traffic to resources. Identified by tokens generated at creation time. The token is tied to the specific network component.
Identities that need access to resources; log on via the StrongDM client. User identities are not tied to a specific client machine—privileges are portable and follow the user across any client they log on to.
Unlike Nodes, the StrongDM client does not require token generation during installation. The privileges assigned to a client are entirely determined by who is logged in at any given moment.
User Identities
Created directly in StrongDM. Requires a unique email address on the tenant plus first/last name. Native users are password-protected but can gain additional security through 3rd-party integrations:
- Identity Provider (IdP) / SSO
- Multi-Factor Authentication (MFA)
Created via an external identity management system and synced with StrongDM via SCIM/SAML. Key characteristics:
- Cannot be modified from within StrongDM—changes are made at the source system
- No duplication of user details; the external system is the source of truth
- Access to resources is granted via Roles, same as native users
| Property | Native User | Provisioned User |
|---|---|---|
| Created in | StrongDM Admin UI | External identity system |
| Edited in | StrongDM Admin UI | External system (synced) |
| Authentication | SDM password + optional IdP/MFA | Via external IdP |
| Resource access | Via Roles | Via Roles (same) |
Service Accounts
Service accounts support business-critical programs and processes that run continuously—websites, databases, automation scripts. Unlike human users, they cannot interactively authenticate. Their credentials must be widely known to the applications that interact with them.
Because service account credentials are widely shared and carry high-level privileges, they are prime targets for hackers. StrongDM helps mitigate this risk by managing and controlling access to these accounts.
Service accounts authenticate to the StrongDM control plane using admin tokens. These tokens are generated at account creation time. Copy and store securely—they cannot be retrieved later.
Since service accounts can't interactively authenticate, StrongDM offers Auto-Connect (standing access). This is disabled by default in keeping with Zero Standing Privileges best practices.
Integrating with Identity Providers (IdPs)
When an Identity Provider is enabled, users receive an additional validation step after entering their StrongDM username and password. They are redirected to validate their identity through the IdP (e.g., "Log in with Google"). This supports both SSO and user provisioning.
Configure at Settings → User Management → Single Sign-On in the Admin UI. IdP applies to both users and administrators. To prevent lockout during IdP outages, you can allow specific non-SSO users as exceptions.
Multi-Factor Authentication (MFA)
Protects logons to the Admin UI and StrongDM client. Users must have a registered MFA device. If SSO is already enabled, it takes precedence and MFA applies only to policies.
When StrongDM policies are enabled, MFA can be configured as a requirement under the "With" statement in policy rules—triggered by specific resources, actions, or contextual attributes (location, device trust).
3rd-party provider requiring a full Duo environment setup.
3rd-party provider requiring an Okta environment setup.
Built-in StrongDM feature. No extra environment needed. Works with Google Authenticator, Authy, etc.
If SSO is already enabled, it takes precedence over MFA for console logons. In that scenario, MFA is only available for use within Policies.
| Scenario | What it does |
|---|---|
| Specific resource access | Allow dev access to non-critical resources without MFA, but require MFA for production |
| Data mutation actions | View Postgres data freely, but require MFA for DELETE or UPDATE operations |
| Geographic access | Block users outside North America by default, but allow them if they pass MFA |
| Device trust | Require MFA when connecting from untrusted hosts (kiosks, shared machines) |
Navigate to Settings → Security in the StrongDM console. Select your provider (Duo, Okta, or TOTP) and save. Users will be warned they must enroll a device before they can log in again.
Leased Credentials & Identity Aliases
StrongDM Gateways/Relays inject credentials during the "last-mile" hop to the resource. Sensitive credentials are never accessible to users and never transferred in plaintext. Credentials are unlocked only when a cryptographically valid proxy instance requests decryption on behalf of a cryptographically valid user session—neither alone is sufficient.
User
Client
Relay
injects creds ↓
The Gateway/Relay uses the credentials configured when the resource was added to StrongDM (stored in a Secret Store). All connections from the Gateway/Relay use this shared identity.
Logs on the resource host reflect the leased (shared) identity, not the individual user's StrongDM identity. StrongDM's own session logs, however, still track the individual user.
Identity Aliases authenticate to the resource using the user's own credentials. Actions are attributed to the individual alias—providing per-user auditability at the resource level.
- Configured per user; each user can have multiple aliases
- Resources using Identity Aliases specify an Identity Set
- Does not use a Secret Store
| Property | Credential Leasing | Identity Aliases |
|---|---|---|
| Who logs in to resource | Shared service account | User's individual alias |
| Resource log attribution | Shared identity | Individual alias |
| Uses Secret Store | Yes | No |
| Resource types | Most resource types | Specific types only (SSH cert, RDP cert, K8s, AWS) |