PrivX as OIDC Identity Provider
PrivX can act as an OpenID Connect Identity Provider for third party OIDC-relaying parties such as Jenkins, Gitlab, Salesforce, and Amazon Cognito.
To configure OIDC clients for PrivX, navigate to Administration→Deployment→Identity Provider Clients and click Add New Client.
The configurable values:
| Name | User readable name for the identity provider client. |
| Enabled | Defines if this idp client configuration is enabled or not. Disabling the configuration disables the endpoint immediately. |
| Issuer | This field is generated after creating the identity provider for the first time. The issuer address is formed as https://<your_privx_server_endpoint>/oidc/<idp_provider_id>/ where idp_provider_id is generated when saving the idp client configuration for the first time To see authorize and token endpoints (required by some clients), see well-known endpoint information at https://<your_privx_server_endpoint>/oidc/<idp_provider_id>/.well-known/openid-configuration |
| Client identifier (not visible during creation) | ID of the application that asks for authorization. PrivX server will generate this automatically after saving the configuration. |
| Client secret (not visible during creation) | OAuth 2.0 client secret. Required if PKCE is not enabled. |
| Auth Method Enabled | none, client_secret or client_secret_basic. If PKCE is enabled, this may be set to "none" to disable the client-secret check. |
| Code Challenge Method Enabled | Enable PKCE with S256 code_challenge_method (described in RFC 7636). We recommend enabling this setting. |
| Scopes enabled | profile, email, phone, address, offline_access, privx_roles Specifies which claims the client is allowed to use to access user information. The actual scopes used is the intersection between client's claims and PrivX server's scopes. Scope openid is implicitly enabled. Scopes like profile and email are often required to fetch users' username or email information. The offline_access scope allows the client to obtain access tokens that grant access to the Userinfo Endpoint even when the end user is not logged in. The privx_roles scope allows the client to fetch information about the roles the user currently has. |
| Signature algorithm | Token signature algorithm (RFC 7518). Allowed values: - RS256 - RSASSA-PKCS1-v1_5 using SHA256 - RS384 - RSASSA-PKCS1-v1_5 using SHA384 - RS512 - RSASSA-PKCS1-v1_5 using SHA512 - ES256 - ECDSA using P-256 and SHA-256 - ES384 - ECDSA using P-384 and SHA-384 - ES512 - ECDSA using P-521 and SHA-512 - PS256 - RSASSA-PSS using SHA-256 and MGF1 with SHA-256 - PS384 - RSASSA-PSS using SHA-384 and MGF1 with SHA-384 - PS512 - RSASSA-PSS using SHA-512 and MGF1 with SHA-512 |
| Grant Type Refresh Token | Enables refresh_token grant use for the Token Request in the Refresh Token Flow. |
| Auth Method Post | Allow the client to use POST method for client_id/client_secret authentication in addition to HTTP Basic Auth. |
| Default Logout Redirect URI | Default post logout redirect URI to be used, if client calls end_session without defining redirect uri. |
| Allowed Redirect URIs | A list of allowed redirect URIs for Code and Implicit flow. Your callback URI needs to be whitelisted here or the authorization will fail. One URI per line. |
| Allowed Logout Redirect URIs | Allowed logout redirect URIs for end_session requests. One URI per line. |
| Access Token Validity | Access-token-validity period in minutes. Default is 5 minutes. |
| Refresh Token Validity | Refresh-token-validity period in minutes. Default is 480 minutes (8 hours). Users are forced to re-authenticate after the refresh token expires. |
| Attribute mapping | Mappings from user attributes to idToken attributes. By default, PrivX returns users' UUIID in idToken sub field. You can change this by configuring attribute mapping for sub fields. Syntax: For example, use email=sub attribute mapping to return users' email address as user subject in their idTokens' "sub" field. principal=sub returns users' usernames instead. Allowed idToken attribute names: sub, name, preferred_username, family, name, given_name, locale, email, phone_number. |
Jenkins login via PrivX OIDC
Jenkins OIDC config using OpenID plugin
Gitlab login page with "Google OpenID" login button.
Gitlab config page after gitlab user has been paired with PrivX OIDC user.
When SSO is enabled in Administration→Settings→Authentication, users may re-login to 3rd-party apps as long as their SSO session is valid. When enabled, a user's SSO session is created when they log into PrivX or a 3rd-party app.
SSO sessions last as long as GUI sessions. SSO sessions are terminated when they time out or when the user logs out of PrivX. Note that PrivX logins create two sessions when SSO sessions are enabled: one regular PrivX session, and one SSO session. You may review sessions via Monitoring→Sessions.