OIDC Login

User-Directory OIDC Login Fails

If your OIDC user login is successful when configured as standalone PrivX directory (OIDC directory type), but login fails when configured as part of other directory type (LDAP or SCIM user directory), one possible reason could be that your OIDC user is not found in user cache.

Possible causes for that include:

1. LDAP or SCIM user has not been imported to PrivX. Check that user is visible in PrivX directory user listing.

2. OIDC user "sub" field does not match the cached user external ID. This can be caused by using custom field names or incorrect attribute mapping.

Some PrivX user directories, like Azure AD and Azure Graph API directory types use Azure "oid" attribute from OIDC idToken to find the imported user from user cache. This works automatically and no attribute mapping needs to be done on PrivX directory settings.
For other directories, like LDAP and SCIM, it's possible to use custom field names for imported users. If that's the case, PrivX needs to know which field to use for matching OIDC subject field.

Also verify your imported PrivX users have valid attributes. Correctly mapped username is not required for successful OIDC login (only matching sub field is required as login happens against OIDC provider. For directories not using OIDC, unique username is required), but having username is recommended for logging purposes and general usability. For example, directory logins using SSH certificate will fail, if user is missing both username and unix username (unix_account) definition.
For imported LDAP users, "uid=principal" attribute mapping is used by default to use LDAP "uid" field contents as username.

If you're using native OIDC directory type and your OIDC server is not returning user's username or email at login, check your "Additional scopes" configuration in PrivX directory settings. By default PrivX uses only "openid" scope. In some cases, using additional scopes like "profile" or "email" is necessary. Check your OIDC provider documentation for more details.
For other directory types, defining openid scopes is not necessary, as your user's username and email are imported separately.
It is enough to receive OIDC subject field which matches the user identifier in cache.

To map custom user identifier field name to OIDC subject field (referred as external_id target attribute), use attributename=external_id -syntax. For example, userPrincipalName=external_id
For SCIM directories, the internal attribute names might be different than protocol attribute names. For example, use dn=external_id to use SCIM userName field.

Note that user's external_id MUST be unique within the directory or login will fail.

PrivX GUI Page doesn't open after OIDC Login

After entering valid OIDC credentials, you encounter errors such as:

• Browser error saying that the page cannot be opened/reached, ERR_CONNECTION_CLOSED.
• Nothing happens.

The issue is also accompanied by similar entries in the Nginx access logs:

"-" 000 0 "-" "-" "-"

This issue may be fixed by increasing the maximum request-header size. To do this, configure Nginx on your PrivX servers as follows:

1. To increase the maximum header size , append the following seetting to /etc/nginx/privx/privx-common.conf:

   • For Nginx versions 1.19.7 and later:

     large_client_header_buffers 4 8k;

   • For earlier Nginx versions:

     http2_max_field_size            8k;

2. Restart Nginx to apply the changes:

   sudo systemctl restart nginx

After increasing the header size, retry OIDC connections to see if the problem has been fixed.