Idea Details

Define TSS Facilities in the TSS Security File

Last activity 06-13-2019 09:41 AM
jbaker314's profile image
06-18-2014 05:15 PM

I would like to recommend that CA Top Secret Security for z/OS be enhanced by providing the capability to define TSS facilities in the TSS security file, rather than in the TSS parameter file.

 

I propose that a command of the form "TSS CREATE(facility-accessor-id) TYPE(FACILITY) NAME(facility-name)" be supported.

 

TSS faciity definitions would not be defined within a department, division, or zone, but rather within a special accessor ID, which for the purpose of this enhancement request, I will designate as "*FAC*".

 

Existing attributes of the form [NO]xxxxxxxx would be handled by adding the attribute ("xxxxxxxx") to the facility accessor ID.  If the attribute is not present, it will be treated as equivalent to "NOxxxxxxxx".

 

I suggest that the bypass and protect lists could be managed by permitting the resource to the facility accessor ID with an access level of "BYPASS" or "PROTECT".

 

These access levels would be added to all resource classes whose members can appear in the corresponding bypass or protect list.  These access levels would not be usable on a permit to an accessor ID of any type other than FACILITY.  Likewise, access levels other than BYPASS and PROTECT would not be usable on a permit to an accessor ID of type FACILITY.

 

I would recommend that a new CASECAUT privilege, TSSCMD.ADMIN.FACILITY, be defined and that a permit with an access level of USE would permit an administrative accessor ID to issue a TSS LIST command for an accessor ID of

type FACILITY, while a permit with an access level of PRIVILEG would permit an administrative accessor ID to CREATE, DELETE, and revise an accessor ID of type FACILITY.

 

I am not proposing any capability to have a different set of facilities defined for each system in a complex of systems sharing a common security file.

 

In this proposal, all sharing systems would have the same facility definitions.

 

However, if the user community feels that such a capability is warranted, I would support an extension of this proposal to incorporate such functionality.

 

This proposal would greatly simplify the definition and maintenance of TSS facility definitions.


Comments

11-17-2015 03:27 PM

Hello Everyone! I am pleased to inform you that this functionality has been added to TSS for z/OS r16 and is now available. You can find more details in our documentation here:
CA Top Secret Version 16 Product Enhancements - CA Top Secret® for z/OS - 16.0 - CA Technologies Documentation 

10-24-2014 01:41 PM

I am going to have to disagree with you on this.

 

By using an ACID and associated permits, as outlined in the proposal, an installation is provided an indirect enhancement in that a security administrator can then make use of the TSS WHOHAS command to query the BYPASS and PROTECT lists, a capability not currently available.

 

As currently implemented, if an installation wishes to determine whether a CICS transaction is in a bypass list, the security administrator is forced to issue a TSS MODIFY(facility-ID-8=BYPLIST)) for each CICS facility and examine the output.

 

Please consider a scenario wherein an installation has 100+ CICS regions, each with its own unique TSS master facility.

As you will note, the proposed methodology is much superior.

 

I would further note that as currently implemented, a transaction does NOT have to be owned in order to appear in a bypass list.

 

In this proposal, such will no longer be possible.

10-24-2014 01:20 PM

John, I like the idea of internalizing the Facility Matrix, but I think it works better as an xDT table, at least with regard to lower-compatible syntax. Since FDT is already taken for defining fields, I would propose YDT for faciltY definition. Structurally FACILITY, BYPASS, and PROTECT lists would all be keyed by the FACILITY name, with an additional qualification of CLASS to provide separation of facility resources. (I avoid RESCLASS here to distinguish CICS bypass/protect classes of TRANS TRAN PCT which technically are all connected to RESCLASS OTRAN/LCF).

 

Just trying to be constructive here. The secretary will disavow....

10-10-2014 10:35 AM

I like the idea too.

 

I was just thinking about breaking out the facilities into a seperate member and concatenating them onto PARMFILE DD since I share all the same facilities in the plex but not necessarily the other parms. Anyone know if this can be done? I may give it a shot when I have time with our sand system.

10-08-2014 09:39 AM

I like this idea, would be so much easier to manage the facilities.