Server Security Overview

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.

The Access Control page on the Web Console provides a server administrator with the tools needed to manage server security. Using ribbon buttons and right-click options, the server administrator can perform the following security operations:


Top of page

x
Authentication

Authentication can be performed based on the following types of credentials:


Top of page

x
Security Providers

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 active 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:

After the server is installed, the default security provider configured by the installation process is the PTH (server internal) provider. This provider keeps a list of groups and group membership in the admin.cfg file. During installation of the server, a server administrator user ID is created in admin.cfg. The installer can accept the default user ID (srvadmin) or change it, but the installer must provide a password for this ID. The user ID will be created as a two-part name in the form security_provider\user_ID, for example, PTH\srvadmin.

When the server starts with security PTH, the PTH\srvadmin user ID (or the one configured during installation) is the server administrator user that is used to connect to the Server Web Console, and that user can make additional security changes to the server, such as adding and changing active security providers and changing access control privileges for users, groups, and roles. We recommend that you keep the PTH provider as an active security provider, so user PTH\srvadmin can be used as a backup Server Administrator.

All new security subjects for all security providers will be registered with a two-part name, provider\userid or provider\groupid. For example, the following group named grp1 is registered under the LDAP1 security provider:

LDAP1\grp1

The following user, whose ID is user1, is registered under OPSYS security in the IBI domain:

OPSYS\IBI\user1

If one-part name registrations exist from a prior release, they are respected and are assumed to be primary provider registrations.

Note: If the silent installation is used, the server administrator user ID with its associated password needs to be provided. If none is provided, the default user ID PTH\srvadmin with the password srvadmin will be configured.

OPSYS security has specific operating requirements in order to be activated. For details, see Configuring OPSYS Authentication.

If you want to use an OPSYS, 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.

Note: In order for a signed-in user to start or manage a server using the edastart command script, the signed-in user ID has to be registered as a server administrator in admin.cfg, even if OPSYS is not an active security provider. This is required in order to protect the server from unauthorized actions by users who can sign in to the system where the server resides.

EDAEXTSEC can be set to OFF in order to override the security provider set in the security_provider keyword of edaserve.cfg and start the server with security OFF. For information on setting EDAEXTSEC in different operating environments, see Platform-Specific Methods for Specifying EDAEXTSEC.

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. For all providers, the user name is a two-part name 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 sign-in time, a user needs to select the security provider name in addition to user ID and password. If a user signs in to the server using the primary provider, the server will automatically prepend the user ID with the provider name, if the user does not supply a two-part name.

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.


Top of page

x
Privileges and Other Authorizations

In this section:

The server supports a large number of objects, and access to them should normally be restricted.



x
DBMS

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.



x
Server DBA

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
Data and Application Folder Access

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.



x
General Server and Web Console Actions

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

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.



x
Roles

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
Registering Users and Groups Under Roles

When the server is installed, the user ID specified as the server administrator 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:


Top of page

x
Encryption

Using the Web Console, you can encrypt passwords in configuration files, enable Secure Socket Layer (SSL) encryption for the TCP/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