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:
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.
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 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.
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.
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:
If group1 were not registered, the user would be assigned the default role.
If user1 is registered in admin.cfg, the server uses the following search path. The lines ending with an asterisk (*) denote a recommended practice:
If the user is registered under a role, the server does not consider group privileges when access to the file or directory is calculated.
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:
Is a user (admin_id) or group (admin_group) name.
Defines the directory or file path.
Can be one of the following:
For example
c:\myapp\app1 c:\myapp\myfile.foc
where * is a token that designates all physical files on the system.
For example:
(APPROOT)\app1 (APPROOT)\ibisamp\car.foc
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.
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
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
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
This is the same as Execute except that it is not shown on the Web Console.
admin_privilege = directory/file_path; PRRUN
This allows the user to view reports from deferred jobs. This privilege is lower than execute.
admin_privilege = directory/file_path; ALIST
This revokes all permissions from the directory or file.
admin_privilege = directory/file_path; ANONE
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:
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
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.
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.
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.
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.
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.
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.
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.
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.
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. |
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.
The Access Control page opens.
The General Properties page opens.
The options are:
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.
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.
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:
When a user tries to perform an action that you have not permitted, a message similar to the following displays:
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.
The Access Control page opens.
The Settings page opens.
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.
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.
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.
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.
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.
The Register Custom Role page opens.
A dialog box opens informing you that a new role will be registered.
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.
The Select Copy Source page opens.
A dialog box opens informing you of the source and destination subjects.
Note:
A server administrator can set selected privileges for basic users, application administrators, and server operators. Configurable options are tailored to each user group.
The General Privilege page opens.
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.
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
The Access Control page opens.
The Register Multiple Users page opens. For information about registering multiple users, see How to Perform Multiple 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.
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.
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.
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.
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:
The Access Control page opens.
The Multiple Groups Registration page opens. For information about registering multiple groups, see How to Perform Multiple Group Registration.
The Register User page opens, as shown in the following image.
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.
The Multiple Groups Registration page opens, as shown in the following image.
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.
This procedure assumes that the user is signed in to the Web Console as a server administrator.
The Access Control page opens.
The PTH Users and Groups Management page opens, as shown in the following image.
Note: You must click Save in order to make these changes permanent.
For a new user, the New PTH User dialog box opens, as shown in the following image:
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:
Note: If you do not click Save, the group will not be saved on the list.
A confirmation dialog box opens.
Note: If you do not click Save, the user or group will not be deleted.
For more information, see How to View or Change Existing User or Group Registrations.
Note: You can also view and change the properties on the PTH Users and Groups Management page.
The Access Control page opens.
The General Properties page opens, as shown in the following image.
Note: If only one user is defined as a Server Administrator, you cannot change that user role.
The user or group is moved to the new role.
The Access Control page opens.
You are prompted to confirm that you want to unregister the user or group.
The user or group is unregistered.
iWay Software |