We have a security role with a few permissions that references security groups that NW owns. We are getting Family Reference validation errors and I was wondering if this is permitted if we get an error for this?
The simple answer is yes. Can you give more information about what Family Reference Validation errors you are receiving and where. Maybe give an example of the permissions you have in a role that is at issue.
It should be valid so long as the referenced security group is in a family that is a valid dependency of the family of your permission.
To figure out if the family is a valid dependency launch Family Definitions and open the family definition for your permission, then confirm if the family of the security group that is being referenced is in the Dependencies subtable.
@martha so an example would be where we wanted to give access to a developer to audit any metadata in the system. That meant that we included a few “sys” security groups in one of our duty roles to enable them to do so.
If this is prohibited, then we would need to remove those security groups from our duty roles.
@stefanus
Including Platform security groups permissions (ie the sysxxxx ones) is not prohibited. However, there is already SYS - Record Audit and a SYS - Unrestricted Audit functional roles that give the ability to see the audit information for all platform security groups. Your nsCox - Developer already includes both of those, so any Cox Developer with that nsCox - Developer has access to record audit information for metadata objects. If that is to much access, say maybe you only want them to have the audit info for sysDevelopment, or you are building some other role, then I would include either sysDevelopmentAuditorRecord or sysDevelopmentAuditorUnrestricted in the functional role you are building rather than create a duty role with they sys permissions in it.
A couple side notes
1.) Having both SYS - Record Audit and SYS - Unrestricted Audit in a functional role is kind of pointless. SYS - Unrestricted Audit gives full access to the audit information where SYS - Record Audit give access only to your own. So the first essentially makes SYS - Record Audit pointless to also have
2.)The reason I recommend adding the base duty or functional roles to a functional role you are building, rather than include the actual sys permissions in a duty role you are building is a.)if you can, you should use base roles, it makes less maintenance on your security if changes are made in the platform roles, b.) duty roles should be as granular as possible, including audit roles with other access is really against that best practice
3.) Keep in mind what @ian.p said above regarding to deliver a functional role or a duty role that has a base permission or role in it, make sure the family dependance is setup to the family the permission or role is in
When I spot checked some of this @stefanus in the environments I suspect this was happening I believe I saw references to security groups which were invalid family dependencies.
@martha alright. It sounds like the SYS – Unrestricted Audit functional role will give us what we are after. This will not form part of the nsCox – Developer role, though.
…and just to clarify, we did not add any base roles to our own, but rather created a permission with audit access for all security groups that were linked to our own duty role.