Get user membership groups in the claims with AD B2C
As it's possible in the standard AD by changing the API application manifest option "groupMembershipClaims" to "SecurityGroup", is it possible to return user membership group in the claims with AD B2C?
Now, we can have only the default and custom attributes by adding a signin policy, but it's impossible to get user membership groups.
Thank you for your feedback, and this can be done using Custom Policy. Check out our Azure AD samples at Github and after some customization to it we can achieve the ask: https://github.com/azure-ad-b2c/samples/tree/master/policies/relying-party-rbac
Borsoi Emanuel commented
As other user mentioned, RBAC does not work for social accounts...
Thai Bui commented
The Custom Policy solution recommended by Azure AD Team only works with local accounts but not with social login or other trust claims provider correct?
Isaac Rebolledo commented
Shubham Singh commented
Still custom policy? Why is this not doable through user flow?
Denis Ouspenski commented
May I suggest that someone at MSFT adds the completed sample as a turn-key solution to the linked GitHub repository?
If it can be done, and so many people are asking for it, having a sample and a piece of documentation detailing the use and implementation would go a long way for everyone in this thread.
It would be even better if that sample was documented and linked through the docs.microsoft.com site.
Joe Smith commented
An explanation of the difficulty here.
Azure B2C consists of a cut-down AzureAD tenant with the Identity Experience Framework (IEF) layered on top. When you authenticate against B2C you are really authenticating against an IEF flow, not the Azure AD directly. For local accounts, the default flows authenticate directly against the underlying Azure AD tenant.
It does not get back groups. In order to enable this, the Identity Experience Framework application would need the the groupMembershipClaims change. That would get the groups into the Identity Experience Framework, but even then the default flows are probably not set up to forward such claims along. In any case, changing the groupMembershipClaims attribute is non-trivial, because the built-in flows use an application registered in the cpimcore.onmicrosoft.com tenant.
If you use custom policy you don't use the shared application registration so it is most likely possible to apply the groupMembershipClaims to your manually created Application representing Identity Experience Framework, and then configuring things such that this claim gets exposed.
But the above would only work for non-social logins. To make social logins work, there is no way to use the underlying AzureAD support for creating group claims. Instead the profile read step would need to read the groups. But I'm guessing the AzureActiveDirectoryProvider does not support fetching groups. Indeed, getting a user's groups is an extra API call on the Graph API that ideally should only occur if needed.
There does not seem to be any easy way to allow the AzureActiveDirectoryProvider to know if the group claims will be needed for the app being processed. It would be easy enough to allow a global switch that if enabled always fetched groups for any application being signed in, even ones that don't need it. But that is likely too inefficient for Microsoft to be satisfied with.
Basically this actually is complicated. If it were easy it would already have been implemented. And the above are what I am able to deduce are complications as an outsider. There could be even more roadblocks that are only visible to insiders.
Sam J. commented
I'm just baffled at how many hoops I need to jump through to obtain something that I strongly feel should be out-of-the-box functionality. I've been working on this for a few days now and it is simply not what I expected from an industry leader. Please streamline this process.
Mark Duff commented
None of the workarounds I've wasted time on work in .NET Core 5.0, so can this be a priority again now? Or where is the link to a working example w/ complete source code?
This couldn't be a more fundamental need.
6 years and going for a must have option so that b2c can be used in a real-world application without redeveloping APIs and securing them, is MS intentionally do not want to implement this???
Howard Richards commented
So this **basic feature** of any security system is STILL missing from B2C after five years? Glad I only wasted a few days testing out Azure B2C. Without groups/roles this is an absolute joke. Why would anyone use it?
It is the same as what Azure AD does but in B2C.
Currently in B2C you can add user attributes, which get added as claims to the user in AAD B2C.
We would also like group membership claims to be populated.
How can this still require a work around? It has been years.
Please, please, please....?
Dumitru Ozunu commented
Ondrej Demjan commented
A major pain in the developers hands while using B2C. Please reconsider.
As others stated I also feel like the workaround here is awful and don't quite understand how this has not been fixed yet. I cannot see how this would be so expensive to implement, the data is there.
Why is there no update on this feature, the work around is ugly to say the least.
Jens Spaniel commented
You can already add the assigned groups via custom claims.
Here you find a tutorial:
Pär Sandgren commented
5y and counting. The data is there, just fix it.
Jose Manuel commented
Please, reconsider this position and implement this popular functionality