External authentication and role-based access control¶

Overview
What’s new
Authentication methods (existing)
- Local authentication
- External authentication
Login flows
Session management
Configuring identity providers (administrator only)
- Navigation path
- Configuring an LDAP provider
Custom CA certificates for LDAP/LDAPS authentication
API configuration
Role-Based Access Control (RBAC)
Role mapping (administrator only)
Checking your permissions
- Viewing your permissions
- Understanding access denied responses

Overview ¶

F5 Insight supports external authentication, enabling enterprise customers to integrate with their existing identity infrastructure for centralized user management and secure access control.

Previously, F5 Insight supported only a single local administrator account (username: admin, password: SSH-configured password). With this release, administrators can configure external authentication providers, allowing multiple users to log in using their corporate credentials with role-based access control.

What’s new ¶

Feature	Description
External Authentication	Authenticate users via corporate LDAP or SAML identity providers
Supported LDAP Providers	Open LDAP
Supported SAML Providers	Ping, Okta
Role-Based Access Control (RBAC)	Three predefined roles - Admin, Operator, Viewer - controlling access to features and API endpoints
Role Mapping	Map external identity provider groups to F5 Insight roles

Authentication methods (existing)¶

F5 Insight supports two authentication methods:

Local authentication ¶

Local authentication uses the built-in administrator account created during installation.

Attribute	Details
Username	`admin`
Password	Configured during system setup (SSH password)
Access Level	Full administrator access
Limitation	Single user only; no role differentiation

External authentication ¶

External authentication allows users to log in using credentials managed by a corporate identity provider.

Provider Type	Supported Providers	Protocol	Description
LDAP	Open LDAP	LDAP v3	Directory-based authentication using LDAP credentials
SAML	Ping, Okta	SAML 2.0	Single Sign-On (SSO) authentication via SAML identity providers

Note

Custom identity provider implementations outside of the supported LDAP (Open LDAP) and SAML (Ping, Okta) providers are not supported in this release.

Login flows ¶

Login screen ¶

After an external authentication provider is configured and activated, the F5 Insight login screen displays additional log-in options:

Local Login: Standard username and password fields for the built-in admin account.
External Login: One or more buttons labeled “Sign in with <Provider Name>” for each configured external provider.

The provider name displayed on the login screen corresponds to the name configured by the administrator during provider setup.

LDAP login ¶

Navigate to the F5 Insight login page.
Select Sign in with <LDAP Provider Name> (for example, Log in with <LDAP Provider Name>).
You are redirected to the LDAP credential screen.
Enter your LDAP username and password.
Upon successful authentication, you are redirected to the F5 Insight dashboard with permissions based on your assigned role.

SAML login ¶

Navigate to the F5 Insight login page.
Select Sign in with <SAML Provider Name> (for example, “Log in with Okta” or “log in with Ping”).
You are redirected to an intermediate authentication screen.
On the intermediate screen, select the SAML log-in option again to proceed to the IdP authentication page.
Enter the SAML credentials on the IdP authentication page.
Upon successful authentication, you are redirected to the F5 Insight dashboard with permissions based on your assigned role.

Note

By default, remote authentication uses an IP address for login page links and external auth endpoints. Use f5insight-set-fqdn to set a stable hostname instead. Using an FQDN is recommended for TLS certificate hostname validation, better user experience (friendly login URLs), and stable identity across IP changes. For more information, see Remote Authentication FQDN.

Session management ¶

Behavior	Details
Access Token Expiry	Tokens expire after 5 minutes
Automatic Refresh	Tokens are refreshed automatically in the background. No user action required
Session Timeout	If token refresh fails, you are redirected to the login page
Logout	Select the logout option to end your session

Note

Access tokens are stored in browser memory only and are never persisted to local storage, ensuring enhanced security.

Configuring identity providers (administrator only)¶

Important

You must be logged in as an Admin user to configure identity providers.

Configuring an LDAP provider ¶

Warning

Known Issue: Authentication with Active Directory can only assign a user to a Viewer Role

This is a known limitation in this release. F5 Insight’s LDAP group search currently requires groups to exist under ou=groups,<baseDN>. Directories that don’t use this layout, including Active Directory, resolve no groups, and affected users default to the Viewer role. This issue is scheduled for a fix in future release of F5 Insight.

Log in to F5 Insight as an administrator.
Navigate to Settings ‣ User Administration ‣ SSO Identity Providers.
Select LDAP.
Fill in the required configuration fields:

Field	Description	Required
Provider Name	Display name for the provider (appears on the login screen)	Yes
Server URL	LDAP server hostname or IP address with port (for example, `ldap://ldap.example.com:389` or `ldaps://ldap.example.com:636`)	Yes
Base DN	Base Distinguished Name for user search queries	Yes
Bind DN	Distinguished Name used to authenticate with the LDAP server	Yes
Bind Password	Password for the Bind DN account	Yes
LDAP Attributes	Mapping of LDAP attributes to user properties (for example, mail, username, and so on)	Yes
Userbase DN	User search base DN	Yes
User filters	User lookup attribute key (for example, `uid`); do not use a full LDAP filter expression	Yes
User object	LDAP object class used for user entries	Yes

Select Create to save the configuration and Activate to enable the provider on the screen.

Note

Only one active LDAP and one active OKTA, PING are allowed.

Note

After activation, a “Log in with <Provider Name>” button appears on the login page immediately.

Note

For LDAP configuration, set User filters to uid in the example flow. Do not enter a full LDAP filter string such as (&(objectClass=inetOrgPerson)(uid={0})) in that field.

Note

The LDAP server must be reachable on a standard LDAP port: 389 for LDAP (or LDAP with StartTLS) and 636 for LDAPS. Make sure firewall and network policy rules allow traffic from F5 Insight to the selected port.

Custom CA certificates for LDAP/LDAPS authentication ¶

F5 Insight 1.2.2 lets you use custom Certificate Authority (CA) certificates to secure LDAP authentication. As an administrator, you can:

Upload a CA certificate or CA bundle to the Trust Store.
Select the uploaded CA when you configure an LDAP identity provider.
Validate the LDAP server certificate for LDAPS connections using the selected CA.

Warning

LDAP + StartTLS with a custom CA certificate is not functional for runtime login in this release. Use LDAPS with a custom CA instead. If your environment requires StartTLS, apply the workaround script before you configure the provider. See Known limitations.

Supported LDAP connection types ¶

F5 Insight supports three LDAP connection types. The level of custom CA support differs for each type.

Connection type	Custom CA support	Notes
Plain LDAP	Not required	No TLS is used. A CA certificate is not needed.
LDAPS	Supported	Recommended for custom CA deployments. Uses port 636 by default.
LDAP + StartTLS	Partial	Backend validation works with a custom CA, but runtime login has known limitations. See Known limitations.

Certificate requirements ¶

Before you upload a CA certificate, make sure it meets the following requirements.

File format

The certificate must be PEM encoded.
Accepted file extensions are .pem, .crt, or .cer (as long as the content is PEM format).
If your file is in DER or binary .cer format, convert it to PEM before you upload it.

Certificate chain

Upload the full CA bundle (root and intermediate certificates), not only the LDAP server’s leaf certificate.
If the LDAP server does not send its intermediate certificate chain, include the full chain in your uploaded bundle.

Server certificate matching

The Subject Alternative Name (SAN) in the LDAP server certificate must match the hostname in your LDAP URL.
If you use an IP address in the LDAP URL, the server certificate must include that IP address as an IP SAN.
The LDAP server must present the configured server certificate along with a matching private key.

Note

F5 Insight does not support LDAP mutual TLS or client certificate authentication.

Verify the LDAP server certificate ¶

Before you configure F5 Insight, verify that your LDAP server’s TLS certificate is valid. Run the following OpenSSL command to test the connection:

openssl s_client \
  -connect ldap.example.com:636 \
  -servername ldap.example.com \
  -CAfile ca-bundle.pem \
  -verify_hostname ldap.example.com

Look for this result in the output:

Verify return code: 0 (ok)

If the verification fails, review the custom CA troubleshooting section before you continue.

Configure a custom CA for LDAPS ¶

Use these steps for LDAPS connections. This is the recommended approach for custom CA deployments.

Go to Authentication ‣ Identity Providers.
Select an existing LDAP provider and select Edit, or select Create to add a new one.

The LDAP provider configuration screen.
In the Server URL field, enter the LDAPS URL for your LDAP server.

Use the explicit port in the URL. For example:
```
ldaps://ldap.example.com:636
```
Make sure the StartTLS checkbox is cleared.
In the CA certificate section, select Upload and select your CA certificate file or full CA bundle.
From the Certificate Authority dropdown, select the CA you uploaded.
Select Test Connection to verify that F5 Insight can reach and validate the LDAP server.
Select Save.

The LDAP provider configuration screen with the Save button.
Activate the provider and test an LDAP login to confirm the setup works.

Configure a custom CA for LDAP + StartTLS ¶

Use these steps only if your environment requires StartTLS. For reliable custom CA support, LDAPS is recommended. See Known limitations.

Go to Authentication ‣ Identity Providers.
Select an existing LDAP provider and select Edit, or select Create to add a new one.
In the Server URL field, enter the LDAP URL for your server.

Important

Do not include a port number in the URL. The system defaults to port 389 automatically. Adding a port causes malformed Server Name Indication (SNI) requests during the TLS upgrade.

For example:
```
ldap://ldap.example.com
```
Select the StartTLS checkbox.
In the CA certificate section, select Upload and select your CA certificate file or full CA bundle.
From the Certificate Authority dropdown, select the CA you uploaded.
Select Test Connection to verify that F5 Insight can reach and validate the LDAP server.
Select Save.
Activate the provider and test an LDAP login to confirm the setup works.

Troubleshoot custom CA certificate issues ¶

Use this section to resolve common errors related to custom CA certificates for LDAP.

Error	Cause	Solution
`x509: certificate signed by unknown authority`	The selected CA does not include the certificate that signed your LDAP server’s certificate.	Upload the correct CA certificate or full CA bundle to the Trust Store. Make sure the bundle includes the root and any intermediate CAs in the trust chain.
`hostname mismatch`	The hostname in the LDAP URL does not match any Subject Alternative Name (SAN) entry in the LDAP server certificate.	Update the LDAP URL to use the hostname that appears in the server certificate’s SAN field. If neither hostname is correct, reissue the LDAP server certificate with the correct SAN.
Server presents a default container certificate (for example, `CN=openldap` or `docker-light-baseimage`)	The LDAP server is still using a default container certificate instead of your issued certificate.	Install the issued server certificate and its matching private key on the LDAP server. Restart the LDAP service after you replace the certificate.
`EOF` during LDAPS validation	The LDAP server is closing the TLS connection before the handshake completes. This can happen when the server or an upstream device (such as F5 BIG-IP) requires client certificate authentication.	Check the LDAP server configuration and any TLS profiles on intermediate devices. Make sure client certificate authentication is not required, because F5 Insight does not support mutual TLS for LDAP connections.
StartTLS connection refused or SNI errors	The provider URL contains a port number (for example, `ldap://ldap.example.com:389`). Adding a port to a StartTLS URL causes malformed Server Name Indication (SNI) requests during the TLS upgrade.	Remove the port number from the provider URL. Use only the hostname — for example, `ldap://ldap.example.com`. The system defaults to port 389 automatically.

Workaround: apply a custom CA for StartTLS ¶

workaround.sh

#!/bin/bash
set -e

# --- Configuration Variables ---
NAMESPACE="f5-insight"
DEPLOYMENT="f5-insight-zitadel"
CONFIGMAP_NAME="ldap-custom-ca-bundle"
CERT_MOUNT_PATH="/etc/ssl/ldap-custom-certs"
CERT_ENV_VAL="/etc/ssl/certs:/etc/ssl/ldap-custom-certs"

# --- Input Validation ---
if [ -z "$1" ]; then
  echo "Error: Missing certificate file."
  echo "Usage: ./apply-zitadel-starttls-workaround.sh <path-to-custom-ca.crt>"
  exit 1
fi

CA_FILE="$1"

if [ ! -f "$CA_FILE" ]; then
  echo "Error: File '$CA_FILE' not found."
  exit 1
fi

echo "============================================================"
echo "Applying ZITADEL StartTLS Custom CA Workaround"
echo "Target Namespace: $NAMESPACE"
echo "Certificate File: $CA_FILE"
echo "============================================================"

# Step 1: Create or Update the ConfigMap
echo "[1/4] Injecting certificate into ConfigMap: $CONFIGMAP_NAME..."
kubectl create configmap $CONFIGMAP_NAME \
  -n $NAMESPACE \
  --from-file=ldap-custom-ca.crt="$CA_FILE" \
  --dry-run=client -o yaml | kubectl apply -f -

# Step 2: Patch the ZITADEL Deployment
echo "[2/4] Patching ZITADEL deployment to mount the certificate..."
NOW=$(date +%s)

kubectl patch deployment $DEPLOYMENT \
  -n $NAMESPACE \
  --type strategic \
  -p "{
    \"spec\": {
      \"template\": {
        \"metadata\": {
          \"annotations\": {
            \"f5insight.io/ldap-ca-workaround-restarted-at\": \"$NOW\"
          }
        },
        \"spec\": {
          \"containers\": [
            {
              \"name\": \"zitadel\",
              \"env\": [
                {
                  \"name\": \"SSL_CERT_DIR\",
                  \"value\": \"$CERT_ENV_VAL\"
                }
              ],
              \"volumeMounts\": [
                {
                  \"name\": \"$CONFIGMAP_NAME\",
                  \"mountPath\": \"$CERT_MOUNT_PATH\",
                  \"readOnly\": true
                }
              ]
            }
          ],
          \"volumes\": [
            {
              \"name\": \"$CONFIGMAP_NAME\",
              \"configMap\": {
                \"name\": \"$CONFIGMAP_NAME\"
              }
            }
          ]
        }
      }
    }
  }"

# Step 3: Wait for the rollout to complete
echo "[3/4] Waiting for ZITADEL pods to restart..."
kubectl rollout status deployment/$DEPLOYMENT -n $NAMESPACE --timeout=180s

echo "[4/4] Done! The workaround has been successfully applied."
echo "============================================================"
echo "Next Steps:"
echo "In the F5 Insight UI, configure your LDAP Provider:"
echo " - Server: ldap://<YOUR_LDAP_HOSTNAME> (Do NOT use custom ports)"
echo " - StartTLS: Checked"
echo " - CA: Select the same Custom CA uploaded to the Trust Store"
echo "============================================================"

Apply the workaround ¶

Important

Complete this workaround after you upload the CA certificate and save the LDAP provider configuration in the F5 Insight UI.

Connect to the F5 Insight virtual machine (VM) using SSH.
Create the workaround script:
```
nano workaround.sh
```
Paste the script content into the editor, then save and close the file.
Make the script executable:
```
chmod +x workaround.sh
```
Copy the CA certificate from your LDAP server to the F5 Insight VM.

Use scp to transfer the file. For example:
```
scp <username>@<ldap-server-ip>:<path-to-certificate>/custom-ca.crt ./custom-ca.crt
```
Alternatively, create a new file on the VM and paste the certificate content directly.
Run the workaround script with the path to your CA certificate:
```
sudo ./workaround.sh ./custom-ca.crt
```
Test an LDAP login to confirm that the custom CA is now used for StartTLS connections.

Known limitations for custom CA ¶

Updating a CA on an existing LDAP provider: When you update the CA certificate on an existing LDAP provider, the new CA might not take effect for runtime login. The system can save the updated certificate in the provider configuration, but login requests might continue to use the previous CA.

If a CA update does not take effect after you save the provider, delete the existing LDAP provider and create a new one with the updated CA certificate.
LDAP + StartTLS with custom CA: Backend validation can use the selected custom CA, but runtime login has known limitations with the current identity management component. For reliable custom CA support, use LDAPS instead of LDAP + StartTLS. If your environment requires StartTLS, apply the workaround script.

LDAP configuration notes and sample LDIF expectations ¶

The following values represent the expected LDAP entry patterns used by OpenLDAP deployments similar to the sample data used for F5 Insight validation.

Expected user object classes and attributes¶

User entries are expected under a people container such as ou=People,dc=ldap,dc=example,dc=com with object classes:

person
organizationalPerson
inetOrgPerson

Common user attributes expected by provider mapping:

uid: login identifier (for example, adminuser)
mail: email address
cn: display name
givenName: first name
sn: last name
userPassword: LDAP bind password hash

Expected group object classes and attributes¶

Group entries are expected under a groups container such as ou=Groups,dc=ldap,dc=example,dc=com.

Important

Known issue: F5 Insight’s LDAP group search currently requires groups to exist under ou=groups,<baseDN>. Directories that don’t use this layout, including Active Directory, resolve no groups, and affected users default to the Viewer role.

Dual-compatible group entries can include both:

groupOfUniqueNames with uniqueMember DN values
posixGroup with gidNumber and memberUid values

This supports both DN-based and POSIX username-based membership lookup.

Sample LDIF entry shapes¶

dn: uid=adminuser,ou=People,dc=ldap,dc=example,dc=com
 objectClass: person
 objectClass: organizationalPerson
 objectClass: inetOrgPerson
 uid: adminuser
 mail: adminuser@ldap.example.com
 cn: Addy Ministrator
 givenName: Addy
 sn: Ministrator
 userPassword: {SSHA}<hash>

dn: cn=admin,ou=Groups,dc=ldap,dc=example,dc=com
 objectClass: groupOfUniqueNames
 objectClass: posixGroup
 cn: admin
 gidNumber: 10002
 uniqueMember: uid=adminuser,ou=People,dc=ldap,dc=example,dc=com
 memberUid: adminuser

Associated OpenLDAP search commands¶

Use these commands to validate expected directory content and group mapping behavior.

# Base user lookup by uid
ldapsearch -x -H ldap://localhost \
 -b ou=People,dc=ldap,dc=example,dc=com \
 -D "cn=admin,dc=ldap,dc=example,dc=com" -w <password> \
  "(uid=adminuser)" dn uid mail cn givenName sn

# Inspect one group and verify dual object classes and membership attributes
ldapsearch -x -H ldap://localhost \
 -b ou=Groups,dc=ldap,dc=example,dc=com \
 -D "cn=admin,dc=ldap,dc=example,dc=com" -w <password> \
  "(cn=admin)" dn objectClass gidNumber uniqueMember memberUid

# POSIX-style group membership query
ldapsearch -x -H ldap://localhost \
 -b ou=Groups,dc=ldap,dc=example,dc=com \
 -D "cn=admin,dc=ldap,dc=example,dc=com" -w <password> \
  "(memberUid=adminuser)" dn cn

# Dual-mode membership query (DN-based OR POSIX-style)
ldapsearch -x -H ldap://localhost \
 -b ou=Groups,dc=ldap,dc=example,dc=com \
 -D "cn=admin,dc=ldap,dc=example,dc=com" -w <password> \
 "(|(uniqueMember=uid=adminuser,ou=People,dc=ldap,dc=example,dc=com)(memberUid=adminuser))" dn cn

Recommended LDAP provider mapping values¶

User search base: ou=People,dc=ldap,dc=example,dc=com
User object class: inetOrgPerson
Username attribute: uid
Email attribute: mail
Display name attribute: cn
First name attribute: givenName
Last name attribute: sn

Configuring a SAML provider ¶

Log in to F5 Insight as an administrator.
Navigate to Settings ‣ User Administration ‣ SSO Identity Providers.
Select SAML.
Fill in the required configuration fields:

Field	Description	Required
Name	Display name for the provider (appears on the login screen)	Yes
Metadata XML / URL	SAML metadata obtained from the IdP (Ping or Okta)	Yes
Binding	SAML binding type: POST or Redirect	Yes

Select Save to store the configuration.
Select Create to enable the provider on the login screen.

Note

The administrator must first configure F5 Insight as a trusted Service Provider on the IdP (Ping or Okta), obtain the SAML metadata XML or URL, and then paste it into the F5 Insight configuration.

Part 2: Configure Okta ¶

Initial F5 Insight for Okta ¶

Log in to F5 Insight as an administrator.
Navigate to System Management -> User Administration -> SSO/Identity Providers.
Select SAML from the available providers.
Provide a name, metadata XML or metadata URL, and binding.

Note

We recommend to create the Okta application before starting this step. When initially creating the Okta SAML 2.0 application, the IAM administrator must supply placeholder values for Single Sign-On URL and Audience URI (SP Entity ID), for example https://<insight_fqdn_or_ip>. This allows working Metadata URL or XML values from the Okta app to be entered during F5 Insight provider setup.

Example App Values

Property	Value
App Type	SAML 2.0
App Name	F5 Insight
Single sign-on URL	`https://<f5insight_fqdn_or_ip>`
Audience URI (SP Entity ID)	`https://<f5insight_fqdn_or_ip>`
Name Format	EmailAddress
Application Username	Email

Save the provider.
Select Edit for the new provider and expand the SAML Metadata section.
Note the following values from F5 Insight:
- SAML Metadata URL (Audience URI / SP Entity ID)
- SAML ACS Intent API URL (Single sign-on URL)

Update the Okta application ¶

Log in to the Okta Admin Console and navigate to Applications.
Select the previously created application.
Configure SAML settings:
- Single Sign-On URL: Paste the SAML ACS Intent API URL copied from F5 Insight.
- Audience URI (SP Entity ID): Paste the SAML Metadata URL copied from F5 Insight.
Go to Attribute Statements and add the required user attributes (set format to Basic).

Name	Value
email	`user.email`
lastname	`user.lastName`
firstname	`user.firstName`
username	`user.email`
displayname	`user.displayName`

Add a Group Attribute Statement:
- Name: groups
- Name format: Unspecified
- Filter: Select Matches regex and input .*
Save the application.

Managing identity providers ¶

Action	Steps
View Providers	Navigate to Settings > User Administration > SSO Identity Providers to view all configured providers
Activate Provider	Select Activate on a configured provider to enable it on the login page
Deactivate Provider	Select Deactivate to remove the provider from the login page without deleting the configuration
Edit Provider	Select the provider and update the configuration fields, then select Save Changes
Delete Provider	Select the provider and select Delete to remove the configuration
Test Provider	Use the Validate option to test the provider configuration before activating

Note

Editing an LDAP provider: LDAP edit configuration requires a password to enable the test connection button.

Note

The Test Connection option is available for LDAP providers only. It validates the LDAP connection and retrieves the available LDAP groups.

API configuration ¶

Identity providers can also be managed using the F5 Insight REST API.

Identity Provider Endpoints

Method	Endpoint	Description
`GET`	`/auth/identity-providers`	List all configured identity providers
`POST`	`/auth/identity-providers/ldap`	Create a new LDAP provider
`POST`	`/auth/identity-providers/saml`	Create a new SAML provider
`GET`	`/auth/identity-providers/{id}`	Get details of a specific provider
`PUT`	`/auth/identity-providers/ldap/{id}`	Update an LDAP provider
`PUT`	`/auth/identity-providers/saml/{id}`	Update a SAML provider
`DELETE`	`/auth/identity-providers/{id}`	Delete a provider
`POST`	`/auth/identity-providers/{id}/activate`	Activate a provider
`POST`	`/auth/identity-providers/{id}/deactivate`	Deactivate a provider
`POST`	`/auth/identity-providers/validate`	Test a provider configuration

Note

Refer to the F5 Insight API Documentation for detailed request/response schemas, payload examples, and authentication requirements.

Role-Based Access Control (RBAC)¶

F5 Insight enforces Role-Based Access Control (RBAC) to manage what each user can access and perform within the platform.

Predefined roles ¶

Role	Description	Access Level
Admin	Full system access including user management, device configuration, and all settings	Full read/write access to all features and API endpoints
Operator	Device configuration and troubleshooting	Read/write access to devices, provisioning, telemetry, and system management. No access to User Administration
Viewer	Read-only access for monitoring and observation	View-only access to dashboards, devices, and configurations. Cannot add, edit, or delete resources

Role permissions matrix ¶

Admin Role - Full Access

Feature Area	GET	POST	PUT/PATCH	DELETE
Device Management	Yes	Yes	Yes	Yes
Telemetry	Yes	Yes	Yes	Yes
AI Integrations	Yes	Yes	Yes	Yes
Provisioning	Yes	Yes	Yes	Yes
System Management	Yes	Yes	Yes	Yes
License Management	Yes	Yes	Yes	Yes
User Management	Yes	Yes	Yes	Yes
Dashboards	Yes	Yes
Audit Console	Yes	Yes
Chat Management	Yes	Yes	Yes	Yes

Operator Role - Operational Access

Feature Area	GET	POST	PUT/PATCH	DELETE
Device Management	Yes	Yes	Yes	No
Telemetry	Yes	Yes	Yes	No
AI Integrations	Yes	Yes	PUT only	No
Provisioning	Yes	Yes	PUT only	No
System Management	Yes	Yes	No	No
License Management	No	No	No	No
User Management	No	No	No	No
Dashboards	Yes	Yes
Audit Console	No	No	No	No
Chat Management	Yes	Yes	Yes	No

Viewer Role - Read-Only Access

Feature Area	GET	POST	PUT/PATCH	DELETE
Device Management	Yes	No	No	No
Telemetry	Yes	No	No	No
AI Integrations	Yes	No	No	No
Provisioning	Yes	No	No	No
System Management	Yes	No	No	No
License Management	Yes	No	No	No
User Management	No	No	No	No
Dashboards	Yes	Yes
Audit Console	No	No	No	No
Chat Management	No	No	No	No

Default role assignment ¶

Scenario	Assigned Role
Local admin user	Always Admin
External user with a matching group attribute	Role as per group-to-role mapping (Admin, Operator, or Viewer)
External user with no group attribute configured	Defaults to Viewer

UI access by role ¶

Feature / Section	Admin	Operator	Viewer
Dashboards	View - Yes	View - Yes	View - Yes
Devices - View	Yes	Yes	Yes
Devices - Add/Edit/Delete	Yes	Add/Edit - Yes, Delete - No	No
User Administration	Yes	No	No
System Settings	Yes	Yes (limited)	View-only / limited
AI Chat	Yes	Yes	No / view-only if UI allows history
F5 Insight Upgrade	Yes	No	No

Role mapping (administrator only)¶

Role mapping determines which F5 Insight role an external user receives upon login. Roles are assigned based on group attributes configured on the LDAP or SAML identity provider.

Navigate to Settings > User Administration > Role > Role Mapping

How role mapping works ¶

The administrator configures a group attribute on the LDAP or SAML server for each user or user group.
When an external user logs in to F5 Insight, the system reads the group attribute from the authentication response.
F5 Insight maps the attribute value to the corresponding role (Admin, Operator, or Viewer).
The user is granted access based on the mapped role.
If no matching group attribute is found, the user is assigned the Viewer role by default.

Configuring role mapping ¶

Log in to F5 Insight as an administrator.
Navigate to Settings > User Administration > Role > Role Mapping.
Select the configured identity provider (LDAP or SAML).
Specify the group attribute name that the IdP uses to indicate the user’s role.
Map the attribute values to F5 Insight roles:

IdP Group Attribute Value	F5 Insight Role
(configured by admin, example, `f5-admin`)	Admin
(configured by admin, example, `f5-operator`)	Operator
(configured by admin, example, `f5-viewer`)	Viewer
(no attribute or unmatched value)	Viewer (default)

Select Save.

Example - LDAP role mapping ¶

LDAP User	Group Attribute Value	F5 Insight Role	Access Level
`john.smith`	`f5-admin`	Admin	Full access including User Administration
`jane.doe`	`f5-operator`	Operator	Operational access, no User Administration
`bob.wilson`	`f5-viewer`	Viewer	Read-only access
`new.user`	(not configured)	Viewer (default)	Read-only access

Example - SAML role mapping (Okta / Ping)¶

SAML User	Group Attribute in Assertion	F5 Insight Role
`admin@company.com`	`admins`	Admin
`operator@company.com`	`operators`	Operator
`user@company.com`	(no group attribute)	Viewer (default)

Modifying or deleting role mappings ¶

Action	Steps	Impact
Modify Mapping	Navigate to Role Mapping, update the group attribute or role assignment, select Save.	Changes take effect on the user’s next login
Delete Mapping	Select the mapping, select Delete Mapping	Users previously assigned via this mapping default to Viewer on their next login

Role mapping API endpoints ¶

In this release, roles are read-only: GET /auth/roles and GET /auth/roles/{role_id}. No create role, update role, or edit permissions APIs.

Method	Endpoint	Description
`GET`	`/auth/roles`	List all available roles
`POST`	`/auth/roles`	Create a custom role (not available in this release)
`GET`	`/auth/roles/{role_id}`	Get role details and permissions
`PUT`	`/auth/roles/{role_id}`	Update a role
`PUT`	`/auth/roles/{role_id}/permissions`	Update role permissions

Checking your permissions ¶

Any authenticated user can check their current permissions using the UI or API.

Viewing your permissions ¶

Your assigned role and permissions are visible in the UI based on the features and actions available to you.

Use the following API endpoints to programmatically check your permissions:

Method	Endpoint	Description
`GET`	`/auth/me/permissions`	View your current role and permissions
`POST`	`/auth/permissions/check`	Check if you have permission for a specific action

Understanding access denied responses ¶

HTTP Status Code	Meaning	Action
401 Unauthorized	Your session has expired or your token is invalid	Log in again
403 Forbidden	You do not have permission to perform this action	Contact your administrator to request the appropriate role

Previous Next