Getting Started with OIDC
Overview
We highly recommend using Open ID Connect (OIDC) as the preferred authentication method for the F5 NGINX Management Suite. OIDC offers several advantages, including a Single Sign-On (SSO) experience for users and simplified user management for administrators through the use of user groups. OIDC allows for easy scalability and streamlined administration of user access.
NGINX Management Suite’s implementation of OpenID Connect (OIDC) is designed to work with any Identity Provider (IdP) that supports the OIDC protocol. The instructions provided below are general and can be applied to any IdP.
Do you need to configure a specific IdP?
To learn how to configure OpenID Connect (OIDC) with a specific identity provider, refer to the linked topics in the Set Up Specific IdPs for OIDC section at the bottom of this page.
Create Roles and User Groups in NGINX Management Suite
When using OIDC for authentication, administrators don’t need to create and manage users in NGINX Management Suite. Instead, they can make user groups in NGINX Management Suite that match groups in their Identity Provider. The roles assigned to the user group set the access level and permissions for users according to their group membership. Users from the Identity Provider who aren’t in a group with an assigned role won’t have access to NGINX Management Suite.
To grant users access using OIDC, simply follow these steps:
- Create a role in NGINX Management Suite,
- Create a user group and assign a role to it. Important: The group name must exactly match a group name in your IdP.
- Set up OIDC.
Create a Role
Roles within NGINX Management Suite are a critical component of role-based access control (RBAC). By defining roles, you specify access levels and permissions for different user groups that map to groups in your Identity Provider (IdP).
NGINX Management Suite comes pre-configured with an administrator role called admin
. Additional roles can be created as needed.
The admin
user or any user with CREATE
permission for the User Management feature can create a role.
Here’s how to create a role and set its permissions:
-
In a web browser, go to the FQDN for your NGINX Management Suite host and log in.
-
Select the Settings (gear) icon in the upper-right corner.
-
Select Roles from the left navigation menu.
-
Select Create.
-
On the Create Role form, provide the following details:
- Name: The name to use for the role.
- Display name: An optional, user-friendly name to show for the role.
- Description: An optional, brief description of what the role is.
-
To add permissions:
-
Select Add Permission.
-
Choose the NGINX Management Suite module you’re creating a permission for from the Module list.
-
Select the feature you’re granting permission for from the Feature list. To learn more about features, refer to Getting Started with RBAC.
-
Select Add Additional Access to add a CRUD (Create, Read, Update, Delete) access level.
- Choose the access level(s) you want to grant from the Access list.
-
Select Save.
-
-
Repeat step 6 if you need to add more permissions for other features.
-
When you’ve added all the necessary permissions, select Save to create the role.
Example Scenario
Imagine you need to create an “app-developer” role. This role permits users to create and edit applications without allowing them to delete or perform administrative tasks. You would name the role ‘app-developer,’ select one or more features, and grant permissions that align with the requirements of application development, avoiding features and permissions that enable deletion or other administrative functions.
Next Steps
After creating a role, you’ll want to assign it to a user group within NGINX Management Suite that matches a group in your IdP. Proceed to the Create a User Group with an Assigned Role section for detailed instructions.
Create a User Group with an Assigned Role
Group names must match with your IdP
To ensure that NGINX Management Suite and your Identity Provider (IdP) work together seamlessly, group names must exactly match between the two systems. If the group names do not correspond, the OIDC integration will not work, preventing users from accessing the NGINX Management Suite. For instance, if you have a group named “app-developers” in your IdP, you must create a user group named “app-developers” in NGINX Management Suite. The group claim must also be part of the token your IdP generates. For guidance on how to add group claims, refer to your IdP’s documentation.
Users from an external identity provider can’t be assigned roles directly in NGINX Management Suite, but they inherit roles through group memberships.
Here’s how to create a user group and assign roles to it:
-
In a web browser, go to the FQDN for your NGINX Management Suite host and log in.
-
Select the Settings (gear) icon in the upper-right corner.
-
From the left navigation menu, select User Groups.
-
Select Create.
-
In the Create Group form, provide information for the group:
-
(Required) Group Name: The name or Object ID of the group. It’s essential to carefully follow these guidelines:
- The value must exactly match the group name or Object ID used in the identity provider.
- A group can be linked to only one identity provider.
- You must add a group claim to your token within your identity provider.
-
Display Name: Enter a friendly name for the group.
-
Description: Provide a brief summary of the group.
-
-
(Required) Choose one or more roles from the Roles list to assign to the group.
Important:
To ensure full access to the NGINX Management Suite platform, you must assign theadmin
role to at least one user group. This role grants users comprehensive privileges and permissions within the platform. -
Select Save to create the group.
Example Scenario
Imagine you’ve created a role called “app-developer” that lets people develop, create, and modify applications, but not delete them or perform administrative tasks. You want this role to correspond to a group in your IdP named “app-developers.”
In this case, you’d select the “app-developer” role when creating the “app-developers” user group in NGINX Management Suite. Users from the Identity Provider who belong to the “app-developers” group will then inherit the “app-developer” role and the associated permissions in NGINX Management Suite.
Next Steps
Now that you have created a user group and assigned a role in NGINX Management Suite, continue to the Configure OIDC section of this document. These instructions will help you complete the integration with your Identity Provider and ensure your user groups and permissions work as expected.
Configure OIDC
Before You Begin
Warning:
Before switching from Basic Authentication to OIDC, make sure to add at least one admin user to your identity provider. Failure to do so can result in admin users being locked out of NGINX Management Suite. If this occurs, you can restore access by reverting back to Basic Authentication.
When you configure OIDC authentication for NGINX Management Suite, Basic Authentication will be disabled for all users, including the default admin
user. To ensure uninterrupted access, you need to create a user group in NGINX Management Suite that corresponds to a group in your Identity Provider (IdP) and assign the appropriate roles.
- Follow the instructions above to grant users access before proceeding.
Requirements
The following requirements must be met before you can use OIDC with NGINX Management Suite:
-
Install Instance Manager on a server that also has NGINX Plus R21 or a newer version installed. Make sure the server hosting NGINX Plus has a fully qualified domain name (FQDN).
-
Install the NGINX JavaScript module (njs) on the same server as Instance Manager. This module is necessary for managing communications between NGINX Plus and the identity provider.
-
Configure an Identity Provider (IdP) to provide authentication services. This involves setting up the necessary authentication policies, scopes, and client credentials within your IdP.
Enable OIDC
To enable OIDC functionality, you must update the placeholder default values in the OIDC configuration file (openid_configuration.conf
). Follow these steps:
-
Open the OIDC configuration file
/etc/nms/nginx/oidc/openid_configuration.conf
using a text editor and update the default placeholder values with the relevant information for your identity provider. (To learn more about the variables, refer to the OIDC Settings below.) Save the changes. -
Using a text editor, open the
/etc/nginx/conf.d/nms-http.conf
configuration file and uncomment the OIDC settings starting with#OIDC
. Comment out the Basic Authentication settings. Save the changes. -
Run the command
sudo nginx -t
to validate the configuration and ensure there are no errors. -
Finally, reload NGINX and apply the new configuration by running the command
sudo nginx -s reload
.
OIDC Configuration Values
Select the links below to view the OIDC configuration values and descriptions.
Metadata from Well-Known Endpoints
Variable | Description |
---|---|
$oidc_authz_endpoint | URL of the IdP’s OAuth 2.0 Authorization endpoint. |
$oidc_jwt_keyfile | URL of the IdP’s JSON Web Key Set (JWKS) document. |
$oidc_logout_endpoint | URL of the IdP’s end_session endpoint. |
$oidc_token_endpoint | URL of the IdP’s OAuth 2.0 Token endpoint. |
$oidc_userinfo_endpoint | URL of the IdP’s UserInfo endpoint. |
$oidc_host | URL of the IdP’s application. For example, https://{my-app}.okta.com . |
$oidc_scopes | List of the OAuth 2.0 scope values that this server supports. For example, openid+profile+email+offline_access |
Custom Configuration for Well-Known Endpoints
Variable | Description |
---|---|
Variable |
Description |
$oidc_authz_path_params_enable |
|
$oidc_authz_path_params | Use for when $oidc_authz_path_params_enable is enabled. Example:
|
$oidc_authz_query_params_enable |
|
$oidc_authz_query_params | Use for when $oidc_authz_query_params_enable is enabled. Example:
|
$oidc_logout_path_params_enable |
|
$oidc_logout_path_params | Use for when $oidc_logout_path_params_enable is enabled. Example:
|
$oidc_logout_query_params_enable |
|
$oidc_logout_query_params | Use for when $oidc_logout_query_params_enable is enabled. Example:
|
$oidc_token_path_params_enable |
|
$oidc_token_path_params | Use for when $oidc_token_path_params_enable is enabled. Example:
|
$oidc_token_query_params_enable |
|
$oidc_token_query_params | Use for when $oidc_token_query_params_enable is enabled. Example:
|
Advanced Configuration Options
Variable | Description |
---|---|
$oidc_client | IdP’s client ID, which is a public identifier for the client that is required for all OAuth flows. |
$oidc_client_secret | IdP’s client secret, which is used by the client to exchange an authorization code for a token. This should be an empty value with "" when PKCE is enabled. |
$oidc_hmac_key | HMAC (Keyed-Hash Message Authentication Code) is a cryptographic technique that combines a hash function with a secret key to verify the integrity and authenticity of a message or data. The HMAC should be unique for every NGINX instance and cluster. |
$oidc_logout_redirect | URI to be redirected to after successfully logging out from the IdP. This should be configured in your IdP. |
$oidc_pkce_enable | PKCE (Proof Key for Code Exchange) is a security extension for OAuth 2.0 that provides additional protection for public clients, such as mobile devices or single-page apps. Its purpose is to prevent a malicious program from intercepting the authorization code during the authorization process.1 : Enable PKCE 0 : Disable PKCE |
$oidc_app_name | IdP’s application name. |
Set Up Specific IdPs for OIDC
Select from the following options to set up OIDC for a specific identity provider: