>From what you're describing - you would have 2 RACF groups (ITEMP and ITMGR).. those groups are given access to the resources they need. If ITMGR needs access to things that ITEMP have access too -- then just add them to the ITMGR group. While you can have superior and subgroups, to my knowledge they don't apply to user/resource access - they are used to confer admin privileges (e.g. ITALL would allow someone to administer ITEMP and ITMGR).
When you say 'add the IT managers security group into the IT employees security group' -- the only way to do that is to individually connect the users in ITMGR to the ITEMP group -- and that should work fine as far as I know. Scott Rohling On Fri, Aug 6, 2010 at 8:09 AM, Billy Bingham < [email protected]> wrote: > From a colleague on the vse-l mailing list. > > > Billy > ------- Forwarded message follows ------- > I only just this week discovered that the VSE BSM does not support > group within group security. Meaning, if you have two security groups of > users -- say, IT managers and IT employees -- and you try to include the IT > managers as IT employees just by adding the IT managers security group into > the IT employees security group, then the VSE BSM (as currently implemented) > will not return the correct access levels for the IT managers so defined. > > IBM Level 2 confirmed that this is a restriction of the VSE BSM and, > they think, also of RACF (but they weren't 100% certain). Can anybody > familiar with RACF confirm or deny such a restriction? Can anybody familiar > with other top-notch security products confirm or deny whether those > products, also, sport such a restriction? It seems, to me, that group > within group security would be such a commonplace thing to want to do that > I'm surprised to find that the VSE BSM does not support this. > > Now, I do understand that such a defined sub-group would logically > obtain the same access level as is defined for the main group. I further > understand that in order to obtain a different access level for such a > sub-group that the sub-group would have to be defined directly, as a main > group, to the security resource in question. I also understand that, under > the scenario I've described so far, this would result in the same group > being defined twice to the same security resource -- once as a sub-group > and once as a main group. However, I don't see this as a problem because a > main group definition should logically take precedence anyway. I just > object to having to always define only main groups in order to obtain the > desired security access levels. > > Sincerely, > > Dave Clark > > WinWholesale Group Services > 3110 Kettering Boulevard > Dayton, Ohio 45439 USA > (937) 294-5331 > > > > > ********************************************************************************************* > This email message and any attachments is for use only by the named > addressee(s) and may contain confidential, privileged and/or proprietary > information. If you have received this message in error, please immediately > notify the sender and delete and destroy the message and all copies. All > unauthorized direct or indirect use or disclosure of this message is > strictly prohibited. No right to confidentiality or privilege is waived or > lost by any error in transmission. > > ********************************************************************************************* > ------- End of forwarded message ------- >
