Managing Users in SL1 PowerFlow

 

This section describes how to configure authentication for PowerFlow to allow access to multiple users with a variety of roles and permissions.

This section also describes how to use the Admin Panel page () of the PowerFlow user interface to manage user group access to the PowerFlow user interface. Only users with the Administrator role for the PowerFlow system can edit this page.

Configuring Authentication with PowerFlow

SL1 PowerFlow supports the following authentication methods:

• Local Authentication. The same local Administrator user (isadmin) is supported by default. Local authentication only supports the isadmin administrator user.
• Basic Authentication. PowerFlow continues to support Basic Authentication as well. Because the PowerFlow SyncPacks, diagnostic scripts, and the iscli tool continue to use Basic Authentication, ScienceLogic does not recommend disabling Basic Authentication.
• OAuth. Lets PowerFlow administrators use their own authentication providers to enforce user authentication and lockout policies. Authentication using a third-party provider, such as Active Directory, or using a protocol like LDAP, requires additional configuration. For optimal security, ScienceLogic recommends that you disable the local Administrator user (isadmin) and exclusively use your own authentication provider.
• Common Access Card (CAC) Authentication. Lets a PowerFlow user provide a CAC card through a browser to the PowerFlow root IP address. After identifying the CAC card, the ingress proxy verifies and authenticates the user. CAC authentication bypasses Dex authentication and does not use OIDC protocols. You can also use CAC authentication with LDAP, or CAC authentication with LDAP and SAN.
• API Key Authentication. Provides access to the PowerFlow API in a controllable manner, with options to restrict which hosts may or may not use certain tokens.

Depending on the authentication used by your PowerFlow system, the PowerFlow login page will display a single option for logging in, or more than one option:

You should configure your authentication strategy in the /etc/iservices/isconfig.yml file on the node from which you are deploying. When you have an acceptable configuration, the autoheal action copies those settings to the other nodes for consistency.

Regardless of authentication strategy, authorization and role access is configured separately, based on user or user group. For more information, see Creating a User Group in PowerFlow.

The following topics describe how to configure each authentication strategy for PowerFlow:

• User Interface Login Administrator User (default)
• Basic Authentication Using a REST Administrator User (default)
• User Interface Login Using a Third-party Authentication Provider
• OAuth Client Authentication Using a Third-party Provider
• Common Access Card (CAC) Authentication
• CAC Authentication with LDAP
• CAC Authentication with LDAP and SAN
• API Key Authentication

User Interface Login Administrator User (Default)

The local Administrator user is the default login user for PowerFlow. The username is "isadmin" by default, and the password gets set during the ISO installation process. The PowerFlow administrator can change the default password or the Administrator user.

This authentication strategy allows authentication of the local Administrator user through the PowerFlow user interface. The "isadmin" user is the local Administrator by default, but you can change the username of the local Administrator to something other than "isadmin" if needed.

If you disable this authentication strategy, you must first configure an alternative provider to appropriately authenticate to the PowerFlow system and also configure a user or user group policy that has the Administrator role. If you disable this user without a second authentication provider configured, PowerFlow will not be able to authenticate any users.

To disable this user, set the following environment variable in the /etc/iservices/isconfig.yml file:

BASIC_AUTH: False

To change the local Administrator username, set the following environment variable in the /etc/iservices/isconfig.yml file:

BASIC_AUTH_USER: "username"

Before changing the local Administrator username, make sure that the user has Administrator permissions in the PowerFlow system. For more information, see User Groups, Roles, and Permissions.

ScienceLogic recommends that you use the same system-wide password for the local Administrator user, which is located in /etc/iservices/is_pass.

Starting in PowerFlow version 3.0.0, you can use the following command to update the PowerFlow Administrator (isadmin) user password:

pfctl --host IP isadmin:password password set -p 'new_password'

This command replaces the ispasswd script from earlier releases of PowerFlow, which was found in /opt/iservices/scripts/ispasswd. The ispasswd script will be deprecated in a future release. 

Alternatively, you can set a different password for the local Administrator user by setting the following environment variable in /etc/iservices/isconfig.yml:

BASIC_AUTH_PASSWORD: "BASIC_AUTH_PASSWORD"

Basic Authentication Using a REST Administrator User (Default)

Basic Authentication through a REST administrator user enables the local Administrator user to access the PowerFlow API through REST using Basic Authentication. This authentication strategy enables users to make queries through the API using <isadmin:password> basic authentication.

This Basic Authentication is enabled by default. The REST administrator uses the same environment variables and configuration as the user interface login Administrator user.

Basic Authentication is limited to only the local Administrator user. If your PowerFlow system is configured to use a different authentication provider, you must authenticate using OAuth 2.0 and a bearer token. For more information, see OAuth Client Authentication Using an Internal Provider.

User Interface Login Using a Third-party Authentication Provider

This authentication strategy lets you set up user authentication through a third-party authentication provider, such as LDAP, Active Directory (AD), or OAuth 2.0. You configure additional providers and their connectors in the /etc/iservices/isconfig.yml file, following the Dex connector configuration described below. This authentication strategy is automatically disabled when no connectors are present in the configuration.

After you configure the providers, users can select one of the defined providers or the local Administrator authentication, and authenticate using that provider.

When using this authentication strategy, the PowerFlow system automatically retrieves the LDAP or AD groups to which the user belongs. You can use these groups can be used to apply specific role permissions. For more information, see Role-based Access Control (RBAC) Configuration.

By default, no third-party authentication providers are configured in PowerFlow.

Credentials for user authentication exist only with the third-party authentication provider, and the credentials are not imported into PowerFlow. The only information that PowerFlow retains for these users are the roles and permissions attached to the user names.

To configure a third-party authentication provider:

1. Go to https://github.com/dexidp/dex#connectors and locate the connector type, such as LDAP, OIDC, or OAuth 2.0, that you would like to use for authentication.
2. Click the link for the connector type to view example configuration options for the connector.
3. Update the /etc/iservices/isconfig.yml file and add a DEX_CONNECTORS section with the configuration for the connector you want to use. The DEX_CONNECTORS section in the isconfig.yml file is identical to the CONNECTORS section described in the Dex documentation.
4. Re-deploy the PowerFlow stack and check for errors in docker service logs iservices_dexserver. If the dexserver starts successfully and PowerFlow is running, then PowerFlow has accepted the configuration.
5. Next, log in to the PowerFlow system with a user provided by the newly configured authentication.
6. Look for errors with searching users or user groups in the user interface or the Docker service logs.

Code Example: isconfig.yml file with an Active Directory authentication provider

For reference, the following is an example /etc/iservices/isconfig.yml file with an Active Directory authentication provider configured to look up users and their groups:

OAuth Client Authentication Using a Third-party Provider

OAuth Client Authentication provides user authentication with a configured third-party provider, such as LDAP or AD. This allows users to use clients authenticating with OAuth 2.0 bearer tokens to authenticate against their configured provider.

The OAuth Client Authentication strategy is automatically enabled when a authentication provider is configured. You can configure this strategy using the same parameters as the User Interface Login Using a Third-party Authentication Provider.

The PowerFlow system provides discovery endpoints for all OAuth 2.0 required endpoints. The discovery address is: https://IS-IP:5556/dex/.well-known/openid-configuration.

Using these discovery endpoints, you can use an OAuth 2.0 client to generate a secure token using a third-party authentication provider. You can use the generated secure token as a bearer authentication token (specified in request headers) to authenticate and make requests.

The client_secret and session_secret are unique, randomly generated strings generated for each IS deployment. To obtain an OAuth 2.0 token, you will need these values, which you can find in the /etc/iservices/isconfig.yml file.

Basic Authentication Lockout Removal

PowerFlow supports OAuth 2.0 with OpenID Connect, which lets PowerFlow administrators use third-party authentication providers, such as LDAP or Active Directory, to enforce user authentication and lockout policies. PowerFlow continues to support Basic Authentication as well, but PowerFlow no longer enforces automatically locking out the isadmin user if that user has too many failed login attempts.

If you are concerned about removing the lockout functionality for the isadmin user, you can perform one of the following actions:

1. Change the default username from isadmin to a different name to prevent brute force type attacks on the isadmin user.
2. Disable Basic Authentication and use third-party authentication providers, such as your company's LDAP server, to enforce user authentication and lockout policies.

Before disabling Basic Authentication, make sure that all scripts or tools that query the PowerFlow API have been updated to use OAuth 2.0.

Common Access Card (CAC) Authentication

Enabling Common Access Card (CAC) authentication lets a PowerFlow user provide a CAC card through a browser to the PowerFlow root IP address. After identifying the CAC card, the ingress proxy verifies and authenticates the user. CAC authentication bypasses Dex authentication and does not use OIDC protocols.

Applying CAC Authorization

To enable Common Access Card (CAC) authorization on the PowerFlow system:

1. Link to a valid server CA certificate:

   • ScienceLogic Certificate: http://ca.pivkey.com/server-ca.crt
   • DODIN Certificate for sample CAC cards: http://repository.auto.sciencelogic.local/artifactory/misc-artifacts/DoD_CAs.crt

2. Set up Public-Key Cryptography Standards (PKCS) #11 in Firefox for your CAC card according to the following instructions: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/pkcs11.

   Use the certificates in step 1 for loading authorities.

3. Add the corresponding server-ca secret into the gui container in the docker-compose file:

   gui:
     secrets
      - source: server-ca.crt
   secrets:
    server-ca.crt:
      file: /etc/iservices/server-ca.crt
   

4. Add the following line to /etc/iservices/isconfig.yml:

   CAC_AUTH: 'true'

Adding CRL to CAC Authentication

To add a certificate revocation list (CRL) to CAC authentication:

1. Download an example CRL from this site: http://ca.pivkey.com/server-ca.crt.

2. Install the following SyncPack that contains a PowerFlow application that you can run to continually update CRL: http://repository.auto.sciencelogic.local/artifactory/pypi-local/is_syncpack_mud/1.0.0/is_syncpack_mud-1.0.0-py3-none-any.whl.

3. Add the corresponding volume information to gui and syncpacks_steprunner in the docker-compose file:

   syncpacks_steprunner:
   volumes:
   ...
   - source: ca_crl
         target: /var/crl
         type: volume
   gui:
   ...
   volumes:
       - read_only: true
         source: ca_crl
         target: /var/crl
         type: volume
   volumes:
   ...
     ca_crl: {}

4. Restart the PowerFlow services.

5. Install the MUD SyncPack from step 2 and run the PowerFlow application to Fetch CRL.

   Alternatively, you can manually mount a PEM-formatted CRL file to /var/server-ca.crl.

6. After the CRL is applied to the volume, update the configuration of /etc/iservices/isconfig.yml with the following line and then re-deploy:

   CAC_CRL: 'true'

CAC Authentication with LDAP

CAC authentication with LDAP uses the standard CAC authentication process, and it additionally searches the LDAP server for relevant groups of the user, which can be used for role-based access control (RBAC) checking later.

This authentication process uses the same DEX_CONNECTORS configuration settings for the configured LDAP/AD server and associated certificates to perform a search of the users' LDAP server. Using the search strings configured for Dex, if the CAC logic identifies group membership, the user session will be updated with their groups.

Environment Expectations

CAC authentication with LDAP requires the following:

• The user must provide an Admin Bind DN and password to provide a search of the LDAP system.
• The user from CAC will not attempt to be bound and authenticated to LDAP.
• The end user has necessary certificates to form a trusted ldaps// connection. SSL certificate verification can be disabled, but is not recommended.
• The administrator is aware of the LDAP environment, search attributes, and object classes necessary to link either a CAC user's SAN or CN to their group membership
• Only SAN or CN is supported for group membership search.

Add LDAP to CAC Query

CAC authentication with LDAP requires ldapCA.pem, which is a file with the internal LDAP server CA chain. This will get concatenated to tls-ca-bundle.pem, the ca-trust bundle of the is_gui container.

To copy an LDAP CA certificate for verification:

1. Create tls-ca-bundle.pem by running the following commands:

   docker cp $(docker ps -q --filter name=iservices_gui):/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /etc/iservices/tls-ca-bundle.pem

   cat ldapCA.pemt >> /etc/iservices/tls-ca-bundle.pem

2. Use an SCP tool to move tls-ca-bundle.pem to /etc/iservices/.

Update the Docker configuration:

configs:
  isconfig:
    file: /etc/iservices/isconfig.yml
  tlsbundle:
    file: /etc/iservices/tls-ca-bundle.pem

  dexserver:
    configs:
    - source: isconfig
      target: /etc/iservices/isconfig.yml
    - source: tlsbundle
      target: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
    deploy:
      replicas: 3
      restart_policy:
        condition: on-failure
    environment:
      db_host: couchbase.isnet,couchbase-worker.isnet,couchbase-worker2.isnet
    networks:
      isnet:
        aliases:
        - dexserver
        - dexserver.isnet
    secrets:
    - source: is_pass

gui:
    read_only: true
    configs:
    - source: isconfig
      target: /etc/iservices/isconfig.yml
    - source: tlsbundle
      target: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
...

Update the isconfig.yml configuration:

CAC_AUTH: 'true'
CAC_LDAP_VERIFY: 'true'
DEX_CONNECTORS:
- type: ldap
  name: ldap
  id: ldap

  config:
    host: rstcsdc01.sciencelogic.local
    rootCA: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

    bindDN: CN=svc-ldap-commander,OU=_Service,OU=Domain User Accounts,DC=sciencelogic,DC=local
    bindPW: <pass removed>
    usernamePrompt: silo credentials
    userSearch:
      baseDN: OU=Domain User Accounts,DC=ScienceLogic,DC=local
      filter: "(objectClass=user)"
      username: userPrincipalName
      idAttr: DN
      emailAttr: userPrincipalName
      baseDN: OU=Domain User Accounts,DC=ScienceLogic,DC=local
      filter: "(objectClass=user)"
      username: userPrincipalName
      idAttr: DN
      emailAttr: userPrincipalName
      nameAttr: cn

    groupSearch:
      baseDN: OU=Domain Groups,DC=ScienceLogic,DC=local
      filter: "(objectClass=group)"
      userAttr: DN
      groupAttr: member
      nameAttr: cn

To make sure that user sessions are terminated upon account deletion from the Active Directory server, the following configuration can be set in the isconfig.yml file. This setting ensures that the user account validation is executed during every user request:

FORCE_CAC_LDAP_REVALIDATION: 'true'

This configuration is disabled by default, as it can cause overhead in the Active Directory server. For more information, see Configuring Authentication Settings in PowerFlow.

CAC Authentication with LDAP and SAN

CAC authentication with LDAP and SAN allows the user to use their Subject Alternative Name (SAN) value when performing group lookup.

To implement CAC authentication with LDAP and SAN , use the configuration variable called CAC_LDAP_SEARCH_BY. This environment variable specifies whether to use Subject Alternative Name (SAN) or Common Name (CN) for LDAP group membership searches when LDAP is enabled and when CAC_LDAP_VERIFY is enabled. The default value of this environment variable is san; use cn for Common Name in the environment variable section.

API Key Authentication

The API key authentication strategy gives users access to the PowerFlow API using API keys, which are also called authentication tokens. This strategy provides access to the PowerFlow API in a controllable manner, with options to restrict which hosts may or may not use certain tokens.

You can create an API key on the API Keys page () of the PowerFlow user interface. After you create the API key, you can use it to create requests to the PowerFlow API endpoints based on the role you assigned to the key. The role defines which resources the key has access to in the PowerFlow API. 

For more information about using API keys, see Creating and Using API Keys in SL1 PowerFlow.

Role-based Access Control (RBAC) Configuration

Regardless of the authentication method you have chosen to use, the role-based permissions assigned to users is applied in the same way. PowerFlow uses the existing users and user groups that you have already set up in your authentication system.

Assigning a Role to a Specific User

By applying a role permission to a single username on the Admin Panel page, or through the API, permissions will be granted to any user who logs in through a provider matching that username.

Assigning Roles to a Specific User Group

By applying a role permission to a group name on the Admin Panel page, or through the API, permissions will be granted to any user who logs in and is a member of the specified group.

For authentication to work properly, group_search must be configured in the authentication provider's connector information. When requesting authentication tokens, be sure to also request the groups claim.

If a user belongs to multiple groups, with varying permissions defined to each group, the user will be permitted to do all actions provided by the group that provides the most roles.

Viewing User and Group Information

After configuring your third-party authentication connector in Dex, you can run the following command to view the search strategy and group results for any user that attempts to authenticate by looking at the Dexserver logs:

docker service logs -f iservices_dex

Changing Roles and Permissions

To change roles and permissions through the PowerFlow user interface, go to the Admin Panel page () to create and edit the roles and permissions of the users or user groups. For more information, see Creating a User Group in PowerFlow.

To change roles and permissions through the API, refer to the swagger.yml file for API required parameters and endpoints to update roles and permissions.

Configuring Authentication Settings in PowerFlow

The following configuration settings can be configured and used with the PowerFlow authentication and authorization strategies:

• DEX_CONNECTORS. This environment variable specifies which authentication providers Dex will use. For more information, see User Interface Login Using a Third-party Authentication Provider.
• BASIC_AUTH_USER. This environment variable specifies the basic_auth and admin login username. For more information, see User Interface Login Administrator User.
• BASIC_AUTH_PASSWORD. This environment variable specifies the basic_auth and admin login password. For more information, see User Interface Login Administrator User.
• BASIC_AUTH. This environment variable specifies whether the local Administrator user will be enabled. For more information, see User Interface Login Administrator User.
• BIND_DN. Use this encrypted value in the dex_connectors section when using LDAP as a connector.
• BIND_PW. Use this encrypted value in the dex_connectors section when using LDAP as a connector.
• CLIENT_ID. The IS client_id in use by default is isproxy, and you should not change this value.
• CLIENT_SECRET. The client_secret is a randomly generated string unique to each PowerFlow deployment. In most configurations, you do not need to change this secret.
• CAC_AUTH. This environment variable specifies whether to enable CAC certificate checking. If this is used, there should be a public CA certificate added as a server-ca.crt secret to the gui container. For more information, see CAC Authentication.
• CAC_CRL. This environment variable specifies whether certificate revocation list (CRL) checking is enabled for the CAC client certificate. If this is true and updated, the user should must add a ca_crl:/var/ca_crl volume to both the gui and syncpacks_steprunner services.
• CAC_LDAP_VERIFY. This environment variable specifies whether to enable lookup of group permissions based on the user Subject Alternative Name (SAN) or Common Name (CN) to the configured LDAP server. If this is configured, the user must configure an LDAP or AD server under the DEX_CONNECTORS environment variable.
• CAC_LDAP_SEARCH_BY. This environment variable specifies whether to use Subject Alternative Name (SAN) or Common Name (CN) for LDAP group membership searches when LDAP is enabled and when CAC_LDAP_VERIFY is enabled. The default value of this environment variable is san; use cn for Common Name in the environment variable section.
• FORCE_CAC_LDAP_REVALIDATION: This environment variable ensures that user sessions are terminated upon account deletion from the AD server when using CAC authentication. This variable will only work if the CAC_LDAP_VERIFY variable is enabled. This configuration is disabled by default, as this setting can cause overhead in the AD server.

User Groups, Roles, and Permissions

On the Admin Panel page (), you can edit and create user groups that define the different roles and permissions for your users. Depending on their assigned permissions, users have access to certain features, or they are blocked from certain features.

On this page, you can allocate permissions to users and user groups that exist in your authentication system. The User Group field in the PowerFlow user interface can specify either an individual user or a group that already exists in your authentication system.

The available roles and permissions for PowerFlow include the following:

• View. The user can view and get via the API the list of applications, the list of installed SyncPacks, the dashboards, the reports, the configuration objects, and the results of application runs.

• Execute. The user has all of the privileges of the View permission, but the user can also trigger application runs through the user interface or the API.
• Configuration. The user has all of the privileges of the Execute permission, but the user can also add and edit configuration objects and modify the application variables.
• Developer. The user has all of the privileges of the Configure permission, but the user can also add, copy, and edit step definitions; add, copy, and edit application variables; and create SyncPacks.
• Administrator. The user has all of the privileges of the Develop permission, but the user can also add, install, activate, and delete SyncPacks; delete applications, steps, and configuration objects; and access to (but not authorization to) the user interfaces for Couchbase, Flower, and RabbitMQ.

Additional information about roles and permissions in PowerFlow:

• Roles in PowerFlow are automatically assigned to a user based on the user's group with the external provider (such as LDAP or AD) .
• If a PowerFlow system does not have an external provider configured, such as LDAP or Active Directory, that PowerFlow system can only support a single isadmin Administrator user.
• The only password saved in the PowerFlow system is the password for the isadmin Administrator user. All other user passwords are saved in the third-party authentication provider configured for PowerFlow.
• The authentication configuration used by PowerFlow is also supported in SL1.
• API queries made by users will also be checked for proper authorization.
• The PowerFlow administrator can configure which users are in which roles.
• The PowerFlow administrator can test and configure the LDAP and Active Directory settings to ensure that the settings work before proceeding.
• The PowerFlow administrator can always log in with the isadmin Administrator user, even if the underlying LDAP provider is inaccessible.

Creating a User Group in PowerFlow

On the Admin Panel page, you can allocate permissions to users and user groups that exist in your authentication system.

If you have the Administrator role, you can modify the permissions for each user group on the page. You cannot change the permissions for the user group to which you currently belong. A user with the Administrator role can also create a user group and assign permissions to that group.

The only password saved in the PowerFlow system is the password for the isadmin Administrator user. All other user passwords are saved in the third-party authentication provider configured for PowerFlow.

To create a user group:

1. In the PowerFlow user interface, go to the Admin Panel page ():

   

2. Click Add User Group. The Create User Group window appears.
3. Complete the following fields:

• User Group Name. Type a name for this user group, without spaces. This is the name that the user or the users in the user group will use when logging in to PowerFlow. You can specify either an individual user or a user group that already exists in your authentication system.
• Choose Permissions Group. Click Add Permission to select the permission to assign to this new user group. Your choices include Developer, Configuration, View, Execute, and Administrator, and these choices are defined in User Groups, Roles, and Permissions.

4. Click Create User Group. The group is added to the Admin Panel page.
5. If you want to give a user group more permissions, select the empty checkbox () for that role from the Admin Panel page. You must have the Administrator role to change these settings.
6. If you want to remove permissions from a user group, select the highest level role, which has a blue check mark (). The role to the right (with fewer permissions) becomes the new role for that user group.

Managing User Sessions

A user with the Administrator role can use the Session Management pane of the Admin Panel page () to monitor which users have been logged into the PowerFlow system. The admin user can end active sessions as needed. Non-admin users can view user sessions, but they cannot end those sessions.

When an administrator ends a session for a user by clicking the End sessions button, that user is redirected to the PowerFlow login page.

Enabling Session Management

Session management is disabled by default. You can use the following set of configuration variables to enable and configure session management. You can set these variables in the PowerFlow configuration file /etc/iservices/isconfig.yml or on the services environment variables:

• ENABLE_SESSION_STORAGE. Set to true to enable session management with default values. This variable is set to false by default.

• SESSION_IDLE_TIME: Specify the idle time in seconds. The default is 900 seconds. This value and the following values should be declared as a string.

• SESSION_RENEW_EVERY: Specify the automatic session regeneration time in seconds. The default is 600 seconds.

• SESSION_ABSOLUTE_TIME: Specify the longest time allowed for a session, in hours, such as 25h. You can also use minutes, such as 60m. This variable uses Dex notation. The default is 25h (25 hours).

• CONCURRENT_SESSIONS_BY_USER. Specify the number of sessions that can be running at the same time, by number of users. The default is 30 users.

  When the number of user sessions is exceeded, the user trying to log in is redirected to a "Session limit has been reached" page, and then the user is returned to the login page.

You can use the following configurations in the /etc/iservices/isconfig.yml file to improve load balancer compatibility if the load balancer sends requests to the client in proxy protocol format like AWS ELB:

• LOAD_BALANCED: true. Setting this value to true specifies that the load balancer will send requests to the client in proxy protocol format. This value is false by default.

• RATE_LIMITED. Setting this value to true enables rate limiting. This value is false by default.

• RATE_LIMIT_REQUESTS_PER_SECOND. This value specifies the number of rate limit requests per second. The default is '50'.

• RATE_LIMIT_BURST. This value specifies the rate limit burst. The default is '100'.

You will need to re-deploy the PowerFlow stack for any changes to the docker-compose.yml file to take place.

In addition, the exposed ports in the docker-compose.yml file are set to mode: host to let PowerFlow capture the proper client IP address of the requests being sent into PowerFlow. This setting lets PowerFlow set the proper rate limits and log transactions. This feature does not allow using the Swarm ingress; as a result, you will need to scale the gui container and place the container in the nodes that will be expecting ingress traffic.

Authentication and Authorization for Services Used by PowerFlow

The PowerFlow administrator can control the level of access to the specific PowerFlow services, including Couchbase and RabbitMQ. Authentication for these services is provided by Dex authentication, which is already used for role-based access control (RBAC) in PowerFlow.

This feature requires LDAP/AD authentication for the PowerFlow system. For more information, see OAuth Client Authentication Using a Third-party Provider.

Couchbase

• Couchbase authentication. To access the Couchbase user interface, a user must log in to PowerFlow first, using his or her PowerFlow credentials. If the user is authorized to access the Couchbase user interface, the user can add port "8091" to the PowerFlow URL, and the user will be automatically redirected to the Couchbase user interface.

• Couchbase authorization. The roles and user groups defined in PowerFlow are applied to the Couchbase user interface based on the default user group policies. The PowerFlow administrator can update these user policies to specify which groups can access Couchbase.

  Couchbase authorization uses the following default permissions:

• Administrator. The user has access to all resources at all levels.
• Developer. The user can add and edit buckets and documents, but the user cannot delete anything.
• Configuration. The user can add and delete indexes and add nodes to Couchbase.
• Execute. The user has read-only access.
• View. The user cannot login to the Couchbase user interface. This was explicitly set that way as Couchbase is the main database for PowerFlow.

RabbitMQ

• RabbitMQ authentication. RabbitMQ authentication works the same as PowerFlow authentication and Couchbase authentication.
• RabbitMQ authorization. RabbitMQ authorization uses the following default permissions:

• Administrator: The user has access to all resources, at all levels, and the user can create internal users and policies. These policies do not impact PowerFlow users.
• Developer: The user can create resources and read all resources on all vhosts.
• Configuration: The user can create queues and exchanges only in the default vhost, but the user can read queues and exchanges on all vhosts.
• Execute: The user can read queues and exchanges on all vhosts, but the user cannot create or configure any resources.
• View: The user can only view queues and exchanges on the default vhost.

If you want to disable the auto-login feature for RabbitMQ and Couchbase, you can set the force_auth_validation environment variable to "true" under the GUI container configurations in the docker-compose file. Setting this variable to "true" allows you to access the Couchbase or RabbitMQ user interface to address issues without needed to authorize. If the flag is missing or set to "false", the auto-login feature continues to work.