External Security

This section explains how to implement external security for security managers of CA Top Secret, CA ACF2, and the IBM RACF product.
view122
The implementation procedures in this section are only examples. The examples give complete authority to all users. The CA View administrator and the security administrator must work cooperatively on the implementation, and decide which are the appropriate settings for the environment.
CA View bases external security authorization on a resource type and a resource name, where:
  • The resource type represents a predefined name, and the resource name identifies the data being accessed in the CA View database.
  • The resource type and the resource name correspond to the class and entity parameters of the RACROUTE macro.
If a user is not authorized to access specific data in the CA View database, a violation is recorded.
Use a wildcard character to request only specific data to minimize the impact on performance.

Initialization Parameters

Four initialization parameters affect the operation of external security.
  • SECURITY=EXTERNAL
    The SECURITY initialization parameter indicates whether database security is based on external security calls. When the SECURITY initialization parameter is set to EXTERNAL, user and resource verification is performed through an external security product (RACROUTE calls).
  • SECTRAN=
    If you use external security (RACF, CA ACF2 Security, CA Top Secret Security) and the report id contains characters from the extended special character set, you must set SECTRAN=YES. This setting causes the extended special characters to be automatically translated to ‘_’ underscores before the RACROUTE security call.
     
    Note:
     For more information about this parameter, see 
    Character Translations
     later on this page.
  • SECID=
    secid
    The SECID initialization parameter specifies a one- to eight-character identifier that prefixes the resource name. The default of the SECID initialization parameter is VIEW.
  • SECLIST=NONE|ALL|REPORT,INDEX,DEFINE,JOB
    The SECLIST initialization parameter specifies whether selection lists are to be limited to data accessible by the user.
    NONE indicates that all of the selection list data is presented to the user and accessibility is determined after the user selects the data.
    ALL indicates that all of the selection lists are to be limited to data that is accessible by the user.
    REPORT, INDEX, or DEFINE identify specific selection lists that are to be limited to data accessible by the user.
    • REPORT corresponds to the SYSOUT/Report Selection List
    • INDEX corresponds to the Index Name and Value Selection Lists
    • DEFINE corresponds to the User, SYSOUT, Distribution, Device, Filter, and View Definition Selection Lists.
    • JOB corresponds to the Job Selection list.
    You can specify any combination of REPORT, INDEX, DEFINE, or JOB. The default for SECLIST is NONE.
For databases that are versioned from an earlier release, the previous ACF2 and RACF initialization parameters determine the settings of the SECURITY and SECID initialization parameters.
If the ACF2 or RACF initialization parameter is specified, SECID is set to that initialization parameter specification and SECURITY is set to EXTERNAL. Otherwise, SECURITY is set to INIT.
For reference purposes in this section, 
secid
 is used to identify the security identifier specified on the SECID initialization parameter.

The SARFSS BYPASS Startup Parameter

By default, the SARFSS started task bypasses security to access datasets in the JES spool. To disable the security bypass, specify the SARFSS
BYPASS=NO
startup parameter.
The following example shows how to set the BYPASS parameter:
//STEP1 EXEC PGM=SARFSS,PARM=('BYPASS=YES|NO')
If you do not specify BYPASS, or if you specify
BYPASS=YES
, then SARFSS bypasses security to access datasets in the JES spool.
If you specify BYPASS=NO, then you must accept the following:
  • SARFSS will not bypass security.
  • You must define security rules that allow SARFSS to acccess datasets in the JES spool.

Changes to View 2.0 External Security

The security package in CA View has extensive and complete security calls that are made for every end-user database access.
Beginning with r11, external security uses Resource Names (as compared to CA View 2.0 that used pseudo data set names). Release 11 also introduced 33 new security call functions. Some of these functions were new, such as Print Index and Create Banner. Some functions related to functions that did not require security, such as, Define Device and Create Annotation.
Security calls were added to SARMFP (the Microfiche Processing Utility) and to SARSAM (the SAR Database Access Method).
SARMFP now requires 
read 
authority (Function Code - CPLFSSL SYSOUT List) to migrate any SYSOUT to the microfiche output file. A SYSOUT cannot be migrated if access authority fails -- in that case the SYSOUT is bypassed.
SARSAM now requires 
read 
authority for any sub-file based functions, specific to the sub-file type.
  • Reading a panel sub-file requires 
    read 
    authority (Function Code 56 - CPLFPACC - Access On-line Panel).
  • Reading a banner sub-file requires 
    read 
    authority (Function Code 52 - CPLFBACC - Access Banner Page).
  • Reading a resource or SYSOUT sub-file requires 
    read 
     authority for both the sub-file (Function code 4 - CPLFBRS - Browse SYSOUT) and 
    read
     authority to all pages (Function code 26 - CPLFAPGS - Access All Pages).

Resources and Authorizations

The product manages security with a single security class (CHA1VIEW) and fourteen resource types. Each resource type corresponds to data within the database or a database function as shown in the following table.
 
Resource Type
 
 
Resources Protected
 
BANR
Banner page members
DBAS
SARDBASE functions
DEV
Device definition (DEF DEV command)
DIST
Distribution definition (DEF DIST command and user definition distribution identifier)
FILT
Filter definitions (DEF FILTER command)
IDXN
Index name
IDXV
Index value
JOB
Job
NOTE
Annotations and bookmarks
PANL
Online panel members
REPT
SYSOUTs/Reports
RAPS
All pages of a SYSOUTt/Report
SYS
SYSOUT definition (DEF SYS command)
USER
User IDs (DEF USER command)
VIEW
Logical Views
Internal security is mapped into four levels of access to be compatible with the external security managers. The levels are inclusive, a higher access level implies all lower levels. All lower levels are implied even when using CA ACF2, because of the nature of the product's SAF calls.
 
RACF
 
 
CA Top Secret
 
 
CA ACF2
 
 
Description
 
READ
READ
READ
Read access to resource data.
UPDATE
UPDATE
UPDATE
Update access to resource data
CONTROL
CONTROL
DELETE
Special update access
ALTER
ALL
ADD
Delete or rename resource data
For reference purposes, the RACF access levels are used.
The resource name is formatted with information that pertains to the resource type. The following table identifies the structure of the resource name.
 
Resource Type
 
 
Data Type
 
 
Resource Name
 
BANR
Banner page members
 
secid.
BANR
.member
 
DBAS
Database
DBAS
.dbhlq
 
DEV
Device
 
secid.
DEV
.devicename
 
DIST
Distribution definition (DEF DISTID command) and user definition distribution id
 
secid.
DIST
.distid
 
FILT
Filter
 
secid.
FILT
.filtername
 
IDXN
Index name
 
secid.
IDXN
.indexname
 
 
Note: 
Blanks, asterisks ("*"), and ampersands ("&") within the index name are translated to underscores ("_"), plus signs ("+"), and exclamation points ("!") respectively. This translation allows resource validation with all security products.
IDXV
Index value
 
secid.
IDXV
.indexname.indexvalue
 
 
Note: 
Blanks, asterisks ("*"), and ampersands ("&") with in the index name and value are translated to underscores ("_"), plus signs ("+"), and exclamation points ("!") respectively. This translation allows resource validation with all security products.
JOB
Job
secid.JOB.
jobname.owner
 
 
owner
 specifies the user id that submitted the job.
NOTE
Annotation and bookmarks
 
secid.
NOTE
.type.access.creator.notename
 
 
type
 indicates the type of note
"A" for annotation or
"B" for bookmark
 
access
 indicates the visibility of the note
"U" for private or
"P" for public
 
creator
 indicates the user ID that created the annotation or bookmark.
PANL
Online panel member
 
secid.
PANL
.member
 
REPT
SYSOUT/Report
 
secid.
REPT
.reportid
 
RAPS
SYSOUT/Report
 
secid.
RAPS
.reportid
 
SYS
SYSOUT definition
(DEF SYS command)
 
secid.
SYS
.sysoutid
 
 
Note: 
An asterisk ("*") that ends a generic sysout identifier is translated to a plus sign ("+"). This translation allows resource validation with all security products.
USER
User ID
(DEF USER command)
 
secid.
USER
.userid
 
VIEW
Logical view
 
secid.
VIEW
.num.type.viewid
 
 
num
 - three digit numeric logical view number from 000 to 255
 
type
 - type of logical view.
"G" for global view,
"P" for public view, or
"U" for private view.
 
Note: 
An asterisk ("*") that ends a generic view identifier is translated to a plus sign ("+") to allow resource validation with all security products.
The DBAS resource type is the only resource type that does not contain the security identifier.
Certain SARDBASE utility functions can be performed before the initialization parameters for a database are set; therefore:
  • The SARDBASE utility cannot necessarily determine the security identifier for a database.
  • The SARDBASE utility omits the security identifier from the resource name.
  • Security calls for the DBAS resource class are deactivated in the base product.
To implement DBAS security calls, you must use CVDEJCL member BRMSATHX to install the SARATHU1 exit in the CVDEOPTN library.
There is a special case for resource types BANR, DEV, DIST, FILT, NOTE, PANL, SYS, USER, and VIEW that determines whether the function can be performed.
  • To perform a given function at all, the user must at least have READ access to a resource named "
    secid
    .
    resourcetype
    ." for each function.
  • A user, for example, who does not have READ access to "
    secid
    .VIEW." is not able to issue the DEF VIEW command or issue the VIEW command from browse.
You can define "
secid.VIEW
" as a generic resource works but, of course, gives read access to every resource of that type.
To avoid giving this type of access, grant READ access to a non-generic resource: "
secid
.
resourcetype
." instead of "
secid
.
resourcetype
.*" or "
secid
.
resourcetype
.(G)".
 
Resource Type
 
 
Data Type
 
 
Resource Name
 
BANR
Banner page members
 
secid.
BANR
.member
 
DBAS
Database
DBAS
.dbhlq
 
DEV
Device
 
secid.
DEV
.devicename
 
DIST
Distribution definition (DEF DISTID command) and user definition distribution id
 
secid.
DIST
.distid
 

Character Translations

Certain characters that are allowable in report names and other definitions can be treated as 'wildcards' by some security products.
When the following characters appear in a resource name they are translated to the character specified:
All Resource Names
 
Character
 
 
Translated to
 
& (ampersand)
! (exclamation)
* (asterisk)
+ (plus)
%(percent)
| (bar)

Index Names and Values

  • IDXN--Index name secid.IDXN.indexname
  • IDXV--Index value secid.IDXV.indexname.indexvalue
 
Character
 
 
Translated to
 
' ' (blank)
_ (underscore)
* (asterisk)
+ (plus)
& (ampersand)
!(exclamation)
%(percent)
|(bar)

Report Id, SYSOUT Id, Logical View, and distribution id

REPT 
 Report definition
secid.REPT.reportid
RAPS 
All pages of report
secid.REPT.reportid
SYS 
SYSOUT definition
secid.SYS.sysoutid
VIEW 
Logical view
secid.VIEW.num.type.viewid
DIST 
Distribution Id
secid.DIST.distid
   
 
Character
 
 
Translated to
 
' ' (blank)
_ (underscore)
& (ampersand)
!(exclamation)
* (asterisk)
+ (plus)
%(percent)
| (bar)

If SECTRAN=YES Is Specified

The Report Id, SYSOUT Id, Logical View, and distribution id are as follows:
REPT 
 Report definition
secid.REPT.reportid
RAPS 
All pages of report
secid.REPT.reportid
SYS 
SYSOUT definition
secid.SYS.sysoutid
VIEW 
Logical view
secid.VIEW.num.type.viewid
DIST 
Distribution Id
secid.DIST.distid
   
 
Character
 
 
Translated to
 
& (ampersand)
! (exclamation)
* (asterisk)
+ (plus)
% (percent)
| (bar)
‘ ‘ (blank )
_ (underscore)
¢ (cent sign)
_ (underscore)
! (exclamation point)
_ (underscore)
/ (slash)
_ (underscore)
< (less than)
_ (underscore)
( (left parentheses)
_ (underscore)
| (bar)
_ (underscore)
) (right parentheses)
_ (underscore)
; (semicolon)
_ (underscore)
¬ (not sign)
_ (underscore)
¦ (broken bar)
_ (underscore)
, (comma)
_ (underscore)
> (greater than)
_ (underscore)
? (question mark)
_ (underscore)
: (colon)
_ (underscore)
‘ (single quote)
_ (underscore)
= (equal sign)
_ (underscore)
" (double quote)
_ (underscore)

Access Levels

The access level required for the resource type is associated with functions in the SARCPL security block. The SARCPL security block is also passed to the SARSECUX user exit.
This table identifies the access level that is required for each of the resource types for the SARCPL functions.
 
Resource Type
 
 
Access Level
 
 
SARCPL Type
 
 
Function
 
BANR
READ
CPLFBSL, CPLFBACC
Access a banner page member
ALTER
CPLFBDEL
Delete a banner page member
DBAS
READ
SARDBASE IDXOUT function
SARDBASE STATUS function
SARBCH 
UPDATE
SARDBASE BLOAD function
SARDBASE CONVERT function
SARDBASE COPY function
SARINIT function
SARDBASE LOAD function
SARDBASE MERGE function
SARDBASE OLOAD function
SARDBASE REORG function
SARDBASE RESTORE function
SARDBASE SET function
SARDBASE UNLOAD function
SARDBASE VERIFY function
SARDBASE VERIFY function
SARDBASE VERSION function
CONTROL
SARDBASE ADDDS function
ALTER
SARDBASE DELETE function
SARDBASE RENAME function
DEV
READ
CPLFCSL, CPLFCACC
Access device definition
UPDATE
CPLFCMOD
Add or change device definition
ALTER
CPLFCDEL
Delete device definition
DIST
READ
CPLFDSL, CPLFDACC, CPLFDIST
Access distribution definition
UPDATE
CPLFDMOD
Add or change distribution definition
ALTER
CPLFDDEL
Delete distribution definition
FILT
READ
CPLFFSL, CPLFFACC
Access filter rules
UPDATE
CPLFFMOD
Add or change filter rules
ALTER
CPLFFDEL
Delete filter rules
IDXN
READ
CPLFIFL, CPLFIFS
Access index name
IDXV
READ
CPLFISL, CPLFISS
Access index value
JOB
READ
CPLFNASC
Access annotation or bookmark
UPDATE
CPLFJMOD
Change user comments or assigned user ID for job
NOTE
READ
CPLFNASC
Access annotation or bookmark
UPDATE
CPLFNCSC
Add or change annotation or bookmark
ALTER
CPLFNDSC, CPLFNDEL
Delete annotation or bookmark
PANL
READ
CPLFPSL, CPLFPACC
Access an online panel member
ALTER
CPLFPDEL
Delete an online panel member
REPT
READ
CPLFSSL, CPLFBRS
CPLFLD
SYSOUTs/Reports
Load a report from tape
UPDATE
CPLFCHG, CPLFPRT, CPLFOPRT, CPLFTMNT
Print a report or change user field information (online retrieval)
CONTROL
CPLFCHG, CPLFKEEP, CPLFKTAP, CPLFKDEL, CPLFINDX, CPLFCLN, CPLFMIG
CPLFDELD
Keep, re-index, clean, migrate, delete disk, or change (batch retrieval) a report
ALTER
CPLFDEL
Delete a report
RAPS
READ
CPLFAPGS
Access to all page of report
SYS
READ
CPLFYSL, CPLFYACC
Access a SYSOUT definition
UPDATE
CPLFYMOD
Add or update a SYSOUT definition
ALTER
CPLFYDEL
Delete a SYSOUT definition
USER
READ
CPLFUSL, CPLFUACC
Access user definition
UPDATE
CPLFUMOD
Add or update a user definition
ALTER
CPLFUDEL
Delete a user definition
VIEW
READ
CPLFVSL, CPLFVACC
Access a logical view definition
UPDATE
CPLFVMOD
Add or update a logical view definition
ALTER
CPLFVDEL
Delete a logical view definition
The following sections list the steps necessary to implement support of external security with the product. There are descriptions and sample jobs for CA Top Secret, CA ACF2, and IBM's RACF. For simplicity, the examples assume that the SECID initialization parameter is set to "VIEW".

Implementing External Security for CA Top Secret

Follow these steps:
  1. Add the CA View resource types (classes) to the Resource Descriptor Table, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //RDT EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * TSS ADDTO(RDT) RESCLASS(CHA1VIEW) RESCODE(20) + ATTR(LONG,MASK) DEFACC(NONE) + ACLST(ALL,CONTROL,UPDATE,READ,NONE) + /*
     
    Note: 
    CA Top Secret does not normally resolve authority in hierarchies. This depends on how a resource class is defined to the Resource Descriptor Table (RDT). The RDT documentation sample given for CA View resource class CHA1VIEW shown in the previous example does not allow hierarchical access.
    For hierarchical checking, access level masks in the RDT ACLST should be specified in descending hexadecimal order and defined so that CONTROL access includes UPDATE and READ access and UPDATE access includes READ access.
    For example, based on the following ACLST definition:
    ACLST(ALL(FFFF),CONTROL(6400),UPDATE=(6000),READ=(0400),NONE(0000))
    The bit pattern for CONTROL access (6400 = 011001..) includes the bits set for UPDATE (011...) which in turn includes the bit set for READ (01...) access.
     
    Note:
     To support security checking on fully qualified resource names - including characters from the expanded special character set, the CA View resource class has to be defined with the NOMASK and NONGENERIC attributes as follows:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //RDT EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * TSS ADDTO(RDT) RESCLASS(CHA1VIEW) RESCODE(20) + ATTR(LONG,NOMASK,NONGENERIC) DEFACC(NONE) + ACLST(ALL,CONTROL,UPDATE,READ,NONE) /*
    Altering the CA View resource class to NOMASK from MASK makes existing resources un-administrable. Before making such a change, we recommend that all existing permissions and ownerships be revoked and removed, then re-administered after the attribute change.
  2. Create a department to own the resources, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //DEPT EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * TSS CREATE(VIEWDEPT) TYPE(DEPT) NAME('VIEW DEPARTMENT') /* //EXAMPLE JOB ACCOUNT,PROGRAMMER //OWNER EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * TSS ADDTO(VIEWDEPT) CHA1VIEW(VIEW.) TSS ADDTO(VIEWDEPT) CHA1VIEW(DBAS.) /*
  3. Make a profile and permit resource access to it, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //PROFILE EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * TSS CREATE(VIEWPROF) TYPE(PROFILE) NAME('VIEW') DEPT(VIEWDEPT) /* //EXAMPLE JOB ACCOUNT,PROGRAMMER //PERMIT EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * TSS PERMIT(VIEWPROF) CHA1VIEW(VIEW.) ACCESS(ALL) ACTION(FAIL) TSS PERMIT(VIEWPROF) CHA1VIEW(DBAS.) ACCESS(ALL) ACTION(FAIL) /*
  4. Add the profile to a user, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //ADDTO EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * TSS ADDTO(userid) PROFILE(VIEWPROF) /*
Steps for Converting CA View 2.0 CA Top Secret Permissions
Prior to r11, CA View used the DATASET resource class to secure the resources with CA Top Secret.
Starting with CA View r11, a resource class of CHA1VIEW is used. Therefore, the old CA View DATASET permissions are to be converted to the new resource class CHA1VIEW.
Use these guidelines to convert the permissions.
  1. This command generates a list of users with permission to access CA View resources that are to be converted:
    TSS WHOHAS DSN(VIEW)
     
    Note: 
    Prior to CA View r11, the RACF= parameter determined the high level qualifier for the resource names. In the above example, RACF= is shown as 'VIEW'. Replace 'VIEW' with the value you specified for RACF= in your previous CA View release.
  2. Enter the following command to add the resource class CHA1VIEW to CA Top Secret:
    TSS ADD(RDT) RESCLASS(CHA1VIEW) ATTR(LONG,MASK,GENERIC) ACLST(READ,UPDATE, DELETE=E000,ADD=F000) DEFACC(READ)
  3. Enter the following command to secure all CA View resources:
    TSS ADD(owningacid) CHA1VIEW(CAVIEW.)
  4. For CA View 2.0, the following command permits the report 'SALESREPORT':
    TSS PERMIT(acid) DSN(VIEW.SALESREP.$ORT)
    For the new resource class, the following command permits the report:
    TSS PERMIT(acid) CHA1VIEW(CAVIEW.REPT.SALESREPORT) ACCESS(READ)
     
    Note: 
    Starting with CA View r11, a parameter called SECID= determines the high-level qualifier for the resource names. In the above example, SECID= is set to 'CAVIEW'. Replace 'CAVIEW' with the value you specified for SECID=.

Implementing External Security for CA ACF2

For CA ACF2, a unique resource type is assigned for the CA View resource. The mapping of these resource types is identified in the following table:
 
Resource Type
 
 
CA ACF2 Type
 
CHA1VIEW
VCL
<
fts>
 
  1. Map the CA View resource types to CA ACF2 resource types, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //CLAS EXEC PGM=IKJEFT01 //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * ACF SET CONTROL(GSO) INS CLASMAP.CHA1VIEW RESOURCE(CHA1VIEW) RSRCTYPE(VCL) ENTITYLN(246) /*
  2. Tell CA ACF2 about the SAF calls that CA View is making, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //SAFD EXEC PGM=IKJEFT01 //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * ACF SET CONTROL(GSO) INS SAFDEF.CHA1VIEW ID(CHA1VIEW) PROGRAM(SAR-) RB(SAR-) - NOAPFCHK RACROUTE(REQUEST=AUTH,CLASS=CHA1VIEW,STATUS=ACCESS) /*
  3. Make the resource types resident, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //ACF2 EXEC PGM=IKJEFT01 //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * ACF SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RVCL) /*
  4. Enter the modify console commands to cause a refresh, for example:
    F ACF2,REFRESH(CLASMAP) F ACF2,REFRESH(SAFDEF) F ACF2,REFRESH(INFODIR)
  5. Define CA ACF2 rules, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //RULE EXEC PGM=IKJEFT01 //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * ACF SET RESOURCE(VCL) COMPILE 'RULES.PDS(VCL)' STORE /*
  6. Tell CA ACF2 to rebuild the resident rules, for example:
    F ACF2,REBUILD(VCL)
ACF2 cannot be configured to operate in a hierarchical mode. If a non-privileged userid requires UPDATE and READ access to a resource, the ACF2 rule must include UPDATE and READ - UPDATE does not imply READ.
PDS Members
Following is the PDS member.
 
Member
 
 
Contents
 
VCL
* CHA1VIEW RESOURCES
$KEY(VIEW) TYPE(VCL)
- UID(*) SERVICE(ADD) ALLOW
Bypassing Password Verification
Once a user is logged onto one of these online interfaces, you can bypass password specification and allow the user to log on to a CA View database:
  • CICS pseudo-conversational
  • IMS
  • ISPF/cross memory
  • TSO/cross memory
  • ROSCOE/cross memory
To implement this functionality, do the following:
  1. Specify LGNSEC=YES for the cross-memory region startup parameter.
  2. Specify the appropriate SARDEF records for CA ACF2.
For the ISPF interface:
SAFDEF.SAR1 ID(SAR1) MODE(GLOBAL) PROGRAM(SARSPF) RB(SVC019) - RACROUTE(REQUEST=AUTH,CLASS=DATASET)
For the VTAM/XMEM interface:
SAFDEF.SAR3 ID(SAR3) MODE(GLOBAL) PROGRAM(EC2XMDRV) RB(SVC019) - RACROUTE(REQUEST=AUTH,CLASS=DATASET) SAFDEF.SAR4 ID(SAR4) MODE(GLOBAL) PROGRAM(EC2VTDRV) RB(SVC019) - RACROUTE(REQUEST=AUTH,CLASS=DATASET)
 
Note: 
Issue the following ACF2 command to activate the above SAFDEF records:
F ACF2,REFRESH(SAFDEF)
Steps for Converting the CA ACF2 View Access Rule into CA ACF2 View Resource Rule
Starting with CA View Release 11 SAF calls are used to protect CA View resources through external security. Therefore, the CA ACF2 Data Set Access rules that protected these resources in previous releases must be converted to the CA ACF2 Resource Rule.
Use the following guidelines to convert the CA View data set rule into a CA View resource rule.
  1. Issue the following command to decompile the existing CA View access rule into a PDS.
    READY DECOMP view-rule into(rule.pds)
  2. Edit the rule.pds member using any valid utility such as ISPF EDIT to ensure the following rule changes:
    1. Change the record from an access rule to a resource rule.
    2. Convert all access rule lines to include a resource rule SERVICE option and an ALLOW permission and remove the '.$' character string from any rule line.
    3. Add new resource rules for resources that were not a part of previous releases of CA View.
  3. Implement the rule changes in Step 2 as follows:
    • Change the $KEY from an access rule to a resource rule by adding the CA View type code to the $KEY statement. The following example shows how to make this change:
      Existing access rule key name shows (by default the VIEW index parameter is set to VIEW):
      $KEY(VIEW)
    • Convert this access rule key into a resource key by adding the CA View resource type code to the $KEY statement.
      $KEY(VIEW) TYPE(VCL)
       
      Note: 
      The CA View Security documentation explains how to:
    • Change each of the access rules in the member to reflect a resource rule SERVICE option and a valid permission. Remove the '.$' character string from all existing rules. The following example shows how to make this change:
    Access rule line shows:
    REPORTX UID (….) R(A) PRODJOBR.$275 UID(....) W(A)
    Change the rules to reflect a SERVICE option with permission of ALLOW and to remove the '.$' character string:
    REPORTX UID (....) SERVICE (READ) ALLOW PRODJOBR275 UID (...) SERVICE (UPDATE) ALLOW
  4. Add additional rules for new resources. This section documents the new resource names included in this level of CA View. The following example shows how to add these additional resource rules:
    BANR/access level is read PANL/access level is read
    Rule lines reflecting the above resource and access level:
    BANR UID(….) SERVICE(READ) ALLOW PANL UID(….) SERVICE(READ) ALLOW
  5. After the PDS member is changed, compile and store the new resource rule. Use the following CA ACF2 commands to accomplish this step:
    READY SET RESOURCE(VCL) COMPILE 'RULE.PDS'
  6. Test the resulting resource rule using the CA ACF2 resource rule test command.
  7. The CA View resource rule should be defined as a resident rule. The CA View Security documentation shows all the commands needed to define the rule as a resident directory.

Implementing External Security for RACF

The sample jobs can be found in CVDEJCL member SARRACF.
To use RACF to manage CA View external security, do the following:
  1. Create or add code to the RACF Class Descriptor Table. For example, the following job creates a Class Descriptor Table that contains the CA View class name. The table must be assembled and linked as ICHRRCDE. If you have already created one of these tables, you must include it in the link step. Otherwise, remove the INCLUDE SYSLMOD(ICHRRCDE) statement from the link step.
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //CDT EXEC HLASMCL,PARM.C=(OBJECT,NODECK) //C.SYSLIB DD DSN=SYS1.MODGEN,DISP=SHR //C.SYSIN DD * CHA1VIEW ICHERCDE CLASS=CHA1VIEW,ID=128,MAXLNTH=246,FIRST=ALPHA, + OTHER=ANY,POSIT=25,OPER=NO ICHERCDE /* //L.SYSLMOD DD DSN=SYS1.LINKLIB, // DISP=SHR //L.SYSIN DD * INCLUDE SYSLMOD(ICHRRCDE) NEEDED IF ADDING TO AN EXISTING TABLE ORDER CHA1VIEW ORDER ICHRRCDE NAME ICHRRCDE(R) /*
  2. Add the CA View class names to the RACF Router Table, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //EXAMPLE JOB ACCOUNT,PROGRAMMER //RT EXEC HLASMCL //C.SYSLIB DD DSN=SYS1.MODGEN,DISP=SHR //C.SYSIN DD * ICHRFR01 CSECT CHA1VIEW ICHRFRTB CLASS=CHA1VIEW,ACTION=RACF ENDTAB ICHRFRTB TYPE=END END ICHRFR01 /* //L.SYSLMOD DD DSN=SYS1.LINKLIB, // DISP=SHR //L.SYSIN DD * NAME ICHRFR01(R) /*
  3. Activate the new classes, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //CLSA EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * SETR CLASSACT(CHA1VIEW) SETR GENERIC(CHA1VIEW) /*
  4. Define a group to own the resources, for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //AG EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * AG (VIEWADMN) OWNER(SYS1) SUPGROUP(SYS1) /*
  5. To give READ access to all of the functions and ALTER access to all of the resources, run the following job steps:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //RDEF EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * RDEF CHA1VIEW (*) OWNER(VIEWADMN) UACC(ALTER) RDEF CHA1VIEW (VIEW.*) OWNER(VIEWADMN) UACC(ALTER)
  6. Connect a user to the group and alter the user definition (so that its default group is the one you just created), for example:
    //EXAMPLE JOB ACCOUNT,PROGRAMMER //CONN EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * CO (userid) GROUP(VIEWADMN) /* //EXAMPLE JOB ACCOUNT,PROGRAMMER //ALU EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * ALU (userid) DFLTGRP(VIEWADMN) /*
Bypassing Password Verification
Once a user is logged onto one of these online interfaces, you can bypass password specification and allow the user to log onto a CA View database.
  • CICS pseudo-conversational
  • IMS
  • ISPF/cross memory
  • TSO/cross memory
  • ROSCOE/cross memory
To implement this functionality, you must do the following:
  1. Specify LGNSEC=YES for the cross-memory region startup parameter.
  2. Define the SARXMS region to RACF, using the ICHRIN03 table supplied with the operating system.
After setting up the SARXMS region definition and assembling it into the linklist libraries, execute the following RACF commands on TSO/RACF:
AG (PROCGRP) OWNER(SYS1) SUPGROUP(SYS1) AU (SAR60) PASSWORD(PASS) OWNER(PROCGRP) DFLTGRP(PROCGRP)
You must IPL to implement these changes.