Configuring Authentication

Security providers must be configured from the Web Console Access Control page.

To switch to security provider LDAP, DBMS, or CUSTOM, you first need to add a new provider under the appropriate security provider on the Access Control tree. When you add a new provider, the server updates configuration file edaserve.cfg with provider blocks named LDAP_PROVIDER, DBMS_PROVIDER, or CUSTOM_PROVIDER. These blocks are inserted with all attributes that apply to the provider type between BEGIN and END dividers.

Security provider PTH is configured during installation of the server and is the default security provider when a newly installed server is started. A server administrator can configure and activate other security providers.

The OPSYS security provider is always on the list of providers. In order to make it an active provider, the server must be authorized (privileged) to start with security OPSYS. There is no need for the additional step of creating a new provider as is needed for LDAP, DBMS, and CUSTOM providers. By default, the effective server administrator ID shown on the Activate Providers page is the server administrator ID. You can change this using the Access Control Settings page. Once the server is installed, you can start adding new PTH users and PTH groups, and you can assign PTH users to PTH groups.

Security provider CUSTOM supports using non-standard security storage. You can create DBMS tables to store users, groups, and passwords. You must then write procedures to read these tables and perform the basic security tasks. This security mechanism has to be created prior to configuring the CUSTOM security provider and must be available when the CUSTOM provider is added to the server provider configuration. It must perform the following standard security tasks:

• Retrieve the user ID and its password to authenticate the user on connecting to the server.
• Retrieve the list of users and groups on user and group registration.
• Retrieve the list of users in each group.
• Retrieve user membership in all available groups.

Once the provider is added, you can change security providers from the Access Control page. Right-click the Security Providers folder and select Activate Providers to switch to a newly added provider. At this point, edaserve.cfg is updated with the security_provider attribute that specifies the provider name.

Multiple security providers can be configured. When you configure OPSYS as one of multiple security providers:

• The server has to be authorized to run security OPSYS, and it needs to have a valid OS user ID and password for starting an agent.
• In a multi-provider security environment that includes an OPSYS security provider, other provider names should not match any domain name reachable by the OPSYS provider.

The Access Control Settings page lets you enter valid OS credentials.

When you configure multiple providers, you choose one to be primary on the Access Control Activate Providers page. Drop-down lists are available for assigning the other providers as secondary providers or inactive. The primary provider defines the security under which the server is running:

During connection to the server, all provider users are connected with a two-part user ID consisting of the provider name and the user ID, for example, MyLDAP\User1 or MyDBMS\User2, where MyLDAP or MyDBMS is the name of a configured secondary provider.

This naming convention is also used when users and groups are registered to server roles. Users and groups are registered with a two-part name. If the PTH provider is a secondary provider, PTH users and groups are registered (and used on connection) as PTH\userid and PTH\groupid.

security_provider = MyLDAP
LDAP_PROVIDER = MyLDAP
BEGIN
  ldap_host = ldaphost
  ldap_port = post 
  ldap_secure_connection = n
  ldap_user_base = dc=ibi,dc=com
  ldap_user_scope = subtree
  ldap_user_class = person
  ldap_user_attribute = uid
   .
   .
   .
END

security_provider = MyDBMS
DBMS_PROVIDER = MyDBMS
BEGIN
  security_dbms = MSSSQL
  security_connection =CON01
END

When security provider OPSYS is configured, the user credentials from the client connection are authenticated by the native security system of the operating system. The server then allocates a data access agent that impersonates the user so that access to files or other objects is controlled by the native system.

Profiles for operating-system users are supported on all platforms. On Windows, Active Directory groups are supported based on the win_primgroup_adsi setting.

Details about OPSYS security requirements are provided in the Server Installation manual, where specific sections are provided for each platform. Refer to this manual for installation instructions and platform-specific setup steps. The following is a summary of the OPSYS requirements:

• On UNIX, the startup tscom300 executable must have root setuid authority.
• On Windows, the server must be started as a service under SYSTEM account (Administrators Group authority) or as a user ID with Windows Administrator authority.

  On Windows, the Server Administrator password is required for this security provider. If the password is not provided in the configuration, the server starts in safe mode and displays a message to that effect. Multiple administrators are allowed. For more information on creating server administrators and other roles, see Registering Users and Groups in a Role.

• On z/OS, the MVS load library must be APF-authorized, and for HFS deployment, certain HFS executables must be given +a authorization.
• On IBM i (formerly known as i5/OS), the ownership of certain library files must be changed to have QSECOFR ownership and, therefore, authority.
• On OpenVMS, the account starting the server must have a specific set of privileges to have proper authorities.

Note that some system specific settings in the edaserve.cfg file are provided to allow further adjustments of the authentication mechanism. Those relevant for some UNIX systems are:

• require_logon_privilege (AIX only. Allows no sign-in IDs to access the server.)
• update_security_db (AIX and HP-UX only. Registers failed sign-in attempts.)

For Windows systems, the logon_method setting (for interactive, network, or batch) is relevant to explicit connections.

Note: For more information on limiting user access to the Web Console, see Configuring General Server and Web Console Actions.

By default, the server installation process establishes PTH security with a PTH server administrator user ID and password. If you deleted the PTH server administrator ID, you can reconfigure PTH security.

The PTH security provider only controls access to the Web Console. When the server is configured for this security provider, there is no impersonation by data agents or authentication of a non-Web Console connected user. From the operating system point of view, all server processes run as a single user ID, and access to the Web Console is controlled by authenticating names against those defined in the admin.cfg file unless authenticate_all_pthuser is set to y. The setting is available on the PTH Security Configuration page, which can be accessed by right-clicking PTH in the Security Providers folder on the Access Control resources tree.

You must configure the Server Administrator password before starting a server configured for a PTH security provider, either by providing it at installation time or by configuring it in the Web Console. For details, see Registering Users and Groups in a Role.

The PTH security provider supports profiles for users and groups on all platforms.

Note: For more information on limiting user access to the Web Console, see Configuring General Server and Web Console Actions.

With a DBMS security provider, there is no impersonation by data agents, but connection credentials are authenticated against a configured DBMS. This technique is called password passthru, as user IDs and passwords supplied by the client are passed to the DBMS for authentication.

A DBMS security provider supports profiles for users on all platforms. Profiles for groups are not supported.

Note: For more information on limiting user access to the Web Console, see Configuring General Server and Web Console Actions.

With an LDAP (Lightweight Directory Access Protocol) security provider, there is no impersonation by data agents, but connection credentials are authenticated against the established directory services. From the operating system point of view, all server processes run as a single user ID.

An LDAP security provider is presently supported on Windows, UNIX, IBM i, and the Unified Server (HFS and PDS deployments).

An LDAP security provider supports profiles for LDAP users and LDAP groups.

Note: For more information on limiting user access to the Web Console, see Configuring General Server and Web Console Actions.

CUSTOM security providers are used when the installation maintains non-standard repositories for users and groups, that is, when the standard methods like OPSYS and LDAP do not apply. An example of such a setup can be having RDBMS tables containing valid user IDs and their encrypted passwords, and also containing the mapping of users to groups. The customer may chose to access these tables using SQL SELECT statements, SQL Stored Procedures, or Web Services. Typically these methods already exist and are used by other non-Information Builders components.

To enable the custom server security provider, the administrator needs to provide code that allows the server security module to perform these tasks:

• Authenticate the user based on user ID and password.
• Obtain all groups for a user (used at run time).
• Obtain all groups in the system (used for administrative actions).
• Obtain all users for a group and all users in the system (used for administrative actions).

The code for performing these tasks is written in the WebFOCUS language as TABLE FILE or SQL SELECT commands against the synonyms representing the SQL table, SQL Stored Procedure, or Web Service. The code can be debugged by running the server with security OFF and running the glue code from application folders. Once debugged, the code is deployed in EDACONF/catalog/custom, and the CUSTOM provider made active.

A tutorial sample called WebFOCUS - Custom SQL Security Provider is available that creates examples of user and group storage and custom procedures that can be used as prototypes. To generate a tutorial, right-click an application on the Application page, point to New, and click Tutorials from the context menu.

The Reporting Server can search across multiple LDAP sources, DBMS providers, an OPSYS provider, and a PTH server when authenticating users.

When authenticating or assigning privileges for a provider that is not the primary provider, the user ID is a two-part name consisting of the provider name and the user ID:

provider\userid

The authentication is done based on a two-part name.

The Server Administrator can add and remove security providers from the list at any time.

For instructions on configuring PTH and LDAP security providers, see Configuring Authentication or Configuring Authentication.

You can enable trusted connections separately for each security provider.

You can configure a security provider to accept trusted connections by setting its trust_ext value to y.

1. Right-click a security provider on the Access Control tree and click Properties on the context menu. This example shows a PTH security provider, but the same setting is available for all security providers.

   The Configuration page for that security provider opens.

2. From the trust_ext drop-down list, select y.

   This setting is available for all types of security providers.

3. Click Save and Restart Server.

When multiple security providers are configured, one must be identified as the default provider for trusted connections when WebFOCUS or other client software sends a trusted group ID without a security provider to the server.

To set the default provider for trusted groups:

1. On the Access Control page, click Access Control on the ribbon, or right-click the Access Control folder and select Access Control from the context menu.

   The Access Control Settings page opens, as shown in the following image.

   
2. You can select a security provider that accepts trusted connections from the trusted_group_default_provider drop-down list. You must select a provider that is configured to accept trusted connections. You can also enter IP addresses to be mapped to a specific provider, if no provider name is supplied by the client.

An authorized server administrator can set an anonymous user ID that can access the Web Console when the user ID/password fields on the Web Console sign in screen are blank and the user clicks Sign in.

This anonymous user ID provides the ID and, in turn, the user rights for the Web Console and the server. Further configuration for the anonymous user can be achieved by creating a user profile for the anonymous user ID. If an anonymous ID matches a user in the admin.cfg list, the applicable role and privileges are applied.

Note: On Windows, for security provider OPSYS only, you must turn IWA security off to use this feature. From the Workspace page, open the Special Services and Listeners folder, right-click TCP/HTTP, and select Properties. Click the Security IWA check box to deselect it.

1. Log on to the Web Console using a user ID that has server administration rights.
2. Click Access Control.
3. Click Access Control on the ribbon.

   The Access Control Settings page opens.

4. Enter a user ID in the anonymous_id field.
5. Enter a password in the anonymous_pass field and repeat it in the confirm password field.
6. Click Apply and Restart Server.

You can configure the following password settings for any security provider:

• View or change the password separator character.
• Enable users to change passwords from the Web Console sign in page.
• Control the start time of warning messages on operating systems that support password expiration.