Pretty sure this is a feature request as I’ve scoured the Access docs and the API docs and haven’t found anything.
On our Argo/Access secured services we want to know which group(s) a user belongs to. Currently the only information passed to our app from CF Access is the user’s email.
There is no API endpoint for determining which groups a user is a member of. One would have to parse all the Access groups rules and manually resolve the include, exclude, and require statements. This would be quite a hairy thing to implement ourselves.
Several ways I could see user groups being exposed is:
An additional header listing the groups a user belongs to
An API endpoint that returns the groups
However to be able to actually deploy usage of that endpoint we would need a very fine-grained API Token Permission instead of the generic “Read everything related to Access”
Adding the groups to the JWT
The negative here of course is that the JWT would need to be re-issued every time group membership changed
We’re using Access to secure, erm, well, access, to a suite of inter-organizational apps. We can’t roll out a centralized SSO for all the users because if the inter-organizational nature of this deployment. Using Google as the IDP works great because all our users have Google Accounts. Using Access as the single-stop for determining user identity and group membership makes building role/perm authorization into our apps much simpler, but as it stands we need to duplicate group definitions between Access and a new purpose-built internal system… quite a waste.
Yes, I’ve seen that, and we use that feature for another deployment. But this feature isn’t quite what I’m asking for here.
The feature you’ve linked is a sort of “passthrough” from the underlying IdP to the CF JWT. The response from /access/get-identity only contains groups and identity data from the IdP. Not all IdPs support this, and they certainly don’t present it in a common structured format.
What I’m asking for here is a way to query Access group membership of users, not the underlying IdP groups. We want the IdPs to authenticate the user, but then we want to use our own defined Access groups as a control on what to authorize access to.
I’d like this feature too. I was hoping to use the Access Groups to identify roles that users might have (across multiple aggregated SSOs), and implement different actions in my origin server based on the Access Group membership.
for example, I want to create a developer/customer-service portal for our organization and protect it with Cloudflare Access. If the user is internal to our organization, we can assign them groups within our IdP so we know if they’re QA/dev/customer-service/business/etc. But, we’ll also allow 3rd party development teams access to the portal.
My use-case is simple enough I could probably lump anyone without a @myorganization.com e-mail address into ‘3rd party dev’ role, and for internal-org users I could look at our IdP groups.
It’d be nice to do all that role assignment up in Cloudflare Access though.