Managing Users and Permissions

14 Managing Users and Permissions

This chapter explains the roles and permissions assigned to users within RUEI, as well as the creation and management of user accounts. The configuration of external user authentication mechanisms (such as LDAP and SSO), and the use of the password settings facility to enforce your organization's security policies, is also described.

Introduction to Users and Permissions

To start working with user definitions, select System, and then User management. The screen shown in Figure 14-1 appears.

Figure 14-1 User Management

Description of "Figure 14-1 User Management"

This screen lists the currently defined system users. For each user account, their account name, full name, E-mail address, and authentication mechanism are listed. A user account's role and status is indicated through the color-coded scheme explained in Figure 14-2.

Figure 14-2 User Account Roles and Status

Description of "Figure 14-2 User Account Roles and Status"

System Account Type

In addition to user accounts, you can also create a system account which does not have access to the RUEI User Interface. These accounts are used to interact with RUEI at a service level, for example if you use the ADF Monitoring Service. System accounts have full access level, and can be configured to have the permissions described in Table 14-4.

User Authentication

The authentication of system users can either be performed by RUEI itself, based upon the user information stored within its database, or by an external authentication server. Currently, RUEI supports two external authentication mechanisms: via an LDAP server, or via an oAuth2 single-sign-on framework. In both cases, the server must be configured to work with RUEI. The procedure to configure the LDAP server is described in Configuring LDAP Server User Authentication, while the procedure to configure an oAuth2 single-sign-on framework is described in oAuth2 User Authentication.

Understanding User Account Roles and Permissions

This section explains how RUEI manages access to its configuration facilities, as well as to reported data. It is recommended that you carefully review the following information.

Each RUEI user is assigned a role. This role determines the actions that they can perform, and the type of information to which they have access. These roles are explained in Table 14-1.

Table 14-1 User Account Roles

Role	Description
Administrator	This user performs the initial configuration of RUEI, and maintains the basic network-related configuration (such as mail settings and Collector attachments) used by the system. In addition, users assigned Administrator privileges act as first-level support for the system, and are responsible for such things as performing backups of the current configuration, the configuration of advanced system settings, and the administration of the other users authorized to work with the system.
Security Officer	This user is responsible for managing all system settings that are affected by the organization's network security policy. In particular, they: Import the security certificates and private keys used to decrypt HTTPS user flows, and keeps them up-to-date. Decide the scope of what is monitored within the organization's network. They can set up network filters to prevent the capturing of specific networks or hosts, or Virtual Local Area Networks (VLANs), or to reduce overall network traffic. Implement and maintain security-related measures for private data passed in web traffic.
Business users	These users are concerned with evaluating visitor behavior according to business goals. As such, they use the business intelligence that the system offers them to monitor a wide variety of issues, such as identifying the most popular paths taken to your web site, or how engaged visitors are on particular pages or sections. They may be concerned with improving customer satisfaction, retention, and loyalty, increasing conversion rates, or monitoring the effectiveness of web site-based marketing activities. Based on assigned permissions, they use the dashboard functionality, as well as on-demand and mailed reports, to maintain an overview of the organization's operations. They can also use these reports and data exports as the basis for further analysis by IT specialists.
IT users	These users are concerned with supporting the IT and other technical information the system needs to monitor the web environment. Typically, they are responsible for deeper analysis of failed SLAs or KPIs. They use the reporting and Data Browser facilities to their fullest to locate the reported anomaly or failure. For example, they might identify that failed user sessions are only occurring for users from a particular network domain.
Report Data Export	These users use basic authentication to access reports. For more information on the feature see Exporting Report Data.
Session Diagnostics	These users can access Session Diagnostics page. For more information, see Working With the Session Diagnostics Feature.
View/Edit KPI Configuration	These users can View/Edit KPI configurations. A user with None or Overview access level within Business or IT access rights, can only view KPI configurations. A user with Business or IT access rights such as Inquiry, Analytical, Full, Administrators, or Security officers can edit KPI configurations.
Edit Dashboard Template	Users can create, edit, and publish templates.

User Account Roles

Depending on the configuration required by your organization, users can be authorized to perform combinations of these roles. There is no limit to the number of users who can be defined.

Super Administrator Versus Authorized Administrators

Be aware that there is one predefined RUEI user: the Super Administrator. Unlike all other users, their initial password is set using the set-admin-password.sh script, and is always locally authenticated. Depending on your operational requirements, other users can be assigned Administrator privileges. However, these users remain under the control of the Super Administrator. For clarity, when it is necessary to distinguish the Super Administrator from other users assigned Administrator privileges, the Super Administrator is referred to as the admin user.

Administrators Changing Each Other's Properties

By default, users with Administrator permissions can change the properties of other Administrators, as well as create and delete Administrator user accounts. If this is not consistent with your security requirements, you can disable this functionality. The procedure is described in the Oracle Real User Experience Insight Administrator's Guide.

User Account Access Level Permissions

In addition to roles, each user (other than Administrators) is also assigned a separate access level permission for Business and IT-related information. These define the modules (such as the Data Browser, KPI Overview, and System) to which the user has access. They are described in Table 14-2.

The minimum permission required to view KPI definitions is Overview access levels or higher. Only Full access level users can modify KPI definitions or copy/delete a KPI.

Table 14-2 Business and IT Access Level Permissions

Access Level	Business User	IT User
None	The user has no access.	The user has no access.
Overview^Foot 1	The user can view their dashboards, the KPI overview, and alert history.	The user can view their dashboards, the KPI overview, and alert history.
Inquiry	The user has read-only access to reports, and can create PDF downloads.	The user has read-only access to reports, and can create PDF downloads.
Analytical	Has access to the Data Browser. Can create new reports, and modify (public or own) reports.	Has access to the Data Browser. Can create new reports, and modify (public or own) reports.
Full	Define and modify KPIs. Edit the service level schedule. Edit alert schedules. Define and modify user flow. Define and modify site-wide errors.	Define and modify KPIs. Edit the service level schedule. Edit alert schedules. Define and modify applications. Define and modify named web servers. Define and modify named clients. Define and modify site-wide errors.

^Footnote 1

A user who is not authorized to at least Overview level as either a Business or IT user cannot log on.

The management of user roles and access level permissions is described in Understanding User Account Roles and Permissions.

In this way, Business and IT users can immediately locate the information that is relevant to them. For example, on entry to the Report library, the list of displayed reports for a business users is filtered to reflect the reports with which they will want to work.

Table 14-3 outlines the minimum permissions required for access to session diagnostics data:

Table 14-3 IT and Business User Permissions for Session Diagnostics

Access Level	All Applications	Specific Applications
Overview	No access	No access
Inquiry	No access	No access
Analytical	Access	No access
Full	Access	Access

Note:

Restricting authorization on specific applications, services or suites blocks the Analytical users access to the session diagnostics data content. Analytical users need be authorized to all application/suites/service in order to access session diagnostics data (access to specific applications is not sufficient).

System Account Roles Permissions

Currently, there are no roles associated with system accounts and only the following permissions:

Table 14-4 System Account Permissions

Access Level	System Account
ADF Monitoring Service	These users use RUEI to monitor ADF applications. For more information on setting up RUEI to work with ADF, see the RUEI Installation Guide.
Enterprise Manager Access	These users allow RUEI data to be available in Oracle Enterprise Manager. For more information on setting up RUEI to work with Oracle Enterprise Manager, see the RUEI Installation Guide. Users need to be authorized in order to access RUEI data within the Oracle Enterprise Manager Application Performance Management (APM) facility. This functionality is fully described in Oracle Enterprise Manager Cloud Control Oracle Fusion middleware Management Guide

Access Level

System Account

ADF Monitoring Service

These users use RUEI to monitor ADF applications. For more information on setting up RUEI to work with ADF, see the RUEI Installation Guide.

Enterprise Manager Access

These users allow RUEI data to be available in Oracle Enterprise Manager. For more information on setting up RUEI to work with Oracle Enterprise Manager, see the RUEI Installation Guide.

Users need to be authorized in order to access RUEI data within the Oracle Enterprise Manager Application Performance Management (APM) facility. This functionality is fully described in Oracle Enterprise Manager Cloud Control Oracle Fusion middleware Management Guide

Adding New Users

To create a new user, do the following:

Select System, then User management, and click the Add new account command button in the taskbar (see Figure 14-1). A dialog similar to the one shown in Figure 14-3 appears.

If an LDAP or oAuth2 server connection has been configured (as described in Configuring LDAP Server User Authentication), the dialog shown in Figure 14-3 lists an LDAP authentication option.

Figure 14-3 Add Account Wizard
Use the radio buttons shown in Figure 14-3 to create a new user or system account and to specify whether the user should be authenticated against the settings held in the RUEI installation (this is the default), or against a configured LDAP or oAuth2 server. When ready, click Next. A dialog similar to the one shown in Figure 14-4 appears.
Use the dialog shown in Figure 14-4 to specify the following information for a new account:
- The user name by which the user will be known within your RUEI installation. This must be a unique name. Users names are case sensitive. Note that if oAuth2 server user authentication is enabled, the user is automatically created as an oAuth2 user. In this case, specified user name must be the same as that defined within the oAuth server.
- The user's full name.
- The user's E-mail address. This is the address to which reports and E-mail alerts will be sent. Ensure it is correct.
- If the user will be authenticated against the settings held locally in the RUEI installation, you are required to specify and confirm a password for the new user. See Enforcing Password Security Policies for information about password requirements. The new password must be changed by the user within seven days or they are locked out.
- Optionally, use the Disabled check box to disable the user at this time. You are free to enable them later.
Figure 14-4 User Details Dialog

If you selected user authentication against a configured LDAP server in Figure 14-3, you can click the Get user data from LDAP button to retrieve the user's settings from the configured LDAP server.

Note:

For remote authentication (LDAP or oAuth2) the Account details does not include New password and Confirm password entry fields, and you don't need to provide a local password.
Click Next to continue. If you are adding a User account, proceed to step 4. If you are add a system account, as described in Introduction to Users and Permissions, proceed to step 5.
In the Basic tab, select the checkbox, Business Access Level menu, and the IT access level menu to specify the role and permissions to be assigned for the new user.

Figure 14-5 User Account Permissions
In the Advanced tab, select the checkbox to specify the permission to different services for the new user.
In the Data Access permissions tab, select the Authorize for menu for applications, suites, and services that the new user is authorized to view information about.
In the Data Access permissions tab, select options from Authorized by menu. You choose to assign a user with applications/suites/services, or assign a user with a custom application dimension value by selecting Application Dimension option.

In Authorized by menu, if you select, Application Dimension option, then you are entitled to all applications/suites/webservices to which, the chosen custom application dimension value is assigned.

.
For more information, see Understanding User Account Roles and Permissions.
If you are adding a system account, the dialog shown in Figure 14-6 appears.

Figure 14-6 System Account Permissions

System accounts have full access to application, suite and service data. For information about setting up the ADF Monitoring Service and Enterprise Manager access, see the RUEI Installation Guide.
Click Finish to create the user definition. You are returned to the user list shown in Figure 14-1

Note:

In addition to the settings described above, there are a number of additional settings (such as language, mailing type, and so on) that are set to their default values when a user is created. These additional settings can also be modified using the procedure described in Customizing Your Environment.

Modifying Existing Users

To modify a user definition, select System, and then User management. The User management panel shown in Figure 14-1 appears. Right click the appropriate user. The context menu shown in Figure 14-7 appears.

Figure 14-7 User Menu

Description of "Figure 14-7 User Menu"

The options shown in Table 14-5 are available.

Table 14-5 User Context Menu Options

Option	Description
Edit	Allows you to modify a user's definition. This is described in Modifying a User's Settings.
Enable/Disable account	Allows you to enable or disable the user account at this time. Note that all currently defined users are disabled when SSO authentication is enabled, and all SSO user accounts are disabled when SSO authentication is disabled.
Switch to	Allows you to temporarily change to the selected user. This is useful if you want to view the modules and reports that they are authorized to see. Select Switch back from the View menu to return to your own role. Note this option is not available when the selected user account is disabled.
Remove	Deletes the selected user from the system's user administration. Note that any private reports that the user created are also deleted. However, public reports created by the user remain available to other users.

Modifying a User's Settings

To change the settings for an existing user, do the following:

Select the required user within the user list shown in Figure 14-1, and select Edit. If an LDAP server connection has been configured (as described in Configuring LDAP Server User Authentication), a dialog similar to the one shown in Figure 14-3 appears. Otherwise, the dialog shown in Figure 14-8 appears, and you should continue from step 3.
Use the radio buttons to specify whether the user's settings should be authenticated against the settings held in the RUEI installation (this is the default), or against a configured LDAP server. When ready, click Next. If an LDAP server is configured, the dialog shown in Figure 14-4 appears. Otherwise, the dialog shown in Figure 14-8 appears.

Figure 14-8 User Details

Description of "Figure 14-8 User Details"
Optionally, modify any of the displayed information. Note that the fields shown with a red asterisk indicate they are mandatory. That is, they can not be left blank.

You can use the Disabled check box to prevent the user from using this account. You are free to enable them later.

Because user accounts are automatically locked after a user has failed to correctly enter their password on five successive attempts, you can use the Locked check box to reset it. Password security is described in Enforcing Password Security Policies. You can use this check box to unlock the user's account. When ready, click Next. The dialog shown in Figure 14-9 appears.

Note:

If a user's password is changed via this interface, the user must change the password themselves (using the procedure described in Customizing Your Environment) within seven days or the account will be locked.

Figure 14-9 User Preferences

Description of "Figure 14-9 User Preferences"

Optionally, you can modify the settings shown in Table 14-6.

Table 14-6 User Preference Settings

Setting	Description
Language	This is the language in which system messages and prompts appear. Currently, only English is available.
Mailing type	Specifies whether the reports the user receives are sent in multiple E-mails (one for each report) or bundled into a single E-mail. The default is multiple E-mails.
Startup module	Specifies the module in which the user starts their session. (For example, Reports, System, or User management). The default is the dashboard (described in Working With Dashboards).
Initial browse period	Specifies the initial period selection when entering the Data Browser or reports facility. The default is the last 6-hour period.

When ready, click Next. A dialog similar to the one shown in Figure 14-5 appears.

Optionally, use the check boxes and menus to specify the roles and permissions to be assigned to the user. These are explained in Understanding User Account Roles and Permissions. If the new user is not assigned Full access level permission, you should use the Authorize for menu to specify the specific applications, suites, and services they are authorized to view. When ready, click Finish for the changes you have made to take effect.

Example 14-1 Resetting the Super Administrator Password

In the event that you need to reset the admin user password, you can do so using the use of the set-admin-password.sh script. This is described in the Oracle Real User Experience Insight Installation Guide. Note the new password must be changed (via the procedure described in Modifying a User's Settings) within seven days.

Enforcing Password Security Policies

Each user must be defined and authorized to work with RUEI. The procedure to do this is explained in Introduction to Users and Permissions. In order to optimize the security of your installation, you can use the password settings facility to enforce your organization's security policies. Specifically, you can control the maximum length of user passwords, how often users are required to change their passwords, the number of days after the creation of a new user account within which the initial password must be changed, and the number of failed logon attempts after which a user account is locked.

To control your installation's password enforcement, do the following:

Select System, then User management, and click Password settings. The dialog shown in Figure 14-10 appears.

Figure 14-10 Password Settings

Description of "Figure 14-10 Password Settings"

Specify the information shown in Table 14-7.

Table 14-7 Password Settings for All Accounts

Field	Description
Minimum length	Specifies the minimum number of characters that user passwords must contain. This must be between 8 -255 characters, and the default is 8 characters.
Expiration age	Specifies how often users are required to change their passwords. The default is 60 days. If set to 0, passwords will never expire. The maximum expiration period is 999 days.
Initial expiration age	Specifies the number of days after the creation of a new user account within which the initial password must be changed. This must be 1 - 30 days. It also specifies within how many days a user must change their password after it has been reset by an Administrator. The default is 7 days.
Allowed login attempts	Specifies the number of failed logon attempts after which a user account is locked. This must be between 1 - 10 times. The default is 5 times.

To specify that system account passwords should not expire, enable the Password never expires option. When ready, click Save.

Example 14-2 Password Enforcement

When creating and authorizing users, the following rules are automatically enforced:

User accounts are locked after a specified number of failed attempts. The account must be unlocked before the user can logon again (described in Modifying a User's Settings). However, locked users will continue to receive mailed reports and alerts.
If a password's expiration period is set to 0, and later re-set to a non-zero value (or vice versa), all existing user accounts will adapt to the newly specified password expiration period.
A user password must have a minimum of eight characters. It must contain at least one non-alphanumeric character (such as $, @, &, and !).
A password cannot include the defined user name, or their first or last name. In addition, the user's last three passwords are also remembered, and cannot be re-used.
Passwords are case sensitive.

Managing the Scope of Authorized Data Within Modules

Users with Full access level permission have access to all information within the Data Browser, reports, the KPI overview facility, and dashboards. For all other users, the information available to them is managed as part of their user profile. The use of this facility is fully described in Understanding User Account Roles and Permissions.

Generic vs. Application, Suite, Service-Specific Items, and Application Dimension Items

KPIs, user flows, and dashboards can be defined as generic or bound to a specific application, suite, service or application dimension values. Access to the information within an item is automatically managed through each user's assigned permissions.

If an item is defined as generic, only users that are authorized to access all applications would be able to view the item. This is because a generic item can contain information about multiple applications, suites, or services. Similarly, if a user is only authorized to view information about two applications, they would only be able to view KPIs, dashboards, Data Browser information, and reports directly concerning those two applications.

If a user is authorized to view information about an application dimension value, they would be able to see KPIs, dashboards, Data Browser information, and reports that are related to this application dimension value. If any KPIs, dashboards, Data Browser information, and reports are associated to any of the applications/suites/web services inside the application dimension value(for example an application group), then they can be seen by this user.

Configuring LDAP Server User Authentication

In order to provide enhanced security, RUEI can be configured to enable user authentication via an LDAP server, rather than through the settings held locally on your RUEI installation. If an LDAP server connection has been configured, you can specify the authentication method to be used for each defined user. Note because the admin user is predefined, and their password is set during initial configuration (see the Oracle Real User Experience Insight Installation Guide), only local authentication is available for this user.

If you plan to use LDAP authentication, it is recommended that you define your LDAP connection before the creation of user accounts. This is in order to prevent having to modify previously specified user settings.

Configuring the LDAP Server Certificate

Note that the LDAP secure server certificate should to in PEM format, and be specified via the TLS_CACERT directive in the /etc/openldap/ldap.conf file. The certificate file must be owned by the root user, and be readable by the RUEI and Apache user groups. Note that the CN of the LDAP server certificate must match the fully qualified domain name of the LDAP server.

Troubleshooting LDAP Connection Problems

If the LDAP secure server certificate configuration procedure described above does not provide a working connection, you can use the OpenLDAP utility (available on the Oracle Linux or RedHat Enterprise Linux distribution set) to validate the configuration of your LDAP server. The utility can be installed and run using the following commands:

sudo yum install openldap-clients
ldapsearch -x -P 2 -H "LDAP_server_URL" -D
cn=jsmith, dc=oracle, cn-com

where LDAP_server_URL specifies the full URL for your LDAP server, and the pair combinations depends on your LDAP server configuration. If specified correctly, information about that user is returned from the LDAP server. Otherwise, the problem encountered (such as the specified host name does not match the LDAP server or LDAP certificate was not installed correctly) is reported.

Note that if the certificate does not work, you can set the TLS_REQCERT directive to 'never' in the /etc/openldap/ldap.conf file to prevent validation of the certificate and continuation with the secure connection.

Configuring the LDAP Server Connection

To enable LDAP server authentication, do the following:

Select System, then User management, and then click Configure LDAP connection. Note that if an LDAP server connection has already been configured, the option is indicated as Modify LDAP connection. The dialog shown in Figure 14-11 appears.

Figure 14-11 LDAP Settings Dialog

Description of "Figure 14-11 LDAP Settings Dialog"

Specify the information shown in Table 14-8.

Table 14-8 LDAP Settings Dalog Fields

Field	Description
Allow LDAP authentication	Specifies whether an LDAP server is available for user authentication. The default is unchecked (disabled).
Server name	Specifies the host name or IP address of the LDAP server to be used. Note that protocol information (such as LDAP://) should be omitted from the server name.
Connection type	Specifies the LDAP version and connection method. The default is V2 (non-secure).
Port number	Specifies the port to which the LDAP server is listening. If necessary, discuss this with your System Administrator. The default port is 389 or 636 (for SSL encryption).
Search base	Specifies the location in the directory structure within which the user ID needs to be unique. This must be a valid DN. For performance reasons, this should be as specific as possible. The default is the root of the directory tree.
Anonymous	Specifies if the LDAP server lookup should be performed using an anonymous user. If unchecked, then a valid Distinguished Name (DN) must be specified, and the password for that user is requested when a new user is created. The default is to use an anonymous lookup.
User ID, Email address, Full name	Specifies the attributes that should be used to extract user settings from the LDAP server. The defaults are based on standard LDAP functionality. If necessary, you should discuss these attributes with your LDAP administrator.

Optionally, you can click Test to verify whether a working connection to the LDAP server can be made. This is discussed in the following section. When ready, click Save.

Any changes you specify to the LDAP configuration settings take effect immediately.

Testing the LDAP Server

As mentioned earlier, you can test the connection to the LDAP server. Do the following:

Within Figure 14-11, click Test. The dialog shown in Figure 14-12 appears.

Figure 14-12 Test LDAP Settings

Description of "Figure 14-12 Test LDAP Settings"
Use the User ID to look up field to specify the user ID for which the LDAP server should search. This should be a valid user ID. When ready, click Test. Upon successfully finding the specified user's entry in the directory, their retrieved details are displayed. When ready, click Cancel. You are returned to the dialog shown in Figure 14-11.

oAuth2 User Authentication

To enhance security, configure RUEI to authenticate users using the oAuth2 single-sign-on framework. If oAuth2 is active, users visiting the RUEI login page will be automatically redirected to the configured oAuth2 server to log in. After the user has logged in, they will be redirected back to RUEI with a token, which RUEI will verify and use to obtain the user name.

Registering a client on the oAuth2 server

Create a client account on the oAuth2 server, as a prerequisite to configuring the oAuth2 integration. Use the following information as needed to complete the account creation procedure. Note that the procedure will depend on your oAuth2 provider.

Specify 3-legged oAuth
The redirect URI ends in /ruei/index.php. The full redirect URI is shown in the oAuth2 settings dialog (see below).

After you create the accout, you will receive a Client ID and a Client Secret, which need to be set in RUEI configuration.

Configuring oAuth2 integration

To enable oAuth2 authentication, in the RUEI UI, select System, then User management, and click on the Configure oAuth2 button in the toolbar. If oAuth2 is already configured, use the Modify oAuth2 Settings button. The dialog shown below appears

oAuth Settings Dialog Fields:

Field	Description
Enable oAuth2	Check this box to enable oAuth2 integration
Client ID	The client ID you received after registering the client on the oAuth2 server
Client Secret	The client secret you received after registering the client on the oAuth2 server
Redirect URI	The RUEI URI the user should be directed back to after signing in. The default value is your RUEI host name, followed by `/ruei/index.php`. You typically also need to provide this URI when registering the client on the oAuth2 server
Scope	This defines the access level RUEI should request from the oAuth2 server, which is normally supplied among the registration details of the oAuth2 server.
Server Host	The host name which should be used to access the oAuth2 server. If different API URI's are on different host names, or if the client should use a different hostname than the RUEI server, specify separate hostnames for each URL on the advanced tab.
Authorize URL	The front-end URL, without host component, which RUEI will redirect the user to for login.
Token URL	The back-end URL, without host component, which the RUEI server will use to send the authorization code, and receive an access token.
Logout URL	The front-end URL, without host component, where RUEI will redirect the user when they select the log out option.

oAuth Advanced Settings Dialog Fields:

Field	Description
Proxy	If the RUEI server needs to use a proxy to access the oAuth2 server, specify the name of that proxy here. Otherwise, leave blank.
User Field	This is the field inside the access token or credentials token which contains the user name.
Credentials URL	The back-end URL, without host component, where the RUEI server can fetch the user name information. If the user name information is contained in the login token, then this field can be left blank.
Authorize Host	The host name to use along with the Authorize URL, if this differs from the Server Host.
Token Host	The host name to use along with the Token URL, if this differs from the Server Host.
Credentials Host	The host name to use along with the Credentials URL, if this differs from the Server Host.
Logout Host	The host name to use along with the Logout URL, if this differs from the Server Host.

Authorizing oAuth2-based users to use RUEI

After the oAuth2 server settings configuration, create RUEI user accounts for oAuth2-based users. When creating these users, you need to specify oAuth-based authentication.

Local accounts

Users with local accounts, including the built in admin account, cannot log in using the oAuth2 integration. They can should access the admin login URL, which ends in /ruei/admin.php, to log in locally.

External Authentication

RUEI can also be configured using an external identification tooling instead of performing authentication itself. This external identification tool isolates RUEI as a protected resource that only allows authenticated users to access the webserver.

This external tool will then set a header containing the identified user. These headers are named as REMOTE_USER by default.

Note:

It is important to take an extreme care to prevent the interface from being accessed directly in any way (with an exception of admin.php for the admin user).

When using External Authentication feature, the validity of user login credentials is not checked because RUEI does not perform it's own authentication.

Configuration

After installation the following configuration should be done to activate external authentication. Execute these commands as the RUEI_USER user:

execsql config_set_value wi_core extauth_enabled 1

Optionally the above can be repeated for the following options (replace extauth_enabled with the option value below):

extauth_header

HTTP header, which contains user ID, prefixed with HTTP_.

extauth_login_url

extauth_logout_url

Logout URL to redirect.

In both URLs above a placeholder %s can be used to give in the RUEI URL to go back to after login or logout.

RUEI Users

To allow users to login using the external authentication, they need to be changed to External in the user configuration window.