We want to give user an elevated permission to specific azure resources for limited time. User can ask for access with subscription name and resource group or resource and hours it needs access.
Example:
GrantAccess -sub 673vh3h3h666 -rg myrg -t 6h
This can be done with Azure AD entitlement management.
https://learn.microsoft.com/en-us/azure/active-directory/governance/entitlement-management-overview
What can I do with entitlement management?
Control who can get access to applications, groups, Teams and SharePoint sites, with multi-stage approval, and ensure users don't retain access indefinitely through time-limited assignments and recurring access reviews.
Delegate to non-administrators the ability to create access packages. These access packages contain resources that users can request, and the delegated access package managers can define policies with rules for which users can request, who must approve their access, and when access expires.
Select connected organizations whose users can request access. When a user who isn't yet in your directory requests access, and is approved, they're automatically invited into your directory and assigned access. When their access expires, if they have no other access package assignments, their B2B account in your directory can be automatically removed.
Create a new access package in Azure AD entitlement management
Related
Are Azure's RBAC tools and capabilities appropriate for delineating and enforcing app-specific user permissions?
What I've been seeing is that Azure's RBAC capabilities seem to involve managing Azure resources: BLOB services, storage accounts, app services, etc.
But what I don't see are examples of Azure RBAC being used to manage app- (or domain-) specific permissions, like "Allow the user to approve purchasing this widget" or "Allow user to categorize these items as Foo, Bar, or Baz", or "Allow the user to view financial data only from these company divisions".
Am I fundamentally misunderstanding how Azure RBAC works, or what it's used to manage? Can anyone point out examples of Azure role definitions that include permissions like the ones above, or point to documentation of how I might set those up?
I believe you are looking for application specific permissions which can be achieved, by configuring API permissions in apps, registered in AD. Please correct me if my understanding is wrong.
So the difference between API Permissions and Role Assignments is as below:
API Permissions: 2 types.
Delegated permissions are appropriate for client apps that access a web API as the signed-in user, and whose access should be restricted to the permissions you select in the next step.
Delegated permissions are used when authentication is done under user's context and are returned in scope claim of the token.
Application permissions are for service or daemon-type applications that need to access a web API as themselves, without user interaction for sign-in or consent. Unless you've defined application roles for your web API, this option is disabled.
App permissions are used when authentication is done under application (service principal) context and are returned in roles claim. For example, if you have a web application, you can configure it to allow access to the user, if the scope claim contains read, otherwise deny access. Or grant write access to application only when roles claim contains write.
You should configure API Permissions when you would like to return the permissions in the Access token. When application consumes the token, it makes authorization decision on the basis of permissions present in the token.
Role Assignments:
RBAC is the authorization system you use to manage access to Azure resources. When using RBAC, an administrator grants permissions to roles, and not to individual users or groups. The administrator can then assign roles to different users and groups to control who has access to what content and functionality.
Role assignments are used to assign permission to users/service principals on Azure Resources. In this case authorization is done by Azure and not by the end application which happens in case of API permissions.
Please ref the below articles for detailed explanation with examples.
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-how-applications-are-added
Our use case is this: our application needs to access the Azure AD of customer organizations to:
Authenticate users
Sync users' profile data to our app when it changes on AD
Read and subscribe to booking changes in meeting rooms
Our app therefore needs the User.Read.All permission to read profiles of users, but also Calendar.Read.All but the latter must be scoped to a specific group (so as the protect the privacy of actual users). According to this article, a tenant administrator can restrict access of an application to a specific group, but I don't see any way to do this for a single permission, so it would restrict all permissions of an enterprise app to this group. Am I missing something or is this simply impossible and I would need to use multiple service accounts for this purpose?
Currently we can not restric the specific application permission to access a specific group. But we can scope application permissions to specific Exchange Online mailboxes.
Administrators can use ApplicationAccessPolicy cmdlets to control mailbox access of an app that has been granted any of the following application permissions:
Mail.Read
Mail.ReadBasic
Mail.ReadBasic.All
Mail.ReadWrite
Mail.Send
MailboxSettings.Read
MailboxSettings.ReadWrite
Calendars.Read
Calendars.ReadWrite
Contacts.Read
Contacts.ReadWrite
So if you have both User.Read.All and Calendar.Read, the ApplicationAccessPolicy will only work for Calendar.Read permission. The ApplicationAccessPolicy are specific to Exchange Online resources and do not apply to other Microsoft Graph workloads.
I am trying to find security best practice on App permissions in the context of azure resource management.
Currently, there is only one permission listed for management.azure.com and it is
management.azure.com/user_impersonation (preview). This delegated user impersonation can be a serious problem and it can led to account takeover by malicious app.
Think about a scenario where a user with global administrator role consent and authorize an access token to the app. App can use the token and do whatever it wants with the azure tenant.
Another scenario where a privileged user assigned contributor role to multiple subscriptions. Token authorized by this user can be misused by app to modify resources in any of the subscriptions.
Unlike graph (graph.microsoft.com) api where you can handpick the permission (user.read), resource management api has only one option - user_impersonation!
You may argue why would a privileged user authorize the action but people make mistakes. Our job is to stop or minimize such risk by design. So, what's the best way to allow app to manage resources in azure and minimize the security risk?
Thanks to #juunas for outline and tips. Thanks to #Gaurav for attempting to address my question. I was able to modify azure resources on a subscription without having to grant user_impersonation on management.azure.com api. Here are the steps-
1) Register an app (TestPermissions in my case)
2) Add API Permissions (optional). You don't need to add management.azure.com.
3) Go the Azure resource (subscription, resource group or management group level based on your requirement) and add IAM/RBAC role to the registered app. I assigned Contributor role to TestPermissions app at the subscription level.
4) Request a oauth2 access token following client credential grant flow. You can provide client_id and client_secret in the body of the POST request or you can provide it as Authorization Basic base64 encoded header (that's what I did). Save the access token for future use (until it expires).
Note: I could not add multiple audience (scope) at the same time. If you would like to get a token for graph api, you can request a separate token by changing the scope to http://graph.microsoft.com/.default
5) Use the access token captured in the previous step to interact with azure resource manager. You will need to add the jwt bearer token in the Authorization header (not shown here) on every request to https://management.azure.com. In this example, I am creating a new resource group named TestCreateRG003 to one of my Pay-as-you-go subscription.
6) Let's validate/verify that the resource is created or updated in Azure. Bingo, there they are! App can read/modify (based on RBAC) azure resources w/o having to grant impersonation permission.
It is true that by granting that permission you are allowing the app to act as you, with all the permissions that brings.
The main way I've seen used when limitations are desired is that you:
Register an app in your Azure AD
Grant the service principal the necessary roles (e.g. Reader on specific resources)
Set the tenant id, client id, client secret etc. in the app
This of course requires that the app itself supports this approach.
If it only allows usage through impersonation, then you'll need to either trust or not use it.
Let me see if I can answer this question.
When a user requests a token for management.azure.com, all is done at that time is that the user has permission to execute Azure ARM API. That doesn't mean that they can do everything that's possible with Azure ARM API.
The things that they can do is controlled by Azure Role Based Access Control (RBAC). So if a user is in the Reader role, the token got on behalf of the user can only read information about resources in their Azure Subscription. They will not be allowed to create, update or delete resources in their Azure Subscription.
What you will need to do is grant users appropriate RBAC role to minimize the risks of misuse.
I would like to assign the rights for mid-level admins to revoke 365 sessions for users in Office 365 (perhaps after accounts become compromised). What are the minimum rights necessary to allow an admin to revoke sessions.
One way is to grant the user User administrator role.
Can manage all aspects of users and groups, including resetting
passwords for limited admins.
You can run Revoke-AzureADUserAllRefreshToken command in powershell or call Azure AD graph api directly by using Azure AD Graph Explorer.
The other one is to create an application and grant it 'Directory.ReadWrite.All' permission.
This will allows the app to read and write data in your organization's
directory, such as users, and groups, without a signed-in user. Does
not allow user or group deletion.
Both of them include other permissions, not only 'Revoke-AzureADUserAllRefreshToken' permission. It depends on you which one include the least permissions for you.
Is it possible currently to make an application in my Azure AD tenant and allow customers to give it permission to alter their resource groups.
I basically want to create an web application that allows any azure resource owner to allow my application to add something to a resource group of their choosing.
I cant figure out if its required for the customer to have the global administrator role for this to work?
Is it possible to make a flow that lets the customer sign in to my webapp, and give permission for a resource group of this choose, without him being the global administrator.
Is it possible for something in the azure portal to select his resource group add allow my azure ad application to get access to his resource group, or what is needed from the customer for this to be possible?
There are two ways by which a 3rd party application can access a user's subscription:
Delegated Permission (User Impersonation): Azure Portal is a good example of that. Basically in this scenario, a user logs in into your application by authenticating herself/himself against their Azure AD and then your application makes ARM API calls on behalf of the logged in user. If the user has permission to do something, your application will do that otherwise your user will get an error.
Application Permission: This is basically more for running things in the background when the user is not logged in. Essentially this is where the concept of Service Principal comes in. In this scenario, someone with administrative privileges grant certain permissions to your application and then your application will be able to do things it is permitted to do. The user need not be present in this scenario.
Now coming to your questions:
I basically want to create an web application that allows any azure
resource owner to allow my application to add something to a resource
group of their choosing.
I cant figure out if its required for the customer to have the global
administrator role for this to work?
Yes, it is possible for your to create such a web application and the customer need not be a global administrator to use such an application. In fact, this is how we're providing Azure Subscription management in Cloud Portam. Azure Portal works the same way. When you login into Azure Portal, you only do things you have permissions to. To see this in action, just login into Azure Portal using a user who is in Reader role and try to create some resources.
Is it possible to make a flow that lets the customer sign in to my
webapp, and give permission for a resource group of this choose,
without him being the global administrator.
Yes, it is entirely possible however the permission from Azure's perspective will be at Subscription level and not at a resource group level. Again since you would be impersonating the user, the user need not give you explicit permission to access certain resources. Azure RBAC will take care of this for you.
Is it possible for something in the azure portal to select his
resource group add allow my azure ad application to get access to his
resource group, or what is needed from the customer for this to be
possible?
Yes, it is possible to do so. However in this case, the user who's granting the permission to your application should be in a role that allows her/him to perform this operation. They should have write permission on Microsoft.Authorization resource provider. However please do keep in mind that once your application (also known as Service Principal) is granted access to a resource in your user's subscription, there's no need for a user to login. You typically would want to use this approach for background process kind of applications.