Editor security scenarios and examples
This topic describes various authorizations that can be implemented for the Situation Editor, the Object Editor, and the ISPF Editor using SAF profiles.
KOBUI.ADMIN.editor
KOBUI.ADMIN.editor.UPDATE
where editor is SITEDITOR for the Situation Editor, OBJECTEDITOR for the Object Editor, and ISPFEDIT for the ISPF Editor.To be authorized for an editor resource, a user or group must be permitted READ (or UPDATE) access to the associated resource profile; for editor profiles, both READ and UPDATE access provide the same capability.
In addition to these resources, security for the editors can also be impacted by profiles defined with generic or masked resources. This topic describes the various profiles and implementations that can impact security for the editors and provides example scenarios.
- Related links
- Define editor profiles to control access to the editors
Authorizing access with generic profile definition
KOBUI.ADMIN, a pattern that is used to protect various enhanced 3270 user interface administrative activities. Using this resource pattern, the administrator can control access to all administrative functions that are protected by SAF verification by defining a profile for KOBUI.ADMIN.**.
- The following profile definition allows users access to the various administrative activities:
RDEFINE classname KOBUI.ADMIN.** UACC(READ) - The following profile definition denies users access to the various administrative activities:
If this profile withRDEFINE classname KOBUI.ADMIN.** UACC(NONE)UACC(NONE)exists in your resource class, it would deny access to an editor if the corresponding editor profile is not defined. You can define the following profile to allow the use of the editor profiles before restricting access to the editors:RDEFINE classname KOBUI.ADMIN.editor.* UACC(READ)
Authorizing access with editor profile definitions
- To allow users to invoke the editors and make updates using the editors, define the profile (or profiles) as follows, depending on your implementation:
orRDEFINE classname KOBUI.ADMIN.editor UACC(READ)RDEFINE classname KOBUI.ADMIN.editor UACC(READ) RDEFINE classname KOBUI.ADMIN.editor.UPDATE UACC(READ) - To deny access to the editors, define the profile (or profiles) as follows, depending on your implementation:
orRDEFINE classname KOBUI.ADMIN.editor UACC(NONE)RDEFINE classname KOBUI.ADMIN.editor UACC(NONE) RDEFINE classname KOBUI.ADMIN.editor.UPDATE UACC(NONE)Note: If access to the resourceKOBUI.ADMIN.<editor>is denied, then users cannot invoke the editor, regardless of the defined access to resourceKOBUI.ADMIN.<editor>.UPDATE. - To allow all users to only browse using the editors and deny the ability to make updates, define the following profiles:
RDEFINE classname KOBUI.ADMIN.editor UACC(READ) RDEFINE classname KOBUI.ADMIN.editor.UPDATE UACC(NONE)
Permitting access to a user or user group
- Option 1: Users can either invoke and make updates in the editors, or cannot access the editors
- With this option, a user either has full access to the editors (including the ability to make updates), or no access; a user cannot be allowed browse-only access.
This implementation uses only the following profile for each editor to secure:
KOBUI.ADMIN.editorImportant: If a profile exists for resourceKOBUI.ADMIN.editor.UPDATE, this implementation does not apply. Instead, see Option 2.- To allow a user or group to invoke and make updates in the editor, enter the following command for the respective editor:
PERMIT KOBUI.ADMIN.editor ID(userid) ACCESS(READ) CLASS(classname)Note: To save updates in the Situation Editor or the Object Editor, the user must also have access to the underlying tables, which are protected by resourceO4SRV.**, where O4SRV is a qualifier for monitoring server tables. - To deny a user or group from being able to access the editor, enter the following command for the respective editor:
PERMIT KOBUI.ADMIN.editor ID(userid) ACCESS(NONE) CLASS(classname)
- To allow a user or group to invoke and make updates in the editor, enter the following command for the respective editor:
- Option 2: Users can make updates in the editors, can only browse in the editors, or cannot access the editors
- With this option, a user can be authorized to make updates in the editors, to only be able to browse in the editors, or to be denied access.
This implementation requires both of the following profiles for each editor to secure:
KOBUI.ADMIN.editor KOBUI.ADMIN.editor.UPDATE- To allow a user to invoke and make updates in the editor, enter the following commands:
PERMIT KOBUI.ADMIN.editor ID(userid) ACCESS(READ) CLASS(classname) PERMIT KOBUI.ADMIN.editor.UPDATE ID(userid) ACCESS(READ) CLASS(classname)Note: To save updates in the Situation Editor or the Object Editor, the user must also have access to the underlying tables, which are protected by resourceO4SRV.**, where O4SRV is a qualifier for monitoring server tables. - To allow a user to invoke and only browse in the editor, enter the following commands:
PERMIT KOBUI.ADMIN.editor ID(userid) ACCESS(READ) CLASS(classname) PERMIT KOBUI.ADMIN.editor.UPDATE ID(userid) ACCESS(NONE) CLASS(classname) - To deny a user or group from being able to invoke the editor, enter the following commands:
PERMIT KOBUI.ADMIN.editor ID(userid) ACCESS(NONE) CLASS(classname)
Note: If access to the profileKOBUI.ADMIN.editoris not permitted, then the user cannot invoke the editor, regardless of the permitted access to profileKOBUI.ADMIN.editor.UPDATE. - To allow a user to invoke and make updates in the editor, enter the following commands:
Examples
The following examples show various implementation scenarios for securing the Situation Editor, Object Editor, and ISPF Editor in the OMEGAMON enhanced 3270 user interface. Each editor must be secured separately.
The following examples use the resource class $OMEGZOS. For the enhanced 3270 user interface, the SAF general resource class to use is customizable and is specified in parameter RTE_SECURITY_CLASS.
- Example 1
- In this example, security is implemented so that, by default, access to the Situation Editor is denied for all users; only designated users can invoke the Situation Editor to view, create, and edit situations.
Because in this example a profile for resource
KOBUI.ADMIN.editor.UPDATEdoes not exist, any user that is givenREADorUPDATEaccess to the resourceKOBUI.ADMIN.editorcan make updates using the editor. In this case, userOMUSER1is authorized to invoke and make updates using the Situation Editor.RDEFINE $OMEGZOS KOBUI.ADMIN.SITEDITOR UACC(NONE) PERMIT KOBUI.ADMIN.SITEDITOR ID(OMUSER1) ACCESS(READ) CLASS($OMEGZOS) - Example 2
- In this example, security is implemented so that, by default, access to the Object Editor in denied for all users. Designated users can invoke the Object Editor and browse the object groups, while only a select group of users can update the object groups.
Implementation of this scenario requires that profiles for both
KOBUI.ADMIN.editorandKOBUI.ADMIN.editor.UPDATEbe defined. Users that are givenREADorUPDATEaccess to the resourceKOBUI.ADMIN.editor.UPDATEcan make updates using the editor. Users that are givenREADorUPDATEaccess to the resourceKOBUI.ADMIN.editorcan only browse using the editor.The following commands define the profiles so that all users are prevented access to the Object Editor. Then, users in the groupOMEGUSERare authorized to invoke and browse object groups using the Object Editor, while only the administrators in groupOMEGADMNcan make any updates. Note that a user requiresREADorUPDATEaccess to both profiles to be authorized to make updates.RDEFINE $OMEGZOS KOBUI.ADMIN.OBJECTEDITOR UACC(NONE) RDEFINE $OMEGZOS KOBUI.ADMIN.OBJECTEDITOR.UPDATE UACC(NONE) PERMIT KOBUI.ADMIN.OBJECTEDITOR ID(OMEGUSER OMEGADMN) ACCESS(READ) CLASS($OMEGZOS) PERMIT KOBUI.ADMIN.OBJECTEDITOR.UPDATE ID(OMEGADMN) ACCESS(READ) CLASS($OMEGZOS)