If you are using OAM, see the appropriate section relating to the OAM version listed below. If you are using a different solution, you can still use RUEI to monitor SSO using Defining Single Sign-On (SSO) Profiles. The chapter contains the following sections:
RUEI can be configured to identify user IDs within Oracle Access Manager (OAM) traffic. OAM version 10.1.4.x (or higher) is supported. In order to monitor OAM-based traffic, do the following:
ObSSOcookie
. When ready, click Save. If your OAM server uses a customized cookie implementation, you should consult your OAM administrator. Information on the customization of OAM cookies is available from the Oracle Access Manager Administrator Guide.ObSSOcookie
. When ready, click Save.The procedure to configure your OAM server to work with RUEI is described in the Oracle Real User Experience Installation Guide.
Example 11-1 Reporting of OAM-Based Traffic
The reporting of user IDs within the Data Browser is based on Distinguished Name (DN). An example is shown in Figure 11-1.
Figure 11-1 Example of Reported OAM Traffic
RUEI can be configured to identify user IDs within Oracle Access Manager (OAM) traffic. OAM version 11g (R2PS3 BP02) is supported. In order to monitor OAM-based traffic, do the following:
Select the required application, and click the Users section.
Click Add new source. The dialog shown in Figure 7-32 appears.
Within the Search type menu, select the "Oracle Access Manager 11g" option.
The procedure to configure your OAM server to work with RUEI is described in the Oracle Real User Experience Installation Guide.
Reporting of OAM-Based Traffic
The reporting of user IDs within the Data Browser is based on the uid attribute of the user as recorded in the OAM LDAP.
RUEI has support for SSO (mod_osso) and LDAP authentication out of the box.
Specifically for OPC a setup was created that will not be checking actual authentication (password), but will assume RUEI is instrumented as a protected / LBaaS resource.
This resource needs to set a specific header to it's backend (not to end users), for which RUEI will match to RUEI users. These headers are often called REMOTE_USER
by default.
Note:
When the user enables the External Authentication feature, RUEI will not do it's own authentication anymore. So, it also will not be checking valid user login and passwords anymore for these users.
Download and install one-off ux-gui RPM
including external authentication support.
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
Login URL to redirect (when header is empty).
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.
To allow users to login using the external authentication, they need to be changed to External in the user configuration window.
Instead of directly using the client header of an external load balancer, we can also use $_SERVER
variables. This can be for example, be used to authenticate using webserver / PHP authentication. Note that this need not work with login / logout pages.
Test Example
Create .htaccess
in $RUEI_HOME/gui
AuthType Basic
AuthName "Password Protected Area"
AuthUserFile [your-safe-dir]/.htpasswd
Require valid-user
Create .htpasswd
with htpasswd tool
Modify header name:
execsql config_set_value wi_core "extauth_header" REMOTE_USER
Single sign-on (SSO) is a method of access control that enables a user to log in once and gain access to the resources of multiple software systems without being prompted to log in again. Because different applications and resources support different authentication mechanisms, SSO has to internally translate and store different credentials compared to what is used for initial authentication. SSO offers the following benefits:
Reduces password fatigue from different user name and password combinations.
Reduces time spent re-entering passwords for the same identity.
Reduces IT costs by lowering the number of IT help desk password-related calls.
SSO uses centralized authentication servers that all other applications and systems utilize for authentication purposes, and combines this with techniques to ensure that users are not actively required to enter their credentials more than once.
In order to facilitate the correct monitoring of SSO-enabled applications, you need to configure the authentication server(s) used within your environment. This is done through the creation of an SSO profile.
SSO servers manage user profiles and provide a login page to authenticated users. Applications then interact with SSO servers to validate temporary tokens. Figure 11-2 illustrates how application authentication works when enabled by an SSO server.
Figure 11-2 Authentication Flow Within SSO-Enabled Application Traffic
The authentication flow shown in Figure 11-2 takes the following sequence:
The user attempts to access a protected URL. The application server checks for the existence of an authentication cookie for the requested application. If found, it means that the user is already logged on, and no further authentication is required.
The user is re-directed by the application server to the SSO server. The application server also provides an application URL to the SSO server so that it knows where to go after user logon. Note the SSO server also checks whether the user is already authenticated (by another application) by validating any existing authentication cookie.
In the event the user is not recognized based on an existing authentication cookie, the SSO server requests credentials from the user via the login page, and these are specified by the user in a user name and password combination.
The user's credentials are verified against their entry in the SSO server database. Once validated, the authentication is preserved by an SSO cookie. The name of this cookie must be specified when creating a SSO profile.
The SSO server fetches the user's attributes. The attributes that are actually fetched are implementation-specific, and are not relevant to RUEI.
The SSO server passes the fetched attributes to the partner application server, using the URL provided to it in step 2. Note that a token argument is added to this URL. The name of this token argument must be specified when creating SSO profiles. The application server will probably also issue its own cookie to the user. This is configured as part of the application or suite definition.
Finally, note the network lines over which steps 1, 2, and 5 pass must be within the scope of RUEI monitored traffic.
SSO Profiles and Applications
It is important to understand that SSO profiles and applications, although closely related, are reported as separate entities within RUEI. For this reason, SSO profile and application definitions should be mutually exclusive. That is, each should be based on separate domains and cookies. Otherwise, the monitored traffic is reported as application-related traffic, and the potential benefits to enhanced reporting are not realized.
To define a SSO profile, do the following:
This overview provides a summary of the defined SSO profile and allows you, if necessary, to modify its definition. This is explained in the following section.
You can check the effect your user identification definition has by viewing the XLS User Information report in the Clients category. For more information on reports, see Working With Reports.
After defining an SSO profile, you can modify it via its overview. The following tabs are available:
Identification: specifies the scope of the SSO server in terms of one or more partial page URL matches. Pages are assigned to the SSO server when a defined filter matches a page's URL. To add a new filter, click Add new filter. Click an existing filter to modify it. A dialog similar to the one shown in Figure 11-6 appears.
Figure 11-6 Edit SSO Profile Filter Dialog
The note at the bottom of the dialog indicates the current rule ordering scheme. This is explained in Controlling Rule Ordering Within RUEI.
Configuration: specifies the authentication token and cookie used.
Users: specifies how user IDs are identified within the application. When not defined, the SSL client certificate is used (when available).
When verifying the correct operation and reporting of your SSO-enabled applications, the important aspect to inspect is the correct identification of users. It is recommended that you regularly review the reporting of within the Data Browser (All sessions > User Id > Sessions and page views). For example, an unexpectedly high level of unidentified users.
Also, you should verify that URLs within SSO-enabled applications are not reported within application-related data. This can indicate that there is a problem.