We have build a front facing single page application for Sharepoint online. Security is synced to sharepoint with AAD security groups. But at the moment we are facing a lot of issues, because we have to many Azure AD security groups created for it.
The app is a web portal has two kind of users:
Customers (guest users in AAD)
Employees (our AAD empoloyees)
Each Customer has is hown Sharepoint Online Site with security groups synced from AAD.
We defined some Customer Roles (Finance Director, Hr Director, IT,..)
And some Employee Roles for each Customer. (CUST_000000_AccountManager, CUST_000000_Invoicing, CUST_000000_Employee). 00000 stands for the customer id. So our employees have a lot of security groups defined in Azure AD.
In summary, it means that for each customer there are 20 security groups in AAD. These security groups are synchronized to our 200+ employees and 8000 customers. 28 000 000+ groups in total...
Due to the large number of groups per employee, we are now experiencing many problems.
What's best practice to handling this kind of specific security?
Handling the security in a separate DB or use multi tenancy as a solution for this...
Thanks in advance.
What you are looking for is Group-based Authentication.
You can configure the Azure AD Application Registration for group attributes. You just need to modify the "groupMembershipClaims" field in application manifest:
"groupMembershipClaims": "SecurityGroup"
Then the token will contain the Ids of the groups that the use belongs to like below :
{
"groups": ["group id"]
}
This method has a limitation that:
To ensure that the token size doesn't exceed HTTP header size limits, Azure AD limits the number of objectIds that it includes in the groups claim. If a user is member of more groups than the overage limit (150 for SAML tokens, 200 for JWT tokens), then Azure AD does not emit the groups claim in the token. Instead, it includes an overage claim in the token that indicates to the application to query the Graph API to retrieve the user's group membership. In this case, you only get back an overage indicator claim like hasGroups telling you that user is part of many groups and you should call graph api to get the list of all groups.
Using Microsoft Graph user: getMemberGroups to check the groups the user is a member of.
And if you are using implicit grant flows for your SPA, you have to check hasGroups claim because groups claim doesn't return in this case.
For other details you can check with the two SO Post:
How to check if a user is in an AD group via Azure AD?
How to validate if user is part of group in Azure AD?
Related
Inviting a consumer user to Azure AD B2C has been covered by other Stack Overflow questions & answers, and AFAIK requires the use of custom policies that entail a signed JWT being created and used during invite redemption.
What I'm trying to figure out: In our application, we have differently permissioned user groups and different organisations managed by internal RBAC logic. We identify & authorize users based on their oid claim in the access token that's returned to msal-react/msal-browser and used to authenticate against our backend's API.
In Microsoft Graph, a user can be invited and the API will respond with the created user's oid. However, this is the wrong type of user and not appropriate for B2C scenarios.
With the custom policy route not creating the user object in AAD B2C at the time of invite, and therefore without knowing the user's oid at the time of inviting them to the application, what might be the best way to configure their in-app profile and have them identifiable to the application itself upon first login?
My thought at the moment is to have the application store the emails of users that are invited who have not yet redeemed/signed-in. We can configure the emails claim to be returned upon login, which is checked against the invited emails store when an oid claim is returned that isn't present in the database. This can then trigger a function to update the user's internal id with the oid in their first login's claim.
If this is inadvisable or if there's a better way, I'd be very grateful to hear it.
It would work, or just pre create the user up front via MS Graph API. Then you have an email and objectId available.
You could also put an extension attribute on the account indicating whether the user has redeemed their invite. That would allow you to monitor who has redeemed, and also be a way to provide a different experience depending on if the user has redeemed or not redeemed the link.
I have an application that has stored the openid subject/NameIdentifier to identify users. Now a featurerequest was made that requires retrieving a user from the Microsoft Graph api while the user isn't logged in. Which requires the objectidentifier to find the user. Is there someway to convert the nameidentifier to the objectidentifier without requiring the users to login.
Can I retrieve the nameidentifier with the graph Api
You can't use Nameidentifier to fetch the user information from the Tenant level using GarphApi which is unique only to the application level.
The ID/UPN is the unique across the Tenant which can be used to fetch user information.
The converstion of Sub/Nameidentifier to oid/UPN is not possible as these two are different unique id generated by azure.
In this document you can find more information about sub/oid here
Within Azure Active Directory, I have created an App Registration.
For most users, this works great. They can login to my application via federating in from Azure AD, and their claims are coming through.
For some users, however, they have over 150 group memberships in Azure AD. For them, they receive an HTTP 400 bad request. I've increased the maxRequestBytes and maxFieldLength of my server according to this post: https://support.microsoft.com/en-us/help/820129/http-sys-registry-settings-for-windows, but it didn't solve the issue for all users. Some received access after this, but there's a handful that still cannot login.
My application only has ~10 groups in Azure AD that it cares about. I customized my App Registration's manifest to have "groupMembershipClaims": "SecurityGroup".
Is there a way I can restrict the claims coming out of Azure AD to only the 10 groups that I care about?
Per my understanding, this issue is due to too many groups claim in some your Azure AD user access token and you want to limit the group claims.
As far as I know, there is no way to do that. But there will be two workarounds here :
1. this official doc which indicated claims about groups and hasgroups, maybe provides some tips to handle your scenario. As the doc indicated, it suggested you to call an API to fetch all user groups if a user has too many group claims.
In your scenario, you will need to check about 10 groups membership with a user. To avoid the issue that too many group claims in your user's token, you can just remove group claims in token and check groups membership with a user with this API.
2. Using Azure AD app roles claim instead of groups claim. In Azure AD application, we can create Add app roles and assign the role to users or groups. Once be assigned the role , role claim will be added in users' token.
As you only care about 10 groups, you can create corresponding app roles and assign the roles to your groups that you cared about(i,e role1 assign to group1).With this,users in groups will have corresponding role claim(i,e , users in group1 will have a role claim:role1) so that we can use this claim to replace groups claim .
What's more
except for increasing maxRequestBytes and maxFieldLength of your server, you can try to modify maxAllowedContentLength , details see this post .
I have a SaaS system using Azure AD and multitenant access. This records the issuer, in the format https://sts.windows.net/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ and an objectidentifier ID.
The portal I'm using insists on seamless trials, so for trial users I can't show a box to collect emails etc. When people later sign up this is collected.
In the initial version I screwed up and didn't collect user names/emails addresses, so I can't warn such users their trials are terminating. I've now fixed this and record the Principal.Identity.Name, which contains an email, every initial sign on.
This leaves me with a bunch of people I have no emails for.
Using what I've got, and maybe powershell or the Graph API, how do I get the names/emails?
Is there a way to get the Group the User is member of so we can process the authentication, or even throw exception so the token will not be created.
The reason we need groups is that we can not create OU in Azure AD whereas we could before in LDAP. We retrieved the distinguished name and therefore had very rich information about said user.
Lastly, we do see that you could create an OU on-premises but read that Graph API would not recognize it or could not retrieve it.
We are attempting to do logic within the SecurityTokenValidated stage of Authentication process and we break the process whenever we try to use:
string UPN = context.AuthenticationTicket.Identity.FindFirst(ClaimTypes.Name).Value
Is this because we are using MSAL?
The best approach for you to take here is to make use of the group claims capability of Azure AD. (And for get OUs. OUs are not represented in Azure AD at all.)
Dushyant Gill's blog post on this is relatively old, but still very much relevant: http://www.dushyantgill.com/blog/2014/12/10/authorization-cloud-applications-using-ad-groups/. In short, the process is:
Enable group claims for your application by setting the groupMembershipClaims property in your application. After setting this, when a user signs in to your application, the list of groups they are a member of will be included in the token (if the number of groups is smaller than the limit).
Update your application's authorization code to make use of the group membership claims (if present).
Update your application to query the Azure AD Graph API if the groups membership claim is not present (i.e. if the "overage" claim is present). This happens only when the user is a member of more than 150-250 groups. (Use the _claim_name and _claim_sources claims as indications that the Graph API needs to be called directly.)
As described in the documentation for Azure AD Graph API permissions, in order for your application to call the getMemberGroups method, the app must have the "Read all groups" permission (Groups.Read.All). This permission requires admin consent, but once consent has been granted, the request can be made using the signed-in user's access token.