In this section: |
Server security is based on a three step process: authenticating the connecting user, establishing his/her group and role, and then assigning privileges and other authorizations based on the user, group, and role.
Note: NLS characters are supported for user ID, group name, password, and domain name on the Web Console Access Control configuration pages.
Authentication can be performed based on the following types of credentials:
A security provider is used to authenticate the incoming connection. When a security provider is configured, it is added to edaserve.cfg as a security provider block. Multiple security providers can be configured, in which case the security_provider attribute will consist of a comma-separated list of security providers. The first one on the list is the primary provider.
The security provider can be of several types:
Initially, when the server is installed, EDAEXTSEC is not set and no other security provider is configured. Under these conditions, the server, by default, will start configured for an OPSYS security provider if it has sufficient privileges for operating system security. If it does not have sufficient privileges, it will start with security OFF.
If you want to use a PTH, LDAP, DBMS, or CUSTOM security provider, you must configure it on the Web Console Access Control page. When you configure one of these security providers, the server edits the edaserve.cfg file to add a block for the new security provider. You can then use the Web Console to change to this provider. In response, the server sets the security_provider attribute in edaserve.cfg to this provider name, after which this provider is considered the primary provider and defines the security used by the server.
You can configure multiple security providers, and the server will add multiple provider blocks in edaserve.cfg. When multiple providers are chosen to be active, the security_provider attribute in edaserve.cfg is set to the list of active providers. In this case, the first provider on the list is considered to be the primary provider and defines the security used by the server.
EDAEXTSEC can be set to one of two values: OPSYS or OFF. These values can be used to override the security provider identified by the security_provider attribute. The server uses the following information to determine the mode in which it should start:
(EDA13171) UNABLE TO START SERVER
An example of configuring multiple providers is having two distinct LDAP providers configured against two separate LDAP servers that can contain different users and different groups.
One provider is considered the primary provider, and for other providers the user name is prefixed with the provider name, for example LDAP1\usera. Note that users (or groups) from two providers that have identical names (such as LDAP1\usera and LDAP2\usera) are considered different security subjects and can be given different privileges and profiles.
At login time, a user needs to select the security provider name in addition to userid/password.
Note that OPSYS providers can be configured with other security providers. On Windows multiple Windows domains act as different security providers and users. For example, domain1\usera and domain2\usera are not identical.
In this section: |
The server supports a large number of objects, and access to them should normally be restricted.
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:
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.
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.
The server reads operating system files using standard I/O calls.
With the OPSYS security provider, 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.
You can disable operating system shell commands using the SET OPSYSCMD or the NOSYS general privilege, You may want to consider disabling these commands as they are not subject to access control.
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.
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. The DBMS security provider 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.
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.
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:
Using the Web Console, you can encrypt passwords in configuration files, enable Secure Socket Layer (SSL) encryption for the HTTP listener, and encrypt data passed between the server and a remote server. For more information about encrypting communication between the server and the WebFOCUS Client, see the WebFOCUS Security and Administration Manual.
| iWay Software |