We currently have a simple AspNet Core website that is logged into by a "Manager". It gives them access to data about company branches they manage and the customers that use those branches.
The managers have an account in our Azure AD organisation. Currently we some appRoles defined in the website's App Registration. We have an appRole for each branch called "BRANCHNAME_Managers" this feels more like a Group. From memory I think we had problems accessing the groups a user was in from within the website so used the appRoles as they appear in the ClaimsPrincipal.Claims.
We want to create an api that is called from that website. That api needs to know what branches a manager manages. That api would have a seperate app registration in Azure AD and it seems that appRoles configured in the Web Site App registration would not be passed through to the web api. Therefore I think we need to move away from appRoles defined in the WebSite App Registration. Is this correct?
Bearing in mind what we are are trying to control access to, the branches a manager manages and the customers that are related to those branches should we be using User Groups membership or something we roll ourselves with simple database relationships?
The App roles defined in the website app registration (client app) cannot be recognized by the API. The app roles only exist in the id token in this case. But we need to verify the access token to access the API.
As I answered in your previous post, you can define the same app roles in the API app registration (service app) and assign those roles to the same managers.
Then you can verify the app roles included in the access token for your API.
Related
In a hypothetical scenario where I am using Microsoft Identity Platform for authentication, how would I also leverage it to control user permissions. Specifically, user permissions within the custom app. These permissions would not be related to other Azure resources or apps. For example, a web app that allows various different operators of a production plant to enable and disable different systems in the plant such as water coolers, air compressors, and conveyor belts. If I have a web app that allows a user to control these devices on a plant floor, how can I use MSAL to control the permissions to these different areas in the app? I only want user A to control coolers and compressors, and I only want user B to control the belts. I already know how to authenticate the users to the application using MSAL. I would prefer to control the permissions using something similar to AzureAD groups unless there is something better suited to this use case.
Scenario 1:
You have a Web App containing all the business logic. For this scenario you create one app registration for your Web App in Azure AD and define app roles for the various operators. You can name these app roles anything you want, for example: Coolers.Control and Belts.Control.
Example App Registration for Web App with App Roles (Image)
These roles can be assigned to individual users or groups in Azure AD at the Enterprise Application page. If you click on the "How do I assign App roles" on the app roles page, you will find the link that will redirect you to the Enterprise Application page.
If the user navigates to your Web App and signs in using the authorization code flow, the OAuth 2.0 authorization endpoint will return an Identity Token including a roles claim. You can use these roles in your web application to determine what areas the user is allowed to access.
More information: https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-web-app-sign-user-overview?tabs=aspnetcore
Scenario 2:
But there is another option that you might want to consider. You could also create a Web App for UI logic only and place the business logic in a separate Web API. With this architecture you are able to allow multiple (future) client applications to use the functionality of the API, for example: native mobile apps or background apps.
For your scenario you would create two app registrations: one for your Web App and one for your Web API. You define the app roles in the app registration for the Web API and define a scope, for example: access_as_user, to allow delegated access. This scope needs to be assigned to the app registration for your Web App.
Example App Registration for Web API with Scope (Image)
In the Web App you use the access_as_user scope (including app id prefix) in the call to the authorization endpoint. If the user signs in and grants this scope to the Web App so it can call the Web API on behalf of the signed-in user, the authorization endpoint returns an Access Token. If the app roles are defined in the app registration of the Web API and assigned to the user, the Access Token will contain a roles claim. This token is meant for the Web API to authorize the user. When the Web App calls the Web API, it also sends this Access Token in the Authorization Header of the HTTP request. The Web API determines what the user is allowed to do based on the roles in the Access Token.
More information: https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-web-app-call-api-overview
Additional information:
Because I had a similar question, I wrote an article about understanding scopes and app roles in Azure AD. The article explains how to use both scopes and app roles in a delegated access scenario, and how to use app roles in an app-only access scenario. I think this answers your question about how to control the permissions using something similar to Azure AD groups.
URL: https://cloudfirstapproach.com/understanding-oauth-scopes-and-roles-in-azure-ad/
Say I have an App1 in Tenant1. This App1 has contributor access to a subscription SUB_1 in the same Tenant1. There is a App1_ClientId and App1_ClientSecret associated with the App1.
Now, I can use this id and secret to login to that tenant and do stuff with the SUB_1 using the URL:
https://login.microsoftonline.com/Tenant1_ID/oauth2/token
Now how does it make a difference if this App is single tenant App or Multi Tenant App? Using this Id/Secret, I can access login to this app from any service anywhere.
Also, What does it mean by "Adding users to this App" ? Say if i add a user to this app, does it mean that that user will have access to the subscription in Tenant1 as well?
Now how does it make a difference if this App is single tenant App or
Multi Tenant App? Using this Id/Secret, I can access login to this app
from any service anywhere.
The difference would come if you want this application to be available in other tenants.
With single tenant, the Service Principal will be created only in your tenant. If you make this application multi-tenant, once a user in a different tenant consents to the application a Service Principal will be created in that tenant. That Service Principal must be granted appropriate Azure RBAC permissions in Azure Subscriptions associated with that other tenant. Only then your application will be able to perform operations on an Azure Subscription using client id/secret.
Also, What does it mean by "Adding users to this App" ?
When you create an application, you can define some roles specific to that application. When you add users to the application, you can assign users in one or more of those roles and then whenever your users access the application, they will be able to do operations allowed by those roles.
To elaborate, let's say your application is a Web API that has 2 controllers actions - Get and Post. What you can do is restrict the access to these controller actions based on the application roles. A user in appropriate role will be able to access those controller action.
Say if i add a user to this app, does it mean that that user will have
access to the subscription in Tenant1 as well?
Not necessarily true. If you're invoking Azure management APIs on behalf of the signed-in user, then they must be assigned proper Azure RBAC role to perform operations. However if you're invoking Azure Management APIs on behalf of the application, then you can configure your application so that these APIs are called in appropriate portions in your code which are protected by the application roles. For example, you would want to implement read operation in your Get controller action and a create operation in your Post controller action.
In your example, if App1 was a single tenant app, it will only have access to the resources granted to it in Tenant1. While you can use that app_id and secret in a code that runs anywhere: in that tenant, in another tenant or even in another cloud, the code can only access the relevant resources in Tenant1.
If you want your app to be able to access resources across multiple tenants, it needs to be added to each of those tenants by an administrator in the respective tenants. This can only be achieved when you have configured App1 as a multi-tenant application.
Adding a user to an application allows the user to access the application itself. The user does not automatically get/inherit any permissions that are granted to the application (such as a role in a subscription in your case)
We are developing a SaaS to analyze customer's data within office365 via Graph API and application permissions.
I'm trying to understand the best(and most automated) flow for onboarding the customers. Ideally, the Azure Global Administrator login in our webapp using Microsoft Identity and gives consent to create an account (app registration or enterprise application) with the relevant application permissions. With these permissions our SaaS has access to analyse data.
As of right now, I'm only able to solve this through manual procedure in making the App Registration together with customer on their Azure Tenant which gives me the Client ID, Tenant ID and Secret for our SaaS to authenticate with. I'm assuming something more fancy is possible :)
Also, I was hoping for a method which involved a multi-tenant registration, if that somehow enables reuse of a single app registration or Enterprise application (e.g. in our own Azure tenant) across multiple tenants (customers).
According to your description: you want to use a single application registration or enterprise application between multiple tenants, then you only need to change the application to a multi-tenant application, because changing the application to a multi-tenant application allows any tenant log in.
Next, you need to request the consent of the administrators of other organization tenants. You can send the login request URL: https://login.microsoftonline.com/{Other company tenant_id}/adminconsent?client_id={client-id}. After the administrator consent, it will be added to other organization tenants as an enterprise application in.
I have an Azure Function App (API) linked to an App Registration in Azure Active Directory (AAD), that exposes some custom Roles via the Manifest.
A client App Registration in AAD can add the API and select from its custom Roles as permissions. This allows the client app to call AAD to obtain
a JWT that includes these custom Roles, which can then be checked by the downstream Function App during JWT validation.
I would like the client App Registration to also include other API's custom Roles as part of a company's 'Product Group' (eg. Product Group may be Sales, Service, Finance etc.).
I want to create AAD Users representing each B2B consumer system, and link them to a Group that aligns to a company 'Product Group'.
Therefore, a User (B2B consumer system) should be able to request a JWT that includes custom Roles for all API's in the Product Group.
I need the JWT to include information of the consumer system, as it needs to be available to the downstream Function App.
What's the best way to achieve this?
The best we could come up with is to create App Registrations with custom Roles in the manifest to represent each Product Group. These App Registrations are completely independent of any specific Function App (API) implementation.
Then we have a client App Registration for each B2B consumer system, that imports the required custom Roles from its parent Product Group App Registration.
The downstream Function Apps (API's) then perform processing based on the Roles extracted from the JWT.
We have an Azure resource app whose APIs we want to expose for access by a client app on Azure. The two apps are on different tenants. The users accessing the APIs (Office 365 account holders) are on different tenants.
The whole set up works when we manually provision a service principal on the tenant that is trying to authenticate from the client app against the resource app. By that I mean they are able to log in using their Office 365 account and are shown the consent screen.
If we do not provision a service principal on the AAD tenant of the user trying to authenticate, we get this error:
AADSTS65005 - The app needs access to a service <service> that your
organization org.onmicrosoft.com has not subscribed to or enabled. Contact
your IT Admin to review the configuration of your service subscriptions.
It is not feasible for us to provision a service principal on every tenant that is accessing our app (resource app). Is there something we are missing? Are we using the right flow?
You can find help for your scenario here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent. (Scroll down to Multiple tiers in multiple tenants)
In the case of an API built by an
organization other than Microsoft, the developer of the API needs to
provide a way for their customers to consent the application into
their customers' tenants.
The recommended design is for the 3rd party
developer to build the API such that it can also function as a web
client to implement sign-up:
Follow the earlier sections to ensure
the API implements the multi-tenant application registration/code
requirements
In addition to exposing the API's scopes/roles, ensure
the registration includes the "Sign in and read user profile" Azure AD
permission (provided by default)
Implement a sign-in/sign-up page in
the web client, following the admin consent guidance discussed earlier
Once the user consents to the application, the service principal and
consent delegation links are created in their tenant, and the native
application can get tokens for the API
Basically, all of the parts that your app needs must be present as service principals in the customer's tenant. This is a requirement of AAD.
The only way for that to happen is for an admin to go through consent for the API and app separately, since they are registered in different tenants.
If they were registered in the same tenant, you could use the knownClientApplications property in the manifest to allow consenting to both at the same time.
In my case, I am exposing my own API and trying to access this API from my other Application (Client Credentials mode), I removed the default permission on both of the app(consuming app and api app) - "Azure Active Directory Graph-> User. Read" since I thought I don't need that but that caused this problem "The app needs access to a service .... that your organization has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service+subscriptions.
I got the clue from the answer of #juunas - point 2. Thx Juunas