x

Security providers LDAP, DBMS, PTH, and CUSTOM must be configured from the Web Console Access Control page.

Note: NLS characters are supported for user ID, group name, password, and domain name on the Web Console Access Control configuration pages.

To switch to security 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 PTH is available for configuration immediately after installing the server. There is no need for the additional step of creating a new provider as is needed for LDAP, DBMS, and CUSTOM. Once the PTH security provider is configured, 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 Change Provider 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. The Change Provider page requires you to enter valid OS credentials when you configure OPSYS as one of multiple providers:

When you configure multiple providers on the Change Provider page, you choose one to be primary. Check boxes are available for assigning the other providers as secondary providers. The primary provider defines the security mode in which the server is running.

During connection to the server, all primary-provider users are connected with a one-part user ID such as User1 or User2. All secondary-provider users connect with a two-part name 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 of the primary provider are registered with a one-part name, and users and groups of all secondary providers 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.

Top of page

Example: Security Provider Blocks in edaserve.cfg

The following is an example of a security_provider attribute and security provider block for starting the server with security LDAP (provider name MyLDAP):

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 

The following is an example of a security_provider attribute and security provider block for starting the server with security DBMS (provider name MyDBMS):

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

x

With DBMS authorization, the main object to be protected is the DBMS resident data that the server reads and writes. Access control is implemented using ENGINE CONNECTION_ATTRIBUTES statements that define the security attributes that are used by the server agent for connecting to the DBMS. The connection security type depends on the DBMS and can be one of three subtypes:

• Explicit. The userid/password is stored in a profile (encrypted).
• Password passthru. The userid/password combination or cookie, such as MYSAPSSO2, that were provided during the connection to the server is passed to the DBMS connection.
• Trusted. This type of connection applies to security provider OPSYS where the operating system process of the agent impersonates the user, and the DBMS connection is derived from that process.

The CONNECTION_ATTRIBUTES statement itself can be defined in the user, group, role or server profile, and they override each other in this order.

It is common initially to create connections in the edasprof server profile. They will then be inherited by all users. Subsequent configuration steps may define connections on other levels, such as the group or user level.

The CONNECTION_ATTRIBUTES statement in effect passes the credentials to the DBMS, and the DBMS server ensures the correct access control: read and read/write rules on the DBMS tables, views, columns, and rows.

x

The server engine can add an additional level of access control by defining DBA rules in synonyms to restrict access to columns and certain data values. This applies only to data access using the WebFOCUS language, and not to Direct SQL Passthru requests. For more information about Server DBA, see the Describing Data With WebFOCUS Language manual.

x

The server reads operating system files using standard I/O calls.

In the OPSYS security mode, the proper OS read/write privileges should be given using native OS tools such as RACF rules or Windows/UNIX permissions. Run time access control is achieved by the operating system validating the data agent access to any given file based on the agent process impersonation of the connecting user.

To protect files in other modes (LDAP, PTH, DBMS), the server access control feature should be used to assign read/write privileges to OS files and folders. The privileges are managed from the Web Console Access Control page and stored in the server admin.cfg file. They can be assigned at the role, group, and user levels and be allotted on the folder and file levels. Normal inheritance rules apply: a subfolder inherits from its parent folder, a file inherits from its parent folder, a user inherits from the group, and so on.

Note that this protection applies to WebFOCUS metadata objects in application folders such as synonyms, FOCEXECs, HTML files, style files, and to data files such FOCUS data sources and sequential files.

Application folders and files can have four types of privileges: read, write, execute, and list. For data files such as FTM files, only two privileges are used: read and write.

Operating system shell commands should be disabled completely using SET OPSYSCMD, as they are not subject to access control.

x

The Web Console provides various actions, such as adapter configuration, server configuration and monitoring, Resource Analyzer configuration, metadata creation, and other actions, such as the ability to issue Direct SQL Passthru requests. To manage access to these actions, the server administrator uses the server access control feature to assign general privileges to users, groups, and roles.

x

Groups are collections of users typically defined by the security provider for the purpose of giving common authorization to multiple instead of individual users. Groups are defined either on an external repository such as RACF, LDAP, or internal PTH. DBMS mode does not support groups. Except for PTH, user provisioning and all associated administration tasks (such as password reset, invalidating users, volume user creation) are accomplished using the respective security provider software and are outside of the reporting server software.

x

Roles are a collections of privileges defined on the server for the purpose of registering groups and users to the collection (as opposed to assigning privileges to individual users). Five predefined user roles (Server Administrator, Application Administrator, Operator, Basic, and None) are created at server installation time. For example, the Server Administrator role has all privileges, and the Application Administrator role has privileges related to the creation of applications, such as creating synonyms and related tasks.

New roles can be added and existing roles can be modified to include and exclude individual privileges.

At server installation time, file access privileges are created with full access rights (read/write/execute/list) for all roles, in order to maintain compatibility with previous releases.

x

When the server is installed, the installing user is automatically registered as Server Administrator. All other users and groups are defaulted to the server default role—Basic.

Note that no group, user, or role profile exists initially after the installation. It is typical at the initial stage to have the DBMS connections defined in the server profile, edasprof. Privileges are derived from the Basic role and are in effect for all users except the Server Administrator.

Recommended steps for securing the server:

• Review default privileges for role Basic and change them if necessary. You can change the default role to another role.
• Review and change the file privileges for the default role at the file root level.
• Customize groups:
  • Register groups to roles. For example, register LDAP group GRP1 to the Application Administrator role.
  • Create group profiles with DBMS connections and APP PATH. For example, for group GPR1, create grp1.prf (through the Web Console Adapter page or the application path configuration).
  • Customize application level file privileges for groups. For example, group GRP1 can have read but not write access to baseapp.
• Optional steps:
  • Create new roles or customize the role privilege list. This should be done only if existing roles are not satisfactory. It allows registering groups to these roles.
  • Register users. This should be done only if groups are not created adequately, and for special users such as managers.
  • Register file privileges on the file level. This should be avoided in favor of folder level privileges, as they are inherited by files and are easier to manage.