This request is specifically for Google Workspace and Azure AD connectors but may be relevant to others.
We want to use Google Workspace Group membership to control access to certain products. I have set up an Enterprise connector to our Google Workspace and selected the option to get Group membership data. I can see groups data coming through in the user context. For example I see something like this:
It seems to me that there is a big security hole if I try and use this data to restrict access based on group membership. The issue is that in our company (like most I’m sure) multiple people are allowed to create and/or manage Google Groups. As such they can set the name of their group to whatever they like. Google does not seem to mind multiple groups with the same name. As long as the email for the group is unique, the name can be a duplicate of another group. And it seems that what is presented in the “groups” array is the name rather than the group identifier.
Here is the exact scenario that worries me:
- I create a group called “group-project-x” and add authorized people to it as members
- I create a rule that checks if an authenticated user is a member of that group
- A colleague creates a group with the same name and adds a different set of people as members
- My colleague’s team can access my application because they appear to be in my “group-project-x” group even though they are not
I tested this and it is indeed the case - authorization is granted even though the user is not in the intended group. It is even worse for Azure AD (which I have also tried) because AD teams can include external guest users that can be authenticated against somebody else’s AD tenant. This means someone who doesn’t even work for my company can access my application because AD authenticates them and they appear to be in my group even though they are not. They just happen to be a guest in a Teams team with a name the same as my security group.
It seems that what is needed is access to the group ID or group email address instead of the group name. If you want to implement authorization based on group membership then name is unlikely to be a suitable attribute because it does not unambiguously identify the intended group. Only group ID or email can do that.