In this section: |
This section covers the authentication best practices for WebFOCUS.
We begin with an overview of authentication checkpoints, which are shown in the following image.
The security checkpoints serve the following purpose.
WebFOCUS Client |
The purpose of this security checkpoint is to ensure that only authenticated users are granted access to WebFOCUS. Then, based on their privileges they are granted access to authorized content. |
WebFOCUS Repository |
The purpose of this security checkpoint is to ensure that the configured database user ID has the appropriate permissions in the database to successfully execute SQL database commands required by WebFOCUS. By default, it is the database service user ID entered during the WebFOCUS installation. Credentials can be:
|
WebFOCUS Reporting Server |
The purpose of this security checkpoint is to ensure that authenticated users are granted access to the Reporting Server. Then, based on their user ID, or role and group, they are:
|
Database Servers |
The purpose of this security checkpoint is to ensure that the configured database user ID for the Data Adapters has appropriate access to connect to the back-end database servers and access data. The connecting user credentials can, in some cases, be passed to the databases to leverage data-level security, if enforced at the database level. |
At each security checkpoint, there are several authentication methods from which to choose. These authentication methods impact the choice of a Security Provider and Data Adapter security configuration and are summarized below.
On the WebFOCUS Client:
On the WebFOCUS Reporting Server:
The authentication checkpoints do not operate in isolation and can be integrated to provide a complete security solution based on requirements. The question then becomes, "What authentication and authorization method should I choose at each of these checkpoints to meet my requirements?"
For purposes of this documentation, assume that an authenticated user to WebFOCUS can be an application user ID or an individual user ID.
To start, we need to understand the following:
These requirements drive the choice of a Security Provider and Data Adapter security setting. For example, the more commonly used Reporting Server Security Providers are typically used as follows:
Customers sometimes have a need to support mixed authentication. The Alternate zone feature was designed to support multiple authentication methods. However, it is based on the web browser IP address, so it can require extensive maintenance and administration. The following guidelines should be used when leveraging the Alternate zone feature.
The last two guidelines are best explained with an example. Assume the following:
We will configure the Alternate zone for the internal users and the Default zone for the external users for the following reasons:
Information Builders |