This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
This feature is available in v0.5+
Intro
Warpgate can use arbitrary OpenID Connect (OIDC) providers to authenticate users based on their verified emails.
OIDC providers include, but are not limited to:
- Google Accounts
- Sign in with Apple
- GitLab
- Microsoft Azure
- Okta
Configuration
External host setting (before v0.12)
To use SSO, Warpgate needs to know what its external hostname is. It'll try its best to figure it out based on the client's request, but it's better if you set it explicitly via the top-level external_host
config option:
+ external_host: warpgate.acme.inc
external_host
can include a port as well
Starting with v0.12, Warpgate uses the Host
header to determine the external host.
SSO Providers
Obtaining app credentials from a provider
You'll need to register your Warpgate instance as an "app" (terminology varies per provider) at the provider and obtain a Client ID and a Client secret. You'll need to provide a Redirect URL which - which will be verified by the SSO provider.
The redirect URL for Warpgate is https://<warpgate-external-host>/@warpgate/api/sso/return
.
Okta provides excellent guides on registering an app with various providers:
Adding credentials to the config file
With a Client ID and a Client Secret in hand, you can add these to the Warpgate config file:
external_host: warpgate.acme.inc:8888
+ sso_providers:
+ - name: google
+ label: Google login
+ provider:
+ type: google
+ client_id: 1234...
+ client_secret: ABC...
Microsoft Azure
external_host: warpgate.acme.inc:8888
+ sso_providers:
+ - name: azure
+ provider:
+ type: azure
+ client_id: 123...
+ client_secret: ABC...
+ tenant: XYZ...
Apple (⚠️ v0.6.6+)
external_host: warpgate.acme.inc:8888
+ sso_providers:
+ - name: apple
+ label: Apple ID
+ provider:
+ type: apple
+ team_id: ABC... # your Apple Team ID
+ client_id: com.warpgate.test # your Service ID (not the App ID!)
+ key_id: ABC... # the ID of the key you've created
+ client_secret: ABC... # Base64 encoded contents of the .p8 private key file you've got from Apple
Custom
external_host: warpgate.acme.inc:8888
+ sso_providers:
+ - name: custom
+ label: ACME SSO
+ provider:
+ type: custom
+ client_id: 123...
+ client_secret: ABC...
+ issuer_url: https://sso.acme.inc,
+ scopes: ["email"],
Requiring SSO for a user
Users are linked to their SSO accounts based on their email. If the SSO provider advertises email verification status, Warpgate will require the email to be verified.
To link a user to SSO, click Add SSO
in the credentials section, and then (optionally) set SSO as the only accepted credential type for HTTP connections.
Here, we've also set SSO to be the only allowed login credential for HTTP auth, and have set SSH to use out-of-band web authentication.
In-browser auth
(OOB web authentication) means that Warpgate will send a login link to the SSH client and will wait for the user to authenticate themselves in a browser. The auth requirements will be the same as set for thehttp
protocol.
❯ ssh cwilde:tnt@warpgate.acme.inc -p 2222
----------------------------------------------------------------
Warpgate authentication: please open https://warpgate.acme.inc:8888/@warpgate#/login/31282192-ad29-4fa7-bdc2-5b481d531e58 in your browser
----------------------------------------------------------------
(cwilde:tnt@warpgate.acme.inc) Press Enter when done:
Setting roles via SSO (⚠️ v0.10+)
With custom
type OIDC providers, Warpgate can also sync the user's role memberships when they log in.
For that, your provider must set a warpgate_roles
OIDC claim (a JSON array of role names) either in the ID Token or the UserInfo response. By default, Warpgate will use these names as-is and completely overwrite the user's memberships.
You can also set role_mappings
in the provider's configuration to explicitly map claim values to role names. In this case, only the roles mentioned here will be synced SSO, and the memberships in other roles won't be affected. For example:
- name: oidc-custom
label: Custom SSO
provider:
type: custom
client_id: ...
client_secret: ...
issuer_url: ...
scopes: []
role_mappings:
'QA group': 'qa'
Admins: 'warpgate:admin'