Websites
Last modified on April 2, 2025
A website resource in StrongDM is the combination of an IP/DNS address and authentication information used to connect to a web-based resource, such as a Redash or Grafana dashboard.
When a User or Role is assigned a website resource, that entity inherits the ability to access the resource via a proxy set up on their local device.
Example: Alice wishes to access an internal website, such as a CI tool, which is already set up in StrongDM as a website resource. Alice sets up her StrongDM user, which is then given permission via a role to access the website. She installs the proxy on her laptop, then is able to quickly access the site after connecting to it via the desktop app.
Validation of the token is not strictly necessary since the connection comes through StrongDM (and thus already is authenticated and authorized), but if you wish to manually validate it, you may do so with the VerifyJWT method in the SDKs. Each SDK has a version of this function, which reports whether the given JWT token is valid.
Resource Properties
| Property | Requirement | Description |
|---|---|---|
| Display Name | Required | Meaningful name to display the resource throughout StrongDM; exclude special characters like quotes (") or angle brackets (< or >) |
| Auth Type | Required | Select HTTP, HTTP Basic Auth, or HTTP Custom Auth; find a description for each in the Auth Types section |
| Proxy Cluster | Required | Defaults to “None (use gateways)”; if using proxy clusters, select the appropriate cluster to proxy traffic to this resource |
| Base URL | Required | Base address and port for the website to add as a resource (for example, http://dashboard.strongdm.com:9021) |
| HTTP Subdomain | Required | Unique string to use as your local DNS address (for example, app-prod1 turns into http://app-prod1.production111.sdm.network/); be sure to input URL-safe characters |
| Default Path | Optional | Path that serves as the starting page when accessing the resource, for example, set /_plugins/kibana |
| Healthcheck Path | Optional | Change the healthcheck from the default / to a more specific URL; the path provided should return a healthy status code, such as 200 |
| Headers exclusion | Optional | Headers to exclude from logging; by default, the logs in StrongDM include all of the headers passed to the website |
| Host Override | Optional | Value to overwrite the host header |
| Resource Tags | Optional | Datasource tags consisting of key-value pairs <KEY>=<VALUE> (for example, env=dev) |
Auth Types
- HTTP: This type of connection does not attempt to perform any authentication via StrongDM, so it has no additional fields required. Just make sure your URL is correct and go from there!
- HTTP Basic Auth: This option uses standard HTTP authentication (username/password). Choosing this option exposes two additional fields: Digest Auth User (username) and Digest Auth Password (password).
- HTTP Custom Auth: This option sends custom authentication data using the
Authenticationheader. Once selected the field Authorization Header is exposed.
Proxy Configuration
Once a user has access to a website, they also need to configure their local system proxy. Users can add the following PAC file to their system to accomplish this task: https://app.strongdm.com/proxy.pac.
The PAC file in the link above automatically configures your system to proxy traffic for your websites. For more detailed setup instructions, read Connecting to Websites.
You can find resources and information about the following StrongDM topics in this section:
Headers
StrongDM modifies headers in the following ways:
- Changes are made to the Location header (as with most proxies).
- If the User-Agent header is missing, it is added with a blank value.
- In the case of HTTP (Basic Auth) and HTTP (Custom Auth) resource types, StrongDM adds or modifies the related auth headers.
- The X-Forwarded-User header contains the email of the StrongDM user.
- The X-Sdm-Token header contains a JSON Web Token (JWT) that can be used to verify the user’s authentication.
These headers are modified for internal use, but the information is presented here because there may be some use cases where you may wish to configure or modify your web applications to anticipate or use some of these headers.