I have an (external to Azure) application to integrate with AzureAD through OIDC. The requirement is to add a custom claim to id_token with a list of groups where the user is an owner in AD.
For example if the user is in the owner of group with id = "123abc", I need to add the following custom claim to id_token.
"ownedGroups": ["123abc"]
If this is not possible is there at least option to add sth like this
"hasOwnedGroups": true
I could not find any relevant example for this in docs. Can you share an example for doing this? If this is not possible in the exactly same way, I 'd like to know the alternative solution for putting information about ownership in id token.
Azure AD does not support Groups as source for custom claims or claims mappings. You can however create directory extensions, update them with any data you want and get them in the token as optional claims.
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 want to add a custom claim to the ID Token or access token on basis of the azure group user is part of.
Let me give an example. I want to create a custom claim named test. The value of this claim will be on basis of the azure group. If the user is part of group A, then the custom claim value will be A, If the user is part of group B, then the custom claim value will be B, and so on.
I am already using roles in a claim for some other thing, so can`t use that.
To enable the return of groups in a claim, there are two ways…
Use the application registration manifest by enabling the groupMembershipClaims property…
https://learn.microsoft.com/en-us/azure/active-directory/develop/reference-app-manifest
or if it’s a SAML application, you can enable it though the SSO configuration.
The steps on enabling groups claim is outlined in the following article…
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims
Once enabled, groups will now be returned in the “groups” claim within a access token or ID token using OpenID Connect.
For more information you can refer this document
I'm setting up SAML SSO for an application. I have it working except that I'm unable to return a suitable value for the NameID claim. Existing userid's in the application are firstname + last initial so they don't match display names, email addresses, or any of the typical stuff found in Azure AD. I could use a transform to generate that but the available functions don't appear to do what I need.
I could also manually enter the userid in Azure AD and then map the claim to that but I hate to "misuse" an existing field (e.g. putting the userid in user.jobtitle or some such).
I also don't want to have to change everyone's userid in the app to match something that already exists in Azure.
I feel like I'm missing something obvious here since there have to be a lot of apps that don't use a common Azure property as their userid.
Thanks in advance for any help here!
Tom
You can map the attributes & claims present in the active directory to your app fields. For example if user.givenname is present in the active directory and in your app, the field name is firstName, you can achieve this by doing the mapping in manage claim section of User attributes & claims. Same could be done for others fields.
You go into the Enterprise applications > Your App > SAML-based Sign-on > click on edit
I need to emit a role's permissions as claims in the JWT.
The aim is to get a certain user's permissions as claims in the JWT for authorization purposes.
The user belongs to a group which is assocciated to a certain role which has certain permissions in the Azure Active Directory.
Clarification:
If I add some items to the appRoles array in the app's manifest, the role names are emitted as role-type claims in the JWT in the following format:
http://schemas.microsoft.com/ws/2008/06/identity/claims/role: [value property in the appRole item as appears int he manifest appRoles array]
But I couldn't find any way to emit role's permissions' names (or any other property) as claims.
I've been googling and digging in MS docs for days but couldn't find anything. I hope that it's possible.
If it isn't possible, a clumsy workaround may be to represent the permission we need to be emitted as an AAD role, and to represent the role (in the meaning of "a set of permissions") as an AAD special group, and then to associate the groups we wanted to be associated with the role (in an ideal world) to that special "role"-group.
But it's very clumsy as we will actually lose the natural meaning of role which is a set of permissions, and the natural meaning of group which is a set of users and/or groups
Thanks for any help :)
The value property is the custom role name you configured and will be returned in JWT. It's by design.
The permission name won't be returned in the JWT. After you have added an appRole into the Azure AD app, you need to assign users and groups to the role.
You need to add the needed permissions in Azure AD APP and then control the permissions in your code.
We assume you have assigned a custom role in an Azure AD app and added a user to this role.
When a user signs in, a token which includes the role claim will be returned. You can judge the user's role in the code. If it matches a custom appRole, he is allowed to perform an operation. If the user does not match any of the appRoles, he does not have permission to perform any operations.
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.