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.
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/
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.
I'm a bit confused, I have the following implementation:
ASP.net API protected using Azure AD, and users with Admin role only can call this API, these roles are configured in Azure AD and assigned to users. the API has one defined scope AccessApi.
Scopes Who can consent Admin consent display name User consent display name State
api://xx User AccessApi AccessApi Enable
The client application developed in WebAssembly blazor is registered and protected in Azure AD without roles, its configured to use AccessApi scope from my Api.
API / Permissions name Type Description Admin consent required Status
myApi (1)
AccessApi Delegated AccessApi No
My confusion is do I need to assign an Admin role for the client application to obtain token which will be used to access the API or the API scope accessApi is enough without any roles?
knowing that users of the client app are the same users of the API just with different roles.
Since same users use both API and client App, is it possible to use MS Graph by client App to get JWT token and use that token to call the API?
If you want to control the user's access to the api based on the role, then you can use appRole. Set the appRole of the application and then assign the appRole to the user, then only the user who is assigned the appRole can access the api.
Next, go to the enterprise application and assign appRole to the user.
In addition, never try to use the token of ms graph api to call your custom api. These are two completely different api resources, and you need to request different tokens for different api resources!
We are working on WEB APIs and want to integrate Azure AD for AuthN and AuthZ. We have successfully integrated the same. We have created enterprise applications, custom roles, assigned users for the same.
Now we need to allow access to APIs with AWS like keys (Secret / Access keys). Individual user can generate their own keys and store those in Azure AD so that when those keys are used, user can be authenticated.
I didn't find any way to achieve this using Azure AD. Any suggestions around same are welcome.
Meanwhile I have gone through custom store for keys. Please refer link : https://www.codeproject.com/Articles/1228892/Securing-ASP-NET-CORE-Web-API-using-Custom-API-Key
Thanks in advance.
Azure AD authentication uses tokens.
So any app wishing to call your API must authenticate with AAD and acquire a token for the API.
If these users are making apps within your organisation, then they can register their app in your AAD and require access to your API. They will create and manage their own keys.
If on the other hand these users are making an app for another organisation, you'll have to make your API a multi-tenant app.
And you'll need to have an on-boarding page in your API through which you will redirect their admin/user to the AAD login page, where they will consent to any permissions your API requires.
After this a service principal is created in their tenant.
Then they can register their client apps and require access to your API.
They will have full control which permissions they want to assign to each app, what roles to give to users etc. But of course the tokens will contain their tenant id so you can filter access on that.