In TSS a "group" is just a place to hang a GID for use in OMVS ... although some software vendors use it for other purposes too. But it doesn't get resource permissions; in TSS, a "profile" is a collection of permissions, and it's assigned to multiple users, so I think it's analogous to a group in Active Directory. And I would say it's not very much like a group in RACF.
To implement RBAC in TSS I should think you want (once you’ve created satisfactory naming scheme for your profiles) to have your access-control software maintain a list of profiles that pertain to each role code, and when someone changes roles the software should remove the profiles that relate to the old role and add the profiles for the new role. --- Bob Bridges, [email protected], cell 336 382-7313 /* Americans who travel abroad for the first time are often shocked to discover that, despite all the progress that has been made in the last 30 years, many foreign people still speak in foreign languages. -Dave Barry */ -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Steve Thompson Sent: Friday, August 4, 2023 16:51 Don't know if TSS implements groups. But with groups, I can have access to certain DSNs read only, others update | delete | create. I can have access to console commands from TSO, but not have logon access to CICS. Just as examples. Having to change TSO IDs is problematic because one loses access to their private data sets... (tools you wrote for making ISPF/Roscoe or whatever better...). So role based using group definitions that give one authority until they don't need it (or can't justify it), is what I think you mean and need. --- On 8/4/2023 4:25 PM, Wayne Bickerdike wrote: > To implement this would require systems that implement application > security. The idea that a systems programmer of any type would be able > to perpetrate fraud is a stretch. > > I had access to everything mainframe (RACF, CICS, z/OS) in a top > secret installation. I wouldn't be able to place a purchase order but > I could nuke any dataset. I was also too damn busy doing my job to > compromise the systems. > > The worst case is where staff inherit privileges as they change roles. > That was a problem. Makes a case for role based security. Change roles > > New role based ID. > > --- On Fri, Aug 4, 2023 at 11:34 PM Michael Babcock <[email protected]> > wrote: >> I ran across this in a CICS security admin book (which should also >> apply to z/OS sysprogs): >> >> Roles and separation of duties >> >> A key security principle is the separation of duties between >> different users so that no one person has sufficient access privilege >> to perpetrate damaging fraud. *This configuration is required by >> various audit regulations such as the United States Federal Law known >> as the Sarbanes-Oxley Act of 2002 < >> https://www.ibm.com/links?url=https%3A%2F%2Fwww.govinfo.gov%2Fcontent >> %2Fpkg%2FPLAW-107publ204%2Fpdf%2FPLAW-107publ204.pdf >>> .* >> An example of this separation of duties, is that someone with >> the role of CICS System Programmer must not also have the role of >> RACF Security Administrator. >> >> Does anyone know exactly which section of SOX it's referring to? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
