Group authz involves different group types be understood by authorization manager and criteria based querying and generation.
It's important to understand the different group types we now have and how they relate to authorization. Note that the use of "User" below means non-prived (i.e. not inventory manager) users.
This is the standard, user-created group, or dyna-group. It's mixed or compatible and is associated with roles for use by non-prived users. Its members are visible to any user with roles associated with the group. A user's permissions on the group depends on those permissions set on the relevant roles.
This is a compatible group whose membership is described by its assigned ClusterKey. It is a group that represents a node in the Cluster Tree View. The Cluster Tree View is the group tree for compatible recursive groups. This backing group is a hidden group with a reference to its ClusterResourceGroup. The ClusterResourceGroup is the recursive compatible group at the root of the tree.
A user has the same permissions on an AutoCluster as he does on the root ClusterResourceGroup. So, authorization on the ACBG is performed on the Role-Owned root group, not the ACBG (because the backing group is not associated directly with any roles).
Note that it is feasible, although unlikely, that via additional group-role assignments a user could have greater permissions on the AutoCluster resources as those provided by the ClusterResourceGroup. But, as a simplifying rule we assume that access to the resources through the AutoCluster will deliver only the permissions assigned to the root ClusterResourceGroup.
For example:
Group-A (recursive compat of all AS Servers)
Group-B (compat group of all App-1 WAR resources)
Role-1 has Group-A without Control permission
Role-2 has Group-B with Control permission
User-1 has Role-1 and Role-2
If User-1 navigates to Group-A and then to Group-A's AutoCluster for App-1, he will not be able to perform a group operation on the App-1 resources in the AutoCluster.
If User-1 navigates to Group-B he will be able to perform a group operation on the App-1 resources.
AutoGroup backing groups are private groups. The AGBG is a compatible group whose members are a parent resource's viewable children of a particular resource type. The backing group implementation for AutoGroups is new in 4.0. This approach leverages a single (group) view for all groups, reducing explicit SLSB support for AutoGroups while increasing their power. It is a group that represents a type node in the Resource Tree View. The AutoGroup backing group is a hidden group that is not associated with Roles. Private groups are "owned" by a particular user and have a reference to the relevant Subject. Only that user can access the AGBG. The resource permissions on the AGBG are the intersection of permissions on the member resources.
Relate this back to how ACBG authz works, and state that it would be possible in the future to make the perms for auto-clusters the intersection of permissions on the member resources as well.
So, there are really three distinct types of groups, each with a different mechanism for access authorization and a different mechanism for group resource authorization. Basically, we've got:
ROLE_OWNED
AUTO_CLUSTER
SUBJECT_OWNED
Each has a different way of determining if a user can access the group and what permissions are available to manipulate the group.
We have two different scenarios where Groups and Criteria come together. There are criteria calls for finding groups and criteria calls for filtering on groups.
In 3.0 the CriteriaQueryGenerator handled Role-Owned authz only. It's AuthorizationTokenType.GROUP performs join-based filtering based on role-group-user association. Furthermore, AuthorizationManager handled only Role-Owned and AutoCluster authz.
We need an approach for handling the three types of group authz both in AuthorizationManager and also Criteria queries.
So, after a lot of discussion it seems the best approach, both for simplicity, feasibility, and future flexibility, is to adopt the following guidelines.
AutoClusters and AutoGroups are GUI-Based constructs resulting from tree navigation. Their backing groups have limited use via the CLI.
This is just pointing out that it is not expected that backing groups, or non-visible groups in general, be widely used via the CLI. Authorization will still be in place to ensure proper access. In general, remote clients will, and should, use standard role-owned groups.
Fetching groups by criteria is limited to one authorization group type per call. By default a user retrieves role-owned groups. Specific criteria can be set to access AutoCluster or Private groups. By default filterVisible=true and filterPrivate=false. Note that filterVisible must be set to true or false, a group criteria fetch must return either all visible or all hidden groups. note: This may be refined in the future as currently it is assumed a hidden group search is either for ACBGs or AGBGs.
Fetching group related data, like history, can cross authorization types. Since a user can initiate group actions on any kind of group, they should be able to see those actions in a single view, supported by a single call. Reporting and certain dashboard views are examples of this amalgam history view.
The SLSB layer will hide the authz type distinction from the caller.
API users and also the Criteria class definitions themselves, should be free to support groups without having to understand the authz types.
This means that client-level (gui) code, and domain criteria code, should be affected minimally.
At the SLSB layer there will be conditional support, as needed, for the different authz types. There were two major approaches discussed:
Enhance existing namedQueries and criteria authz fragments to support the various types within a single call. Although it would immediately extend support across our existing code it has two pitfalls: the queries work may be tricky, and perf implications for the disjunctive clauses were unknown, and could possibly differ platform-wise. In short, this approach involves having multiple "GROUP" authorization tokens in the generator, and the proper token is applied as needed.
Provide explicit support (queries, etc) for the different authz contexts. This unfortunately requires entity finds to determine the authz type (when we have only a group id). But within a transaction that should be at most one small, indexed fetch. It also introduces some more conditional coding. But it also ensures simpler support and lean authz queries that are targeted to the authz context we are in. In short this involves a single "GROUP" authorization token in the generator, like today, but one that is updated to handle all types of group authz.
DECISION! After some examination of the queries involved, we have chosen option 1. The query complexity is not as bad as initially thought and it provides the most centralized coverage for existing code. Also, another major deficiency was found for option 2. Criteria queries that needed to go across authz types (like reporting queries) could not be supported in a single db round trip, since each rt could support only one authz type. The amalgam views would be impossible because Hibernate doesn't support unions and we would have had to write the queries as paginationOver(query1 union query2 union query3).
Note that independent of the Criteria Query Generator, AuthorizationManager needs to be made robust. This will require work in the SLSB and, most likely the NamedQueries it uses.
Note that the ResourceManager must enhance the findResourceGroupsbyCriteria and findResourceGroupCompositesbyCriteria handle all cases. The latter call in particular will need new support to correctly supply resourcePermission information.
This is a bit of an aside, but a lot of the criteria classes offering group filtering are in support of group history. This is an area that needs to (and will) see a lot of improvement as it migrates from a strictly top-down group view to a bottom-up group resource member view where group activity is reflected differently. Meaning, a user should be able to see how their viewable resources have been manipulated even if performed as part of a resource or group operation they didn't initiate. The proposed work will not in any preclude this future enhancement
The complexity of the resource/group auth strategy and associated db joins is increasing. Given that inventory and permission changes are relatively rare, a strategy that employs a simpler but more verbose db representation (more rows, less complexity, data redundancy) may be something we should seriously consider. Authorization tuples could be precomputed such that complex joins could be avoided for a majority of common authorization queries.