Add RoleAssignment to a Resource Group programmatically - active-directory

I'm implementing an application in Java that has access to Azure via a secure principal and that creates some Resource Groups.
I would like, given an AD Group Name specified via configuration, to add a specific Role Assignment for that AD Group to the Resource Groups.
Is it feasible via Azure Java SDK or I need to use REST APIs?
Which permissions the service principal needs to:
Read an AD group given its name
Assign a RolePermission to a newly created Resource Group for that AD Group
I need to ask to our ActiveDirectory team which permission must be enabled to my Service principal.
TIA
Best regards

I don't know if we can use java sdk to implement this requirement, but I know we can request rest api to do it. Please refer to the steps below:
1. We need to get the id of the role definition by request this api: GET https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleDefinitions?api-version=2015-07-01
The URI parameter {scope} should be like /subscriptions/{your subscription id}/resourceGroups/{your resource group name}
For example, here I get the id of "Contributor" role.
2. Then request this api: PUT https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleAssignments/{roleAssignmentName}?api-version=2015-07-01 to create role assignment(assign the role for resource group contributor to your ad group).
The {scope} should be /subscriptions/{your subscription id}/resourceGroups/{your resource group name} and you can specify a {roleAssignmentName} as you like(should be valid GUID).
The request body should be like below:
{
properties: {
"roleDefinitionId": "{the id of Contributor role which we get in step 1}",
"principalId": "{the object id of your AD group}"
}
}
3. Finish the two apis request above, we can find the AD group has been assigned with the role of "Contributor" for the resource group.

Related

Adding custom claim to id token based on group ownership existence on Azure AD

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.

Where does AzureAD store the "id" attribute returned by a SCIM endpoint?

I am integrating AzureAD with a SCIM endpoint. So far integration seems to work: AzureAD sends "POST" requests to create users, then later it queries/updates users using their 'id'.
Reminder from SCIM standard (RFC 7643): The 'id' is
A unique identifier for a SCIM resource as defined by the service provider
My SCIM endpoint generates this unique ID upon user first creation. It sends this ID to AzureAD in the reply, as required by the standard. I know that AzureAD stores the ID somewhere, because it uses it in subsequent requests.
My question: where is this ID stored in AzureAD? I need to read it, so I can forward it somewhere else. Using Graph Explorer I tried a lot of properties:
https://graph.microsoft.com/v1.0/me?$select=id,userPrincipalName,extensions,employeeId,externalUserState,identities,externalId
But none of them work. They are empty or do not contain the SCIM id.
Does anyone know if the property is publicly available?
Azure AD Provisioning has an internal data store that is not exposed via any external/customer-facing APIs where this is stored. If the service is evaluating an object that it does not know the SCIM ID value for it will try to locate that using a filtered GET such as GET /Users?filter=userName eq "user#domain.com", but once it has located that object the service will store internally a record stating that object X in Azure AD with objectId value of 123 is matched to object Y in with ID value of 456.
To specifically answer your end goal of "I need to find this value in Azure AD and forward it somewhere else" - this is not possible.
It is not like you think that AAD will save the user id from SCIM.
You can use Provision on demand to understand how it works.
Simple steps:
Click on "Provision on demand" in SCIM enterprise app.
Then select an AAD user and click on "Provision".
After it is executed successfully, you will be able to see the following:
Import user is retrieving User from Azure Active Directory.
Determine if user is in scope is determining if User in scope by evaluating against each scoping filter.
Match user between source and target system is retrieving User from SCIM and matching it with the AAD User in step 1. This is the point that you didn't know before. AAD will Get User by query in this step.
GET /Users?filter=userName eq "{userName}"
Then the user id from SCIM will be returned (As above screenshot shows).
Perform action updates User in SCIM using the id from step 3.
So AAD doesn't store the id from SCIM. It queries the user in SCIM firstly to get the id and then use this id to send update request to SCIM endpoint.

Emit role's permissions as claims in JWT with AAD (Azure AD)

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.

Restricting claims in Azure App Registration?

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 .

Authentication Process Get Azure AD group the user is a member of and do logic

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.

Resources