More Flexibility for VOB Element Protection

WHAT’S THE PROBLEM?  
 
HCL VersionVault administrators often need to set up access controls on VOB elements to meet their companies’ information security policy.  Operating system groups are a popular way to manage protections: users are assigned to groups, and those groups are used for element access checks. 
 
This works nicely when groups are used for VOB element access control lists (ACLs), introduced in VersionVault 8.0.1, or for UNIX-style mode bit checks based on the VOB element’s group ownership.  However, it only works as long as a single user only needs 16 or fewer groups to access all authorized elements. 

VOB element ACLs can reduce the need for a user to be a member of multiple groups:  instead of having one user with multiple groups accessing elements each with a single group, you configure the ACL to protect elements to be accessible by multiple groups and each user only needs one (or a few) group(s) to access the elements. 
 
For example, a shared component “S” would allow access to the groups representing the teams that consume that component (“A” and “B”) and to the team that maintains the component (“S”).  Then the developers of components A and B only need membership in the respective team-group (A or B), and the developers of the shared component only need membership 
in group S. 
 
But some administrators had extra burdens managing their group membership this way: their organization’s security policy was built around separate groups for each component, with users assigned membership in the groups needed for all components their project used. ACLs could solve the problem technically but the management of ACLs to allow multiple groups per element had a higher administrative overhead than using a single group per element. 
 
In the above example, developers for component A need membership in group A and group S; likewise for B developers. 

 
WHAT’S THE SOLUTION?  
 
VersionVault 9.0.0.4 and later support a mode where the group membership of each user is evaluated on the VOB and view server hosts. The idea is similar to behavior supported by NFS servers: the server looks up the user in the operating system’s group membership database, and uses the resulting group list when evaluating access. This works around the former 16-group limit that applies when the client’s group list is sent to the server. 
 
For example, a user in 50 groups will have all 50 groups recognized by the VOB and view. Access checks are evaluated based on those groups.