External Security

The sections that follow demonstrate how to implement external security for the following security managers:
view140
The sections that follow demonstrate how to implement external security for the following security managers:
  • CA Top Secret Security
  • CA ACF2 Security
  • IBM's RACF
CA View performs external security authorization based on a resource type and name:
  • The resource type represents a predefined name, and the resource name identifies the data being accessed within the CA View database.
  • The resource type and name correspond to the class and entity parameters of the RACROUTE macro.
If a user is not authorized to specific data within the CA View database, a violation is recorded.
Note:
Since the CA View external security processing verifies the user's authorization for every object requested, you can minimize the impact on performance by using a wildcard character to request only specific data.
Be aware that the implementation procedures presented in this section are examples only. You must determine what the appropriate settings are for your environment.
These examples authorize all users to do everything. We recommend that the CA View Administrator and the Security Administrator work together to do the implementation as a cooperative effort.
Contents
2
2
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 the following 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
ADMIN
Web Viewer
Administrator
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)
GROUP
Web Viewer
repository groups
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 the following 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
ADMIN
Web Viewer
Administrator
WEBVWR.ADMIN
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
GROUP
Web Viewer
Repository Group
WEBVWR.GROUP.
grpname
grpname
- repository group name (up to 100 characters)
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
indicates the job id that submitted to 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.
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, distribution id, and repository group 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
CPLFJSL, CPLFJACC
Access a job.
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) INS SAFDEF.WEBVR ID(WEBVR) PROGRAM(BPXPTATT) RB(BPXPTATT) - 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)
Note:
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(
EE0
XMDRV) RB(SVC019) - RACROUTE(REQUEST=AUTH,CLASS=DATASET) SAFDEF.SAR4 ID(SAR4) MODE(GLOBAL) PROGRAM(
EE0
VTDRV) 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
Note:
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.