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
Related
i was reading about AAD privilege escalation in one of the article where the author states that "if you compromise an Application Administrator account or the on-premise Sync Account you can read and modify directory settings, group memberships, user accounts, SharePoint sites and OneDrive files. This is done by assigning credentials to an existing service principal with these permissions and then impersonating these applications"
my questions are?
1.how can i find what privilege my app admin account has and how it is different from the permissions
that "application " has.
2. what does assigning credentials to a service principal means?
As mentioned in Carl's link,
The Application Administrator role allows users to create and manage all aspects of enterprise applications, application registrations, and application proxy settings. This role also grants the ability to consent to delegated permissions and application permissions, with the exception of permissions on the Microsoft Graph API.
Applications can have different privileges added to them, and a user in the Application Administrator role can add extra permissions to an application and theoretically use those credentials to impersonate the app's identity and have more privileges than originally intended.
An Azure service principal is a security identity used by user-created apps, services, and automation tools to access specific Azure resources. Just as a user is represented by a security principal called a user principal, an app is represented by a service principal. The service principal provides an identity for your app, allowing you to delegate only the necessary permissions to the app. It improves security if you only grant it the minimum permissions level needed to perform its management tasks. So if you assign credentials to a service principal you can grant or restrict the app's access to certain resources.
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.
It seems there are two separate mechanisms for defining applications scopes in AAD: appRoles via manifest update and oauth2Permissions via App Registrations, Exposed API tab. The first one is the only one allowing an application scope (allowedMemberType: Application) - the API permissions tab in App Registrations seems only to allow delegated user permissions. Am I interpreting this correctly? It seems rather confusing.
appRoles via manifest
We can define both User role and Application role via manifest. We can see application roles under application permissions. And application permission is used by client credential flow.
We can not find the user roles under delegated user permissions since these roles are not used here. The roles is assigned to specific user under enterprise app tab, the developer need to grant different logic code for different roles.
oauth2Permissions via App Registrations
We can only add delegated permission here. And this permission applies to all the users, not specific user. When users sign in, they will be asked to consent to the permissions.
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.