In a previous article, Adventures with Azure AD: Group Overage Claim, I talked about how to handle, in an ASP.NET MVC Core application, the group overage claim that is sometimes returned in the claims for an authenticated user.
I had a customer contact me saying that the code I provided them was not working as expected for a particular user. The customer thought it might be due to the number of Security Groups returned, in their case, more than 260 Security Groups were being returned.
For kicks and grins, we agreed to comment out the code that converted the Security Groups to Roles and added them as a claim, basically, ignoring bloating up the Claims with Roles.
We hit F5, and off the browser went … and it worked!
Not sure exactly what is going on here, I assume there is a limit to the size the cookie can be, even though it is chunked up into small pieces.
In hindsight, if my application only cares about a limited number of Security Groups, as a developer, I should take the more responsible step and only convert those Security Groups to Roles that I care about.
We made couple of changes to the code, as seen below, and now all is good.
|
1 2 3 4 5 6 7 8 9 10 11 |
var jsonResult = await httpResponse.Content.ReadAsAsync<dynamic>(); var securityGroups = ((JArray)jsonResult.value).ToObject<List<string>>(); var availableSecurityGroups = new[] { Roles.ROLE_GROUP1, Roles.ROLE_GROUP2, Roles.ROLE_GROUP3 }; foreach (var securityGroup in securityGroups.Intersect(availableSecurityGroups)) { identity.AddClaim(new Claim(ClaimTypes.Role, securityGroup)); } |
This was a great collaborative learning experience for my customer and myself!
Always grateful to learn something new, even if it is a limitation of some feature or technology.
You can see the entire example code at https://github.com/mattruma/SampleAzureADAuthentication.