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/
Related
I have created an API that is protected by OAuth using an app registration in Azure.
My app registration does not require assignment, but it exposes a number of roles that the underlying API verifies. To my understanding, this accomplishes almost the same thing as requiring approval.
So far I've only had user/group roles but now I've added an application role intended for integrators, and I want other application owners to be able to request permission to my API. I, as the API owner, would like to review these and either reject or consent to the request. E.g. I don't want everyone to be able to access my API within the tenant without my knowledge, just like all users/groups don't have access with me assigning them to a role.
The Role-based access control for application developers documentation makes it very clear who manages access:
...an application developer defines roles rather than authorizing individual users or groups. An administrator can then assign roles to different users and groups to control who has access to content and functionality.
However, if you create a role with allowed member types set to application, things are not quite as clear and it seems to behave more like a scope, where I give up any access management. Also from my limited understanding, a scope is used when the API needs to request data from the user (e.g. wanting to read their username), whereas a role is used for the application developer to control access to what they are developing.
This is what it looks like when I request access to my API from another app:
This same page mentions the following information:
The "Admin consent required" column shows the default value for an organization. However, user consent can be customized per permission, user, or app. This column may not reflect the value in your organization, or in organizations where this app will be used.
As well as:
Applications are authorized to call APIs when they are granted permissions by users/admins as part of the consent process
However, from my reading, it sounds like this never gives me, as the API owner, any insight into who has access to the API I own. I want to control application access the same way I'd assign a group or user to a role in the enterprise application.
Can this be achieved when it's an application on the other end, not a user? If not, how would I allow applications to integrate in a controlled manner?
I want to explain the feature Azure ad provided to protect web api here.
As you know, we usually use a token in the request header to let the api check if the request had correct permission to visit the api. Such as if the request from an allowed user role, right? So to whole progress should be authentication and authorization. Users sign in first then try to generate an access token to visit an api. Azure AD has similar architecture.
If you had a web application(e.g. web mvc app) you can integrate Azure AD into it then you can allow users use their user1#xx.onmicrosoft.com account to sign in. If you had a web api project, you can also integrate Azure ad and add [Authorize] attribute above the controller so that the incoming request should contain a correct Bearer token which we call it access token.
For Azure AD, we usually have 2 options, verification scopes or app roles. That results from the different flows we used to generate the access token. For example, we use auth code flow to sign in users and generate access token containing scp claim which is granted delegated api permissions. And we use client credential flow to let an application to generate access token containg roles claim which representing it's granted application api permissions. In short, when we set [Authorize] + [RequiredScope(scopeRequiredByApi)] in the controller, it allows requests from a user(user sign in the app and call api), when we set [Authorize(Roles = "roleRequiredByApi")], it allows requests from the application(no user signed in and the app call api by itself).
Here scopeRequiredByApi and roleRequiredByApi is what you exposed and then added to App Registration > Permissions. Just like Integrator you marked in the screenshot, it can be recognized as roleRequiredByApi because its type is Application.
And I'm afraid the roles is not what you want but to be honest what I said is what AAD can do for you... And I think the document I mentioned above about verification scopes or app roles will be a good sample for you.
The App Registration > Permissions section has a great feature for reviewing and limiting the access provided for your app registration:
enter link description here
In addition you should always define the scope of your permissions and limit it to the least required for your app. eg. NEVER set scope at the subscription level! Always set it at the resource group or lower.
Also note that Microsoft now provides Defender for APIs and you can use Sentinel to monitor a lot of the activities related to your app registration. Always always enable logging wherever possible and configure some method of alerting/reporting so you can better understand the activities for your app.
I have React app on the frontend, I have registered it at Azure AD as REACT_AZURE and I use #azure/msal-react npm package to authenticate the user.
In order to protect my Express routes, I have registered another app at Azure AD as API_AZURE, and in "Expose an API" section I have added scope 'access_as_user'.
In REACT_AZURE app in "API permissions" section I have added permission for 'access_as_user'.
Now I can acquire access token for 'access_as_user' scope and make an API call to my express server.
In my protected route, I am using passport-azure-ad BearerStrategy to validate the access token, if it is valid I am authorized to get resources.
Is this the right flow? Do I have to register two apps with Azure AD? if not, how do I do it right?
Is this the right flow? Do I have to register two apps with Azure AD?
if not, how do I do it right?
Of course, your process is absolutely correct. You need to register two applications in Azure, one representing the client application and the other representing the api application. Then expose the api of the api application and add the client application to the api application. Then let the user log in to the client application to complete the authenticate and obtain the token, and use the token to call the api. I have answered similar questions before, you can refer to it.
But I’m not sure if you want to control which users can access the api based on the user role. If you only want certain users in the tenant to access the api, then you can add a step that is to create an app role and grants users who you wish to have access to the api. Then users in the tenant who are not granted the app role will not have permission to access the api. see more detailed answer.
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.
I have an ASP.NET MVC Web Application running as a web app in Azure App Service. This web app calls an Azure Function via HttpClient from a Controller. Authentication/Authorization is configured in the web app with Azure Active Directory. I need the user to also be authenticated when a call to the Azure Function is made so that I can access the user Claims.
I tried to also configure Authentication in the Azure Function itself but this resulted in an "Unauthorized response" whenever I called the function from my web app.
Is there a way to make both the web app and the Azure function use the same Active Directory Authentication. So that when a user is authenticated to the web app, he does not need to authenticate again in the Azure function and all the User Claims would be available in the function itself?
I can think of three different approaches that would work.
Using Bearer token.
Create two separate application registrations, one for the web application and one for the function application. Setup the Authentication/Authorization feature for the respective applications, with both configured to require AAD access. Give the web application's AAD app registration permission to access the function application's AAD app registration.
To make sure that the access token of your web application is a JWT that can be used to contact your function application, you need to add additional login parameters to your web application. To do this, follow the instructions here, but instead set additionalLoginParams to resource=<your-function-app-registration-client-id>.
When a user makes an authenticated request to the web app, a header should be populated called X-MS-TOKEN-AAD-ACCESS-TOKEN which should be an access token with an audience of your Function application's app registration. This can then be used as a bearer token to the Function application API calls, which should satisfy the authentication/authorization requirements of the function application.
Using on-behalf-of flow
Create two separate application registrations, one for the web application and one for the function application. Setup the Authentication/Authorization feature for the respective applications, with both configured to require AAD access. Give the web application's AAD app registration permission to access the function application's AAD app registration.
Then, follow the on-behalf-of flow so that the web application can get an access token for an authenticated user user for the function application. There are several libraries that help with this flow. See ADAL if your app registrations are AAD V1 apps, or MSAL if your app registrations are AAD V2 apps.
Use Client-Directed-Flow (X-ZUMO-AUTH)
Create two separate application registrations, one for the web application and one for the function application. Setup the Authentication/Authorization feature for the respective applications, with both configured to require AAD access. Give the web application's AAD app registration permission to access the function application's AAD app registration.
To make sure that the access token of your web application can be used to authenticate against your function application, you need to add additional login parameters to your web application. To do this, follow the instructions here, but instead set additionalLoginParams to resource=<your-function-app-registration-client-id>.
When a user makes an authenticated request to the web app, a header should be populated called X-MS-TOKEN-AAD-ACCESS-TOKEN which should be an access token with an audience of your Function application's app registration, along with an id token in the header X-MS-TOKEN-AAD-ID-TOKEN. Make a POST request to https://.azurewebsites.net/.auth/login/aad with the payload
{"id_token": <id-token>, "access_token": <access-token>}. This will return a session token, that you can attach as an X-ZUMO-AUTH header to authenticate requests.
NOTE: The claims in this option will be the claims of the authentication token, which are not the claims of the identity provider like in the first two options. To get the same claims as the other options, set the application setting WEBSITE_AUTH_ZUMO_USE_TOKEN_STORE_CLAIMS to true.
I want to develop a RESTful API to manage users in a custom Azure AD tenant. User management includes the following (the AAD tenant will contain predefined groups):
Create Users
Delete Users
Assign User to Group(s)
Remove User from Group(s)
Reset User Password
I am confused about how to set up the application registration and hoping to get direction based on the following:
The REST API application must be secured by Azure AD, so only designated admin users can access and use the API. Does that require the REST API application to be registered in the AAD Tenant where permissions to use the API and let the API access user profile (and group membership) is set?
The REST API is essentially a client of the Microsoft Graph API, which I envision facilitates the above operations requested by an admin user. Does that require a separate application registration, or can the same registration be used to provide necessary permissions?
Do I need the ADAL library in this situation?
Does that require the REST API application to be registered in the AAD
Tenant where permissions to use the API and let the API access user
profile (and group membership) is set?
Of course,you the Rest API app should be registered in the AAD.
Does that require a separate application registration, or can the same
registration be used to provide necessary permissions?
You can just need to register one app and you can assign mulitple permissions to it. Also you can add different roles to the app for different access scope to your API.Although, Your REST API is just like a client for the Microsoft Graph API, You can just assign the permssions to it by Applicaiton registration.So,you can just the Microsoft Graph by sepcify the resource in the HTTP request.
Do I need the ADAL library in this situation?
Yes, you need. For your web API, if you use AAD v1 ednpoint, you can just use ADAL to validate the JWT token and do some neccessary operations.