Changing ACL Inheritance
It is possible to change the ACL inheritance model used for selected ACLs. Changing inheritance is useful in organizations where only explicitly specified groups should have access to configuration management subprojects, even if other groups have permission to access the parent project.
Use Case for Breaking ACL Inheritance
The use case for breaking ACL inheritance is when only explicitly specified groups should have access to subprojects. Consider the following example:
As illustrated in the diagram, permission is denied everyone for the Global ACL. Group A, Group B, and Group C are the only groups granted permission to the Project ACL. Group D is the only group granted permission to the Subproject ACL.
By default, ACL Inheritance is enabled, which results in Subproject ACL being accessible by Group A, Group B, Group C, and Group D. All of those groups have access to Subproject ACL because users who are granted permission to Project ACL also have permission to Subproject ACL.
However, the use case is that only explicitly specified groups have access to a subproject. In this example, one group named Group D should be the only group able to access Subproject ACL. That use case is true when ACL Inheritance is changed (see Changing ACL Inheritance).
Key Considerations When Breaking ACL Inheritance
The following are key considerations when breaking ACL Inheritance:
• There may be a large number of permissions and groups in an ACL. Changing ACL inheritance impacts all of those permissions and groups.
• Some organizations may have groups that need access to all configuration management projects and subprojects. Breaking ACL inheritance requires explicitly granting permission to those groups for each project and subproject they need to access.
• When ACL inheritance is broken for an ACL (the ACL Inheritance submenu check mark is cleared for the selected ACL), only Integrity Administration Client 10.7 (and later) can modify that ACL.
Determining ACL Inheritance Status
To determine the inheritance status of an ACL, select the ACL. Then select the ACL menu. If ACL inheritance is enabled, a check mark appears beside the ACL Inheritance submenu. If ACL Inheritance is broken, there is no check mark displayed beside the ACL Inheritance submenu .
Changing ACL Inheritance
To change ACL inheritance in the Administration Client, first select the ACL. Then select > . If ACL Inheritance is enabled, a check mark appears beside the submenu. If ACL Inheritance is broken, the check mark is cleared.
Impact on Development Path Inheritance
Changing ACL inheritance has an impact on development path inheritance. Consider the following example:
This example is an extension of the one in Use Case for Breaking ACL Inheritance. In this example, Variant Subproject ACL does not have permissions specified.
By default, ACL inheritance and devpath inheritance is enabled, which results in Variant Subproject ACL still being accessible by Group A, Group B, Group C, Group D and Group X. All of those groups have access to Subproject ACL because users who are granted permission to Project ACL also have permission to Variant Subproject ACL, even when no groups are granted permission to Variant Subproject ACL.
However, the use case is that only explicitly specified groups have access to a subproject. In this example, only Group D should have access to Subproject ACL. That use case is true when ACL Inheritance is broken and devpath inheritance is still enabled.
