FS
Documentation

COSmanager/User Guide/COSmanager Users and Access Controls

This page was last modified 06:15, 6 August 2007.

From Documentation

< COSmanager | User Guide(Difference between revisions)
Jump to: navigation, search
Revision as of 03:57, 10 July 2006
Daniels (Talk | contribs)
(COSmanager User Access Controls)
← Previous diff
Current revision
Daniels (Talk | contribs)

Line 23: Line 23:
COSmanager applications ‘interpret’ each one of a user’s roles, to determine what capabilities are granted to the user in that application. COSmanager applications ‘interpret’ each one of a user’s roles, to determine what capabilities are granted to the user in that application.
- +{{Note|By convention, role names are capitalized (Admin, BKP:SeniorOp) and capabilities are not capitalized (rptdistn).}}
-----+
-;Note: By convention, role names are capitalized (Admin, BKP:SeniorOp) and capabilities are not capitalized (rptdistn).+
-----+
- +
Roles can be nested. In duty3g, the Admin role is assigned all the capabilities belonging to the SeniorOp role, plus dutyadmin and runall. In COSreport, the Admin role is assigned all the capabilities belonging to the SeniorOp role, plus maintain. Roles can be nested. In duty3g, the Admin role is assigned all the capabilities belonging to the SeniorOp role, plus dutyadmin and runall. In COSreport, the Admin role is assigned all the capabilities belonging to the SeniorOp role, plus maintain.
Line 35: Line 31:
Roles defined in the COSmanager framework are global; they are available in all COSmanager applications. Roles defined within an application are local to that application. Roles that are mainly used in only one application should be defined in the role table for that application. Roles defined in the COSmanager framework are global; they are available in all COSmanager applications. Roles defined within an application are local to that application. Roles that are mainly used in only one application should be defined in the role table for that application.
-Once a local role is defined, you must assign it to one of the global roles before it can be accessible to a user. In Figure 32 the local role Backupduty is assigned to the global role Operator, therefore users who have the Operator role can view and perform+Once a local role is defined, you must assign it to one of the global roles before it can be accessible to a user. For example, a local role of Backupduty is assigned to the global role Operator, therefore users who have the Operator role can view and perform
in duty3g any duties assigned to Backupduty. in duty3g any duties assigned to Backupduty.
-The access capabilities defined under COSmanager configuration > Users and privileges are used to control access to the COSmanager configuration menus. Application-specific capabilities can be customized under that application’s own configuration menus—for example, capabilities belonging to COS/Sentinel can be maintained under the COS/Sentinel configuration menu.+The access capabilities defined under COSmanager configuration > Users and privileges are used to control access to the COSmanager configuration menus. Application-specific capabilities can be customized under that application’s own configuration menus—for example, capabilities belonging to sentinel3G can be maintained under the sentinel3G configuration menu.
<br> <br>
=== How it works === === How it works ===
-When a user starts a COSmanager application, shell variables are created for each of their roles and capabilities (see [[COSMOS Startup Procedure]]). Access to many functions is controlled by testing for these variables in scripts and menus. +When a user starts a COSmanager application, shell variables are created for each of their roles and capabilities (see [[COSmanager/User_Guide/Overview#COSmanager_Startup_Procedure | COSmanager Startup Procedure]]). Access to many functions is controlled by testing for these variables in scripts and menus.
-For example, in COS/Report the Admin role has the capability rptgen but the Operator role does not. When a user with the Admin role enters COS/Report, a shell variable is created named SEC_RPT_rptgen. In the Report menu on the List of Reports window, COSmanager only displays and lets a user select the option Generate after checking that SEC_RPT_rptgen is set in that user’s environment.+For example, in COSreport the Admin role has the capability rptgen but the Operator role does not. When a user with the Admin role enters COSreport, a shell variable is created named SEC_RPT_rptgen. In the Report menu on the List of Reports window, COSmanager only displays and lets a user select the option Generate after checking that SEC_RPT_rptgen is set in that user’s environment.
Roles group users with similar access requirements and responsibilities. The advantages of this are: Roles group users with similar access requirements and responsibilities. The advantages of this are:
*convenience – it’s easier to assign roles to users to it than it is to individually assign capabilities. *convenience – it’s easier to assign roles to users to it than it is to individually assign capabilities.
*control – access rights are granted according to job functions and responsibilities and not to individual users, making it easier to control security when staff move between jobs or are temporarily unavailable. *control – access rights are granted according to job functions and responsibilities and not to individual users, making it easier to control security when staff move between jobs or are temporarily unavailable.
- 
-<br> 
== How To Control Access to COSmanager == == How To Control Access to COSmanager ==
Line 60: Line 54:
*by assigning roles to a special COSmanager user called DEFAULT. Any UNIX user who is not defined in the COSmanager user table, either in their own right or through their group, receives the roles of the default COSmanager user. *by assigning roles to a special COSmanager user called DEFAULT. Any UNIX user who is not defined in the COSmanager user table, either in their own right or through their group, receives the roles of the default COSmanager user.
-Roles are described in [[COSMOS User Access Controls]]+Roles are described in [[COSmanager/User_Guide/COSmanager_Users_and_Access_Controls#COSmanager_User_Access_Controls | COSmanager User Access Controls]].
 + 
To add a COSmanager user or group To add a COSmanager user or group
*Select COSmanager configuration > Users and privileges > COSmanager users. *Select COSmanager configuration > Users and privileges > COSmanager users.
Line 66: Line 61:
*Press Choose to list groups and user accounts that are not already COSmanager users. Select a user or group. *Press Choose to list groups and user accounts that are not already COSmanager users. Select a user or group.
- +{{Note| COSmanager only lists users whose ID is between minUID and maxUID—that is, non-system accounts.}}
-----+
-;Note: COSmanager only lists whose user ID is between minUID and maxUID—that is, non-system accounts.+
-----+
- +
*Press Choose to list roles. Select one or more roles. *Press Choose to list roles. Select one or more roles.

Current revision

COSmanager has security controls to regulate access by COSmanager users to menus and functions in COSmanager applications.

COSmanager users are UNIX users who have the ability to configure COSmanager or run one or more COSmanager applications.

COSmanager is installed with a set of default roles and capabilities, which you can customize to suit your security policy and organization structure.

This chapter explains how to:


Contents

COSmanager User Access Controls

To access COSmanager, a user must first have a UNIX account on the same host as COSmanager and be registered as a COSmanager user. The user must also have access rights to some or all COSmanager menus and options.

COSmanager access is controlled by assigning to selected users one or more roles. Roles equate to responsibilities shared by some staff. Each role translates to a set of capabilities that determine users’ access to menus and functions in individual COSmanager applications.

COSmanager includes a set of global access roles that are automatically available to all applications. For example, if a user is assigned the global role Manager, they implicitly are assigned all the capabilities belonging to the Manager role in each application you have installed. If instead you want that user to have Manager access in backup3G and sentinel3G only, you would assign those roles explicitly: BKP:Manager and SEN:Manager.

You can also define new roles that are local to an application.

COSmanager applications ‘interpret’ each one of a user’s roles, to determine what capabilities are granted to the user in that application.


Note
Note
By convention, role names are capitalized (Admin, BKP:SeniorOp) and capabilities are not capitalized (rptdistn).

Roles can be nested. In duty3g, the Admin role is assigned all the capabilities belonging to the SeniorOp role, plus dutyadmin and runall. In COSreport, the Admin role is assigned all the capabilities belonging to the SeniorOp role, plus maintain.

Therefore, in COSreport, the Admin role would give a user the capabilities maintain, rptgen, and rptdistn.

Roles defined in the COSmanager framework are global; they are available in all COSmanager applications. Roles defined within an application are local to that application. Roles that are mainly used in only one application should be defined in the role table for that application.

Once a local role is defined, you must assign it to one of the global roles before it can be accessible to a user. For example, a local role of Backupduty is assigned to the global role Operator, therefore users who have the Operator role can view and perform in duty3g any duties assigned to Backupduty.

The access capabilities defined under COSmanager configuration > Users and privileges are used to control access to the COSmanager configuration menus. Application-specific capabilities can be customized under that application’s own configuration menus—for example, capabilities belonging to sentinel3G can be maintained under the sentinel3G configuration menu.


How it works

When a user starts a COSmanager application, shell variables are created for each of their roles and capabilities (see COSmanager Startup Procedure). Access to many functions is controlled by testing for these variables in scripts and menus.

For example, in COSreport the Admin role has the capability rptgen but the Operator role does not. When a user with the Admin role enters COSreport, a shell variable is created named SEC_RPT_rptgen. In the Report menu on the List of Reports window, COSmanager only displays and lets a user select the option Generate after checking that SEC_RPT_rptgen is set in that user’s environment.

Roles group users with similar access requirements and responsibilities. The advantages of this are:

How To Control Access to COSmanager

You can grant COSmanager access to a UNIX user in one of the following ways:

Roles are described in COSmanager User Access Controls.

To add a COSmanager user or group


Note
Note
COSmanager only lists users whose ID is between minUID and maxUID—that is, non-system accounts.


Adding a User Access Role

COSmanager roles should be defined in terms of functions or responsibilities rather than individuals. For example, the Admin function (whether it is done by one person or several) needs access to most or all of the menus; Operators and Auditors need only a few specialist submenus.

You should only add to the COSmanager role table global roles—that is, roles that will be used in more than one COSmanager application. If a role is only useful to a single application it should be added as a local role within that application.


To add a role

  1. Select COSmanager configuration > Users and privileges > Global access roles.
  2. Select Maintain > Add.
  3. Enter a name for the role, relating to the responsibility of the users who will be assigned to it—e.g. ShiftSuper, Training, etc.
  4. Enter a description
  5. Choose from the list of other global roles and application-specific roles.
  6. Press Accept to save this role and exit.


Adding a Capability to the COSmanager Framework

Roles that you define here in the COSmanager framework are global. This means that they are available to be interpreted by any COSmanager application. Capabilities in the COSmanager framework are local—they are only used to control access within the COSmanager configuration menus. In effect the framework is treated like an application.

In the COSmanager framework, capabilities are used to control which users may run COSmanager applications or use the application administration menus. You can change the capabilities assigned to an existing role, or assign capabilities to a new role you have just defined.


To assign capabilities to a role

  1. Select COSmanager configuration > Users and privileges > COSmanager access capabilities.
  2. Select Maintain > Add.
  3. Press Choose to list roles. Select a role that has not already been assigned capabilities.
  4. Press Choose to list the roles and capabilities defined within the COSmanager framework. Select one or more capabilities.
  5. Press Accept to save this role and exit.