Configuring Privileges and Other Authorizations

In this section:

WebFOCUS users are authenticated against one of the supported authentication sources (OPSYS, LDAP, DBMS, PTH internal, or CUSTOM). The underlying security system may divide users into groups. For example, for OPSYS security the groups are defined in the operating system, and in LDAP they are defined in the LDAP database. With a PTH security provider, the server file named admin.cfg defines groups. A CUSTOM provider executes custom requests against user-defined security storage, for example an SQL database.

To assign privileges to server application and data files, you must register groups of users to a server role and customize the privileges. In exceptional cases, you may register individual users to a server role and customize its privileges. The authorizations then depend on the privileges assigned to the role.

With any type of security, access to the following categories of resources must be controlled:

The Server provides an Access Control function that enables the Server Administrator to create and edit permissions for different categories of users and groups. These permissions define whether specific users and groups can read, write, and/or execute WebFOCUS repository files and perform various Web Console system functions. To open the Access Control page, select Access Control on the Web Console menu bar.

In addition to users and groups, the server supports security subjects called roles. The server comes with a set of standard roles, and these roles come with a fixed set of general privileges. For more information about these standard roles, see Configuring Roles.

The Server Administrator can register roles, groups, and users. When registered, they are assigned a set of general privileges and file access privileges. By default, groups inherit privileges from the roles they are assigned, and users inherit their privileges from the groups or roles to which they are assigned. The Server Administrator can create new roles and customize privileges for any role, group, or user. The Server Administrator always has full privileges, and those privileges are not adjustable.

It is considered good practice for a large user community to define access rules on the group level and not on the individual user level. This technique allows volume user provisioning to be handled outside of WebFOCUS Server software (for example in the LDAP server). The WebFOCUS Server in general registers group access rights, plus some individual users as an exception, such as managers or special project people.

The following defines the order of precedence for access rights:


Top of page

x
Configuring DBMS Authorization

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.

For more information about the CONNECTION_ATTRIBUTES command, see the Adapter Administration manual.


Top of page

x
Configuring Server DBA Security

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.


Top of page

x
Calculating Privileges for Any Registered or Unregistered User or Group

The server administrator can calculate the privileges of any registered or un-registered user or group on the server by right-clicking the Access Control tree and selecting Show Privileges from the context menu.

The Show Privileges page opens.

You can select a security provider and whether to show the privileges of a user, group, or role under that security provider. You must enter a valid ID for the user, group, or role.

You can enter an unregistered user or group, then the server will calculate the privileges based on user membership and its group registration.

When you click Next, the server calculates the appropriate privileges and returns a page of Properties for registered users and groups with tabs for General Privileges and File/directory Privileges. This page also indicates whether the security subject you chose is registered and, if not, which privileges it inherits. If your server is configured with profile_setting=all, and you select a user who belongs to multiple registered groups, the privileges of all will be combined in the display.


Top of page

x
Permissions for Server Application Files and Directories Using a Non-OPSYS Security Provider

Reference:

The Server Administrator can specify read/write, execute, and list privileges for files in application directories and for the directories themselves. This control is in addition to operating system file access control which follows the current umask setting.

The Server Administrator can view or edit File and Directory privileges by clicking the Directory/File Privileges tab on the Access Control page for a role, group, or user. The Server Administrator can view and edit General privileges for other users, groups, and roles.

Non-Server Administrator users can right-click any object on the left panel and select Properties to see their privileges for that file or directory object. The Server Administrator has the option to manage privileges by right-clicking an object.

By default, for compatibility with previous releases, file access control allows complete access to all files and directories. However, the Server Administrator can reset this default by right-clicking a row in the table and choosing Edit Privileges. For information, see How to Configure General Privileges.

After initial server installation, the Server Administrator should review individual privileges for each role and customize them if needed. For example, the write privileges for basic users to applications on the APPPATH can be removed.

File privileges can be defined on the lowest level, such as a specific file and specific user, but the recommended policy is to define them on the application folder level and on the role and group levels to reduce administrative overhead. Privileges defined on the application level will apply to (be inherited by) all files in this application and by all nested (lower level) application directories, unless overridden on a lower level. The same applies to roles, groups, and users. Privileges defined on the group level will be inherited by the users in the group, unless overridden by explicit user registration.

The following schematic shows the flow of privilege assignments and inheritance.

In effect, when the system opens a file such as app1/app2/car.mas for user user1 in group1 belonging to role1, the server uses a specific search path until the privileges are found. The server administrator can also see the directory and file privileges from the Application Directories page by right-clicking an application and selecting the Privileges option.

Users without administrator rights can see the privileges from the file or directory Properties option.



Example: Search for Privileges for Users Who Are Not Registered

The following describes the search path if user1 is not registered or has not been assigned a role in admin.cfg. Assume the user is in group1 and group1 is registered under role1:

  1. App1/app2/car.mas for group1.
  2. App1/app2 for group1.
  3. App1 for group1.
  4. * for group1
  5. App1/app2/car.mas for role1.
  6. App1/app2 for role1.
  7. App1 for role1.
  8. * for role1.

If group1 were not registered, the user would be assigned the default role.



Example: Search for Privileges for Registered Users

If user1 is registered in admin.cfg, the server uses the following search path. The lines ending with an asterisk (*) denote a recommended practice:

  1. App1/app2/car.mas for user1.
  2. App1/app2 for user1.
  3. App1 for user1.
  4. App1/app2/car.mas for role1.
  5. App1/app2 for role1.
  6. App1 for role1.
  7. * for role1.

If the user is registered under a role, the server does not consider group privileges when access to the file or directory is calculated.



x
Reference: Understanding Access Control Permissions

When file and directory access control privileges are being set, the registration of physical file locations is not saved using a full path reference in all cases. When a location is in a folder under one of the server internal locations EDACONF, EDAHOME, APPROOT, or EDAPRFU, it is registered as a reference that is relative to that server location. The physical paths to EDACONF, EDAHOME, EDAPRFU and APPROOT are defined when the server is installed.

For example, if the privilege is for the directory D:\ibi\srv77\wfsV8\etc, and if the EDAHOME location has been established as D:\ibi\srv77\wfsV8, any privilege registered for that location will be registered using a relative reference based on EDAHOME:

admin_privilege = (EDAHOME)\etc;PRRUN

Then, if a new server release is installed in a different file system, the privilege will be applied to the correct directory in the new file system because the EDAHOME location will contain the correct directory reference for that system.

Registration of files and directories located outside of EDACONF, EDAHOME, APPROOT and EDAPRFU locations are registered as full physical paths.

Access Control parameters are saved in the server admin.cfg file.

{admin_id|admin_group} = name 
admin_privilege = object; privilege_name, privilege_name[, ...] 

where:

name

Is a user (admin_id) or group (admin_group) name.

object

Defines the directory or file path.

Can be one of the following:

  • Physical path to the file or directory.

    For example

    c:\myapp\app1 c:\myapp\myfile.foc

    where * is a token that designates all physical files on the system.

  • A path relative to one of the server internal locations EDACONF, EDAHOME, APPROOT, or EDAPRFU.

    For example:

    (APPROOT)\app1 (APPROOT)\ibisamp\car.foc
privilege_name

Defines the type of access. Can be one of the following:

AREAD reads and displays the content of a file to the user. For example, the user can see (but not change) procedures and synonyms. The user needs read permission to open data files.

ARWRT Write allows the user to read, edit, and write procedures and metadata.

PRRUN Execute. This privilege is typically given to end users who need to execute FOCEXECs and use Master Files and relevant utility procedures. However, the data file used by a FOCEXEC and Master File only requires read permission.

ALIST allows the user to list and view files and folders on the application tree or the output of a deferred execution run.

ANONE revokes all permissions.

Note that definitions in the admin_privilege strings can contain relative path references for application directories under APPROOT and other internal locations. However, fully-qualified physical paths are also respected.



Example: Useful Combinations of Permissions
  1. Full Access - read, write, execute, list

    This setting is typically used by developers on applications that they develop and create directly.

    This is the default for all files not explicitly customized, unless the default is reset. To explicitly specify full access, issue the following setting in admin.cfg:

    admin_privilege = directory/file_path; ARWRT, AREAD, PRRUN, ALIST
  2. Read, execute, and list.

    This permission can be used by developers for other utility application directories that they invoke while developing their own.

    For example, a developer can keep common synonyms and utility FOCEXECs in such a directory. Of course, the person that creates such a directory needs full access to it, but all others only need read and execute. Read is needed to open data files.

    admin_privilege = directory/file_path; AREAD, PRRUN, ALIST
  3. Execute.

    This permission is typically given to end users who need to execute FOCEXECs and use Master Files and relevant utility procedures.

    admin_privilege = directory/file_path; PRRUN, ALIST
  4. Execute and hidden.

    This is the same as Execute except that it is not shown on the Web Console.

    admin_privilege = directory/file_path; PRRUN
  5. List and View.

    This allows the user to view reports from deferred jobs. This privilege is lower than execute.

    admin_privilege = directory/file_path; ALIST
  6. No Permissions.

    This revokes all permissions from the directory or file.

    admin_privilege = directory/file_path; ANONE


Example: Sample Permissions

The privileges for locations relative to EDACONF, EDAHOME. APPROOT, and EDAPRFU are set using the following syntax

admin_privilege=(APPROOT)/baseapp;AREAD, ARWRT,PRRUN,ALIST

However, existing privileges set using the full physical name are respected.

These examples use the following directories and files:

/u1/pgmabb/myapp
/u1/pgmabb/myapp/data1.dat

The following shows a sample permission distribution list:

admin_id = chief_developer
BEGIN
admin_level = APP
admin_privilege = *; ARWRT,AREAD,PRRUN,ALIST
admin_privilege = (APPROOT)/work_app; AREAD,PRRUN,ALIST
END
admin_group = team_developer
BEGIN
admin_level = APP
admin_privilege = (APPROOT)/main_app; AREAD,PRRUN,ALIST
admin_privilege = (APPROOT)/synonym_app ; AREAD,PRRUN,ALIST
admin_privilege = (APPROOT)/work_app; ARWRT,AREAD,PRRUN,ALIST
admin_privilege = /u1/admin/server/prod_data ; AREAD,ALIST
END
admin_group = end_user
BEGIN
admin_level = USR
admin_privilege = (APPROOT)/main_app; PRRUN,ALIST
admin_privilege = (APPROOT)/ synonym_app ; PRRUN
END

These security declarations define the following roles and permissions:



x
Reference: Access Control vs. APP PATH

APP PATH defines two main aspects of the system:

The privileges are on the physical directories, not the application, so if the application is mapped to a different directory, the privileges from the new directory will be in effect.

Note that with Access Control, all such access is subject to Access Control rules which take precedence over APP PATH:

For example, user u1 has the following in his profile where both app1 and app2 contain file xxx.mas, and f1.fex:

APP PATH app1 app2 app3,

In admin.cfg for user u1, access to these applications defined as:

admin_privilege = /u1/app1; AREAD, PRRUN
admin_privilege = /u1/app2; PRRUN
admin_privilege = /u1/app3; ARWRT, AREAD, PRRUN

When user u1 tries to execute the FOCEXEC f1 (EX f1), the one from app1 will be executed.

When user u1 tries to issue TABLE FILE xxx, the app1/xxx.mas will be opened, since it only needs Execute privileges.

When user u1 issues the following command, the app1/xxx.mas will be opened, since it requires Read privileges:

EDAGET MASTER, xxx, T, ANY 

When user u1 tries to issue the following command ENCRYPT FILE XXX, the app1/xxx.mas will be read, and an attempt to rewrite it in place will be made. Since user u1 does not have sufficient privileges, an error will occur and an error message will be issued.

Protection against hacking



x
Reference: Permissions for FOCCACHE and EDATEMP

EDATEMP is a location where the server creates temporary files during agent connection. All of these files are deleted on disconnect to provide a clean environment for the next connection.

FOCCACHE stores temporary files during execution of one Web session. These temporary files can be stored in FOCCACHE for multiple agent connections, and data can be accessed through the Web Console and WebFOCUS Server. FOCCACHE is an internally mapped application directory to a unique physical location for each Web session.

Both of these locations have a full set of permissions for a connected user unless the default location has been overridden by HOLDDATA, HOLDMETA, and remapping of FOCCACHE from its default location using APP commands. In this case, the access controlled permissions are applied based on the admin role, group, or user.



x
Reference: Access Control Implications For Scheduling

The DataMigrator scheduler initiates requests based on procedures (flows) with scheduling headers that it finds in the application path. The procedures are submitted for execution using the user ID and related profiles that depend on the value of the sched_run_id keyword. If the option is set to the following value, the effective server administrator ID is used:

sched_run_id = server_admin_id 

If the option is set to the following value, the user ID found in the flow is used:

sched_run_id = user 

The encrypted password is taken from the admin.cfg file. If the user is registered without a password, trusted connection is used for the LDAP and OPSYS security modes on all operating systems except Windows.

If the installation has a large number of users, it is good practice to protect which procedures the users are allowed to schedule. The method to accomplish this is to define a special application directory, for example schedule_app_1, that contains process flows with scheduling headers only. The actual procedures can be in any other application directory including a home directory, for example app2. The process flows will contain references to the actual procedures, for example:

EX app2/myrpoc

A special scheduling directory such as schedule_app_1 can be protected with file access privileges so that only a designated user ID, for example user1 can write to it and create and modify schedules in it. The user1.prf profile should have app1 in its application path.

The scheduler is configured to scan this application directory by setting the following keyword:

sched_scan_id=user1

This ensures that only the schedules located in schedule_app_1 are in effect and that user1 is the only user controlling the scope of scheduling.


Top of page

x
File Permissions for an OPSYS Security Provider

Reference:

Impersonation is when the server executes code in the context of an authenticated and authorized user. Access to files is controlled by the operating system security features in the native file systems. Files are protected according to the permissions set for the impersonated user.

Users who have server privileges to make configuration changes (update configuration files such as edaserve.cfg, admin.cfg, odin.cfg, or edasprof.prf) must also have operating system privileges to update those files.

The main file areas within a configuration are organized into four locations:

Permissions for new files depend on how the server is installed and started.



x
Reference: Consequences for Files Under the EDAHOME/EDACONF Hierarchy

All users who are expected to use the server must have Read/Execute access to files under the hierarchies. Server administrators that share common resources (such as admin.cfg), should be members of a group that provides writable access to those resources. Non-shared resources should provide each user or group with the specific permissions required.



x
Reference: Consequences for Files Under the APPROOT Hierarchy

Care must be taken when defining default permissions under APPROOT directories for application administrators who will create files that need to be accessed by regular users. When application files are written under any application, they are created according to the rules of ownership and default permissions applicable to the user who signed in to the Reporting Server. Thus, application developers must share a common default group if they are to work on a shared project.



x
Reference: Consequences for Files Under the EDATEMP Hierarchy

In a server that runs with security OPSYS, special conditions apply to the edatemp subdirectory and its contents. The basic principle is that agent subdirectories under edatemp are owned at any given moment by the user that the agent is impersonating.

With an OPSYS provider, this means that once a user connects to an agent, he is explicitly given ownership of his agent subdirectory, regardless of which user the agent impersonated during previous connections. This ownership and the inherited permissions defines how other users can access the connected user temporary files, if at all.

On UNIX, z/OS (HFS deployment), and IBM i, the edatemp subdirectory itself is an exception because it is set up similarly to the /tmp directory. While it allows any user to add files and directories underneath, only the creator of a file can later rename or delete it. Files directly under edatemp (for example, traces) and listener subdirectories are owned by the super user (root, QSECOFR). If edatemp is pre-created or adjusted to an alternate permission, then that permission will be respected. However, be aware that edastart -cleardir will remove the edatemp directory, and therefore necessitate the repeated recreation to the desired permission.

On z/OS (PDF deployment), all temporary files created by a user are based on the rules in the Security package.

On Windows, the permissions of the parent directory of edatemp (usually EDACONF), which were applied when the server was installed, are inherited when edatemp and then the agent subdirectories are created, defining the kind of access other users have to an agent subdirectory and its contents.


Top of page

x
Configuring General Server and Web Console Actions

In this section:

How to:

Reference:

An authenticated user interacts with the server using the Web Console or Data Management Console (DMC). The Server Administrator controls access to the Web Console actions permitted by assigning general privileges to roles and registering users and groups into roles.



x
Procedure: How to Configure General Privileges

General privileges define access to the Web Console and DMC control pages such as the Adapter and DBMS Connections configuration pages, the Metadata creation pages, the Procedure editor and Procedures and Flows Run Options page, and the Server Configuration pages.

These privileges can be reviewed or customized from the Web Console by choosing Access Control on the Web Console menu bar. General privileges can be set on the role, group and user levels. Groups and users registered under any role inherit the general privileges of that role unless they are customized on the group or user level.

Users other than the Server Administrator can see their own general privileges by choosing Show Privileges on the My Console menu. Server Administrators do not have this option because they have full privileges to all pages of the Web Console and Data Management Console.

WebFOCUS procedures can use the CHECKPRIVS() function that, when given a privilege code (for example, NODPT), returns the value Y (yes) or N (no) depending on whether the connected user is has that privilege. For more information, see the Using Functions manual.



x
Reference: General Privileges

The following image shows a sample General Privileges pane for a Basic user, with default values.

The following table describes the general privileges.

Privilege

Description

Adapters

ADPTP

You can configure adapters and add DBMS connection attributes.

NODPT

You can disable Direct Passthru.

NOSYS

You can disable the ability to execute certain operating system commands.

Metadata

METAP

You can launch tools to create and edit metadata.

DATMG

Data Management (allows users to create DBMS tables for the synonym, run Quick Copy, upload to Relational Database, and re-load data).

Procedures

PRSAV

You can launch tools to edit procedures, upload procedures.

PRSTR

You can use the stress tool.

PRDFR

You can Schedule/Email/Submit.

PRRPT

You can view output, DM log and statistics, impact analysis, scheduler and flow reports.

PROUT

You can view log and output of submitted requests.

Workspace

WSCFG

You can perform server administrative functions, such as access control, server configuration and migration, scalability control, and application path control.

GRANT

You can grant file privileges that you have to other users.

MONIT

You can monitor agents, sessions, connections, and services for all users.

KILAL

You can kill and stop agents, sessions, connections, and services for all users.

SRVLG

You can view server logs and traces, and you can create Savediag.

STPSV

You can stop and restart the server.

RARGP

You can use Resource Analyzer and Resource Governor.

My Console

CHGPW

You can change your password.

MONUS

You can monitor Data Service Agents that match your user ID.

MONGR

You can monitor Data Service Agents that match your group ID.

KILT3

You can kill Data Service Agents that match your user ID.

KILGR

You can kill Data Service Agents that match your group ID.

APATH

You can change your application path (no applock).

UPROF

You can edit your user profile.

DBMSC

You can manage your own DBMS connections.

UPROF

You can edit your own user profile.

APROF

You can list application profiles.

UINFO

You can disable display of My Console, detailed error messages, sign-in information, list of privileges for the user, server version, console log, help, and the Privileges section of the Properties page for a file or directory.



x
Procedure: How to Control Access to the Web Console and DMC

Authenticated users are permitted to perform certain control operations on the Web Console, depending on their definitions in admin.cfg as Server Administrator, Application Administrator, Server Operator, Basic User, or other custom role defined on the server. Within a given role, additional administration privileges may be applied. As a result, available Web Console features may vary from site to site or between server configurations at a site.

The Web Console or DMC functions available to the user are determined by his role. If a user is not assigned a role, does not belong to a group, or the group is not registered, his access to Web Console functions is based on the default_admin_role setting.

Access to the Web Console is also affected by the security provider in effect:

Security OPSYS. Access to the Web Console is protected by user authentication at the operating system level.

Security PTH. Access to the Web Console is protected by user authentication against the admin.cfg file.

Security DBMS. Access to the Web Console is protected by user authentication against the selected DBMS.

Security LDAP. Access to the Web Console is protected by user authentication against the LDAP (or AD) server.

Security OFF. With security OFF, anyone can access the Web Console, with full, unrestricted use of its features.

Alternatively, if a server administrator has established an Anonymous ID, it can be used to access the Web Console, without an explicitly entered user ID. For details, see Setting an Anonymous User ID.

Access to the Web Console and DMC can be restricted for individual users or for a group of users.

  1. Access the Web Console with a server administrator user ID.
  2. From the Web Console menu bar, select Access Control.

    The Access Control page opens.

  3. Expand a Roles folder.
  4. Right-click a user or group and select Properties.

    The General Properties page opens.

  5. Select a role from the Inherit Privileges from drop-down menu.

    The options are:

    • Server Administrator
    • Application Administrator
    • Server Operator
    • Basic User
    • None. (No access allowed.)

    Select the value you want to apply. If only users defined in the admin.cfg are to be allowed access, select None.

    Note: If the Server Administrator has created custom roles, they will available in the drop-down menu.

  6. Click Update.

Note: If a server administrator has established an Anonymous ID, it can be used to access the Web Console without an explicitly entered ID. For more details, see Setting an Anonymous User ID.



x
Procedure: How to Minimize User Access to the Server Through the Web Console

Users need some access to the Web Console in order to execute procedures and upload files. However, you can minimize their access to the server when they are signed in to the Web Console by implementing the following steps:

  1. Remove all general privileges. Set all disable privileges: NODPT, NOSYS, UINFO.
  2. Set all file privileges for * to Execute and List.
  3. Adjust privileges to applications so they only allow necessary actions.

When a user tries to perform an action that you have not permitted, a message similar to the following displays:



x
Procedure: How to Set the Default Administration Role

A default administration role provides access to Web Console or DMC functions and to the server for users who are not assigned a role, do not belong to a group, or whose group is not registered. It is based on a selected role.

  1. Access the Web Console with a server administrator user ID.
  2. From the Web Console menu bar, select Access Control.

    The Access Control page opens.

  3. Right-click Access Control and select Settings from the context menu, or click Settings on the ribbon.

    The Settings page opens.

  4. Select a role from the default_admin_role drop-down menu in the General section.
  5. Click Apply and Restart Server.


x
Transferring File Permissions With the GRANT Privilege

The server administrator normally provides access control permissions for application folders to groups and users. If the server administrator issues the GRANT privilege to another security subject (role, group, or user), that security subject can then grant its own file permissions to any other security subject,

For example if user A has Read but not Write permission on folder X, he can transfer Read permission to user B. He cannot grant Write permissions to anyone.

Note that if user A loses the permission later on, user B will retain his transferred permission.



Example: Granting Permissions to Another User

In the following configuration, user pgmtst2 is an Application Administrator with the GRANT privilege:

User pgmtst2 has Read, Execute, and List privileges on application app06, while user pgmtst3 has no privileges on this application:

Since user pgmtst2 has the GRANT privilege for this application, user pgmtst2 can edit the privileges for user pgmtst3:

However, the privileges pgmtst2 can edit are only those that pgmtst2 has for this application. Therefore, the ARWRT privilege is not available for editing:

When user pgmtst2 clicks Apply, user pgmtst3 will be assigned Read and List privileges to app06.


Top of page

x
Configuring Groups

Reference:

The Server Administrator registers a group or user within a role that has a set of privileges. Users and groups can be registered for special privileges, both general privileges and file privileges. It is a good practice to assign users to groups and to control groups rather than individual users. The installation has a choice of grouping users in LDAP or using the operating system security mechanism. This grouping is external to the WebFOCUS or server software and must be accomplished by the administrators for those external products. The groups are then registered in the server, and a role is chosen for them. By default, the privileges are inherited from the role in which the group is registered.

At sign-in time, the user group is determined and the proper privileges are assigned. If the user does not belong to any registered group or role, the privileges are taken from the default role. At installation time, the default role is set to Basic User, but the server administrator can change this designation. The default role can be reset on the Access Control General Privileges pages using the default_admin_role keyword.

A group can be assigned a profile stored as groupname.prf. Group profiles support the same syntax as role profiles, which are described in Configuring Roles.

The Access Control page for a user or group has tabs that enable the Server Administrator to view or edit the Application Path, General Privileges, Directory/File Privileges, Administration File, for a user, the list of group memberships, and, for a group, the list of members.

Note: Profile settings affect how groups connect to the server.

To open the Access Control page for a group or user, right-click the group or user and select Properties.

Note that for LDAP security, if the LDAP database contains the email address, it is automatically populated on this page. This requires the ldap_user_email attribute to be set in the LDAP provider configuration

If a user belongs to multiple groups, the server either uses the primary group privileges, allows the user to select the effective group at sign-in time, or merges the privileges from all groups. How the server handles privileges for users in multiple groups is determined by the group_profile setting in the edaserve.cfg file. You can access this setting from the Access Control page by right-clicking the top level of the Access Control tree and selecting Settings. The default value for group_profile setting is to use the primary group. If the security provider is OPSYS, the operating system determines the primary group. For LDAP, the primary group is the first group alphabetically for the user.

GRPLIST is a function that returns a group name or a list of group names (separated by colons) for the connected user. This function is supported for LDAP security with all types of connections. If the group list is empty or there is an error in the function parameters, the function returns blanks.

There are also three &vars (&FOCSECUSER, &FOCSECGROUP, and &FOCSECGROUPS) that store the connected user and its primary group or the list of all groups (if the server is configured with profile_setting=all). These variables are populated by the server and cannot be changed by the application.



x
Reference: Customizing Group Privileges

Although the recommended policy is to control groups, there may be a need to create different sets of privileges for some individual users. If a user cannot be assigned to a group or to a custom role, the user can be registered with any role, and the Server Administrator can customize the privileges as needed. The customization can include general and file privileges, application path, and DBMS connections. Such users should be kept to a minimum.


Top of page

x
Configuring Roles

How to:

The server is shipped with five predefined roles that allow basic operational control. Roles are listed under Access Control on the Web Console menu bar:

The roles come with a fixed set of general privileges as follows:

The default file and directory privileges allow full access.

The Server Administrator can customize the default privileges and can create custom roles and assign them general and file privileges. The only roles that cannot be changed are the Server Administrator role, which always has full privileges, and the NONE role, which has no privileges. If the Server Administrator customizes a role, it displays with the text (Customized) next to its name on the Access Control tree.

Roles can be assigned profiles that are stored in the location identified by the $EDAPRFU variable. The profile for each role is stored as the file named rolename.prf. The following items can be controlled by a profile:

Predefined roles are assigned predefined names:

Name

Description

SRV

Server Administrator

APP

Application Administrator

OPR

Server Operator

USR

Basic User

Note: When a user connects to the server, the role profile is executed after the server profile.



x
Procedure: How to Create a Custom Role
  1. From the Access Control page, either click the Register button at the top of the page or right-click the Roles folder, and select Register Role from the context menu.

    The Register Custom Role page opens.

  2. Enter a name for the role, and click Apply.

    A dialog box opens informing you that a new role will be registered.

  3. Click OK.

    A page opens on which you assign privileges to this new role.

    The page opens to the General Privileges tab, but you can click the Directory/File Privileges tab to assign file and directory privileges.

  4. You can assign privileges by:
    • Checking each privilege you want to assign to this role and then clicking Apply.
    • Clicking Reset to Default Privileges to assign the privileges from the default role to this new role. Then you can edit the privileges as needed.
    • Clicking Copy Privileges from Other Subjects to assign privileges based on other users, groups, or roles.

      The Select Copy Source page opens.

  5. To copy the privileges from one of the listed subjects, right-click the icon on the left of the subject and click Copy.

    A dialog box opens informing you of the source and destination subjects.

  6. Click OK to copy the privileges.

Note:



x
Procedure: How to Set Customized Privileges for Roles

A server administrator can set selected privileges for basic users, application administrators, and server operators. Configurable options are tailored to each user group.

  1. On the Web Console menu bar, select Access Control.
  2. Right-click a role in the navigation pane.

    The General Privilege page opens.

  3. Select the check boxes for the functions you want the role to be able to perform. Configurable options vary by user group.
  4. Click Apply to confirm these setting.
  5. Click Reset to Default Privileges if you wish to revert to the standard privileges assigned to that user group.

Top of page

x
Registering Users and Groups in a Role

How to:

A server administrator can assign specific users the following roles: Server Administrator, Application Administrator, Server Operator, Basic User, or All Users. A server administrator can also create additional roles and select or deselect certain privileges for these users or groups.

The user and group roles are stored in a release independent file called admin.cfg, which is located, by default, in .../ibi/profiles. This location is defined with the server configuration parameter EDAPRFU, which is stored in the edaserve.cfg file. The admin.cfg file should not be shared between servers that run with different security providers.

When registering users and groups under an LDAP or OPSYS security provider, you can retrieve a list of groups and users from the operating system. The list can be filtered to minimize the number of candidates retrieved. The User and Group Description is retrieved when available. This feature is available on Windows, UNIX, iSeries, and zOS/USS.



x
Procedure: How to Perform Single User Registration

This procedure assumes that the user is signed in to the Web Console as a server administrator.

Note that for the PTH security provider, the user first has to be created using the PTH Users and Groups Management page

  1. From the Web Console menu bar, select Access Control.

    The Access Control page opens.

  2. Right-click a role and select Register User from the context menu.

    The Register Multiple Users page opens. For information about registering multiple users, see How to Perform Multiple User Registration.

  3. Click Single User Registration.

    The Register User page displays for providers for which the server does not have support for retrieving user and group lists from the security provider. For example, single registration is used for a DBMS provider or an OPSYS provider on z/OS PDS deployment, as shown in the following image.

  4. Enter a user ID in the User field.
  5. If you use domain names with the user IDs (Windows only), enter the domain name in the Domain field or select one from the drop-down menu (OPSYS only).
  6. Optionally, in the Password and Confirm Password fields, enter the password for the user ID. A password is only required for scheduled runs.
  7. Enter an email address for the user.
  8. Select an administrator level from the Inherit Privileges from drop-down menu. The options are: Server Administrator, Application Administrator, Server Operator, Basic, or None.
  9. Click Register.


x
Procedure: How to Perform Multiple User Registration

User registration can be done for providers that are active.

You can register a single user ID by clicking Single User Registration, which navigates to the Single User Registration page described in How to Perform Single User Registration.

  1. On the Access Control menu, right-click a role and select Register User.

    The Multiple Users Registration page opens, as shown in the following image.

    For multiple users, you can filter the users retrieved by specifying a pattern in one more of the filter entry fields (UserID, Description, Email, and others). The list of filter fields can vary depending on a security provider.

  2. To retrieve all users for the security provider, click Next.
  3. To limit the list retrieved, check the Filter User box. This enables you to enter search criteria.
    1. Enter a User ID search string, for example *abc*, in the User ID field. Depending on the operating system, the User ID search may be case-sensitive.
    2. Optionally, select a domain or enter a search string in the Domain drop-down list.
    3. Optionally, enter a search string in the Description field. The Description search is not case-sensitive.
    4. Click Next.

      The list of users is returned, as shown in the following image, and the role you first selected appears in the Inherit Privileges from drop-down list.

    5. Optionally, select a different role from the Inherit Privileges from drop-down list.
    6. If you want to override the existing registration for the users, check the override the existing registration box.
    7. Either check the boxes for the users you want to register, or click Select All to select all the users on the list.
    8. Click Register.


x
Procedure: How to Perform Single Group Registration

For security PTH, the group first has to be created using the PTH Users and Groups Management page.

This procedure assumes that the user is signed in to the Web Console as a server administrator.

For the OPSYS, LDAP, Custom, or PTH security providers, a server administrator can assign a role to groups of users by following these steps:

  1. From the Web Console menu bar, select Access Control.

    The Access Control page opens.

  2. Right-click a Role from the Roles folder and select Register Group.

    The Multiple Groups Registration page opens. For information about registering multiple groups, see How to Perform Multiple Group Registration.

  3. Click Single Group Registration.

    The Register User page opens, as shown in the following image.

  4. Select the security provider from the Security Provider drop-down list.
  5. Enter a name for the group in the Group entry field.
  6. Optionally, enter a description in the Description entry field.
  7. To establish the privileges for this group, select a role from the Inherit Privileges from drop-down list.
  8. Click Register.


x
Procedure: How to Perform Multiple Group Registration

Before you can retrieve a list of groups from the operating system, LDAP or OPSYS must be the active security provider.

You can register a single group by clicking Single Group Registration, which navigates to the Single Group Registration page, as described in How to Perform Single Group Registration.

  1. On the Access Control menu, right-click a role and select Register Group.

    The Multiple Groups Registration page opens, as shown in the following image.

  2. To retrieve all groups for all domains, click Next.
  3. To limit the list retrieved, check the Filter Group box. This enables you to enter search criteria.
    1. Enter a Group ID search string, for example *abc*, in the Group ID field. Depending on the operating system, the Group ID search may be case-sensitive.
    2. Optionally, select a domain or enter a search string in the Domain drop-down list.
    3. Optionally, enter a search string in the Description field. The Description search is not case-sensitive.
    4. Click Next.

      The list of groups is returned, as shown in the following image, and the role you first selected appears in the Inherit Privileges from drop-down list.

    5. Optionally, select a different role from the Inherit Privileges from drop-down list.
    6. If you want to override the existing registration for the groups, check the override the existing registration box.
    7. Either check the boxes for the groups you want to register, or click Select All to select all the groups on the list.
    8. Click Register.


x
Procedure: How to Manage Users and Groups With PTH Security

This procedure assumes that the user is signed in to the Web Console as a server administrator.

  1. From the Web Console menu bar, select Access Control.

    The Access Control page opens.

  2. Expand the Security Providers folder.
  3. Right-click the PTH folder and select Manage Users/Groups.

    The PTH Users and Groups Management page opens, as shown in the following image.

  4. You can drag users (listed on the left) to groups (listed on the right) or drag groups to users. In addition, you can select a user or group and use the arrows between the two panes to move them.

    Note: You must click Save in order to make these changes permanent.

  5. To add a user or group, click New on the appropriate pane.

    For a new user, the New PTH User dialog box opens, as shown in the following image:

    1. Enter a user ID.
    2. Optionally, enter a description in the Description field.
    3. In the Password and Confirm Password fields, enter a password for the user ID.
    4. Enter an email address for the user.
    5. By default, the password never expires. If you want to set an expiration date, uncheck Password never expires.
    6. If you want to temporarily disable the account, check Account disabled.
    7. Click OK. The user is added to the list.
    8. Click Save.

      Note: If you do not click Save, the user will not be saved on the list.

    For a new group, the New PTH Group dialog box opens, as shown in the following image:

    1. Enter a group ID.
    2. Optionally, enter a group description.
    3. Click Next. The group is added to the list.
    4. Click OK.

      Note: If you do not click Save, the group will not be saved on the list.

  6. To delete a user or group, select the ID and click Delete.

    A confirmation dialog box opens.

    1. Click OK.
    2. Click Save.

      Note: If you do not click Save, the user or group will not be deleted.

  7. To view or change the properties of a user or group, select an ID and click Properties.

    For more information, see How to View or Change Existing User or Group Registrations.



x
Procedure: How to View or Change Existing User or Group Registrations
  1. From the Web Console menu bar, select Access Control.

    Note: You can also view and change the properties on the PTH Users and Groups Management page.

    The Access Control page opens.

  2. Expand a Role from the Roles folder.
  3. Right-click the user or group whose properties you want to view or change, and select Properties.

    The General Properties page opens, as shown in the following image.

  4. You can change the user role by select a different role from the Inherit privileges from drop-down menu. For more information, see How to Configure General Privileges.

    Note: If only one user is defined as a Server Administrator, you cannot change that user role.

  5. Click Update.

The user or group is moved to the new role.



x
Procedure: How to Unregister a User or Group
  1. From the Web Console menu bar, select Access Control.

    The Access Control page opens.

  2. Expand a Role from the Roles folder.
  3. Right-click the user or group and select Unregister.

    You are prompted to confirm that you want to unregister the user or group.

  4. Click OK.

The user or group is unregistered.


iWay Software