We have a multi-tenant single page app (and backend) that uses Azure AD for authenticating users. We'd like do queries to customer's Azure AD for retrieving groups but make it an opt-in behavior for customers (tenants). The reasoning behind that is that not all customers necessary need the functionality and would rather not grant us access to their AAD unnecessarily.
Is there some way of implementing this with Azure AD?
I've been trying to test with different OAuth /authorize calls with resource IDs and scopes but mostly I end up with "AADSTS65001: The user or administrator has not consented to use the application with ID ''. Send an interactive authorization request for this user and resource." error. Configuring the web app or backend to require the permission would surely fix the error but that will also make the approval of it mandatory for all users of the app.
Is there a way of using the authorize/consent API to request access to a new application on-demand?
An ugly work-around that should work would be to have 2 client IDs and 2 backend IDs with different permissions but ADAL.js doesn't seem to be designed to work with multiple Client IDs (it's singleton, for starters). Also Application Permissions should of course work but I'm not sure how much of those are required to search for groups.
Is there a way of using the authorize/consent API to request access to
a new application on-demand?
Do take a look at Azure AD v2.0. With their incremental & dynamic consent model, it is possible to do so though I am not sure if this specific functionality (managing groups) is available there.
I had a discussion with Azure AD team member recently about this (as we are also facing the same problem) and he suggested that we take a look at this.
Essentially the way things work in Azure AD v2.0 is that you start with basic set of permissions (like sign in, read profile etc.). Then when some tenant need specific permission, you essentially ask them to grant those permissions to your application at that time only. What this means is that different users in your application have granted different permissions to your application.
If you are using MSAL, and looking for a way to dynamically change your scopes before authenticating, have a look at this: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular/docs/v2-docs/configuration.md#msalguard---dynamic-auth-request
More here: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular/docs/v2-docs/configuration.md#platformbrowserdynamic
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.
We want to use Azure AD as the Identity Provider for users in a web application. At the moment, we have everything set up using MSAL.js 2.0 with the Auth Code Flow, a custom scope, and access token which is used to authenticate requests towards our various backend services.
The issue is that our users want to be able to login with their own custom email addresses, instead of their login ids generated by AD and with the #onmicrosoft.com domain. For example, user1#some-orginization.com or user2#some-other-organization.
It would still be okay to accept the login ids as usernames as well, but surely there must be a way to allow users to use another property of the profile (their alternate email for example) to log in.
Our application is registered to AD such that it will allow only logins from one tenant, since we don't want to require users to already have existing Microsoft Accounts.
We're avoiding B2C because some users would face issues with their company policies, which would mean they could be invited as users, but would be rejected at login. Also, B2C does not really support Roles like B2B does, which is somewhat important for us.
Any guidance will be greatly appreciated.
EDIT:
After countless hours of attempting to make this work, I decided that it just isn't worth the effort, and switched to Auth0. They provide everything I could possibly want, and seemingly even better Azure AD integration to other tenants then Azure AD itself.
I think what you want to express is that you want to log in to your application with any email (including personal accounts and social accounts).
If so, then you need to modify the application's manifest configuration and then change the /tenant id endpoint to the /common endpoint.
To change the setting for an existing AD App, navigate to the Manifest blade of it in the portal, find the signInAudience attribute, set it with AzureADandPersonalMicrosoftAccount or PersonalMicrosoftAccount.
I'm new to Azure ADB2C, and am confused by some of the terminology.
I am building a motorcycle ride monitoring website that I would like users to be able to log in to by verifying a social media identity (Google & Microsoft Account, for now).
But I only want users who are members of the site to be able to use certain features. For example, I'd like everyone who authenticates to be able to apply for membership, read about the benefits of membership, etc., but I only want members to be able to initiate ride monitoring.
Is the recommended approach here to only authorize (rather than authenticate, if I'm understanding the terminology correctly) certain authenticated users (i.e., members) to use the ride monitoring services?
If so, what's the best way to authorize a member? Look up their email (which I require to be returned from the authentication process) in a standalone database and proceed accordingly? If I go that way, what's the simplest way of adding their membership status to their credential, so I can access it throughout the site?
Apologies for not providing code here. I've got a bit of it hanging around :) but this is more of a design question than a coding one.
Azure AD B2C is primarily Authentication as a Service. There are ways in which it can be used for what you are trying to achieve here.
You can use custom (extension) attributes in AADB2C (https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-custom-attr) in combination with AAD Graph apis (https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet). So when user authenticates and applies for membership, you can call AAD graph api to set the custom attribute on user object. You can get the extension attribute in a the token after the authentication happens. This token will give you membership of the user.
You can also use AAD Groups instead of custom attributes. In the tenant, create membership groups. Once user authenticates, call AADGraph to set/get user's membership of a group and that will give the authorization information.
You can also do what you described, maintaining the info in a database store of your application. But the first two functionalities provide in-built functionalities for user management.
I don't understand how the 'Scopes' in Azure B2C are supposed to be used. They are associated with an API, but not a user. I'm sure I'm missing something, but I see no practical use for something associated with an API. I've used and implemented Claims-based authentication based on a user's role in the database.
For example: ordinary users of an API should not have the authority to delete an object, but administrators should have the authority. Does someone have a practical example of how these B2C 'Scopes' can be used to limit a users access to the API?
They are associated with an API, but not a user.
That is correct. I like to think of the association to the API as defining the 'surface area' of the API. For example, this API defines 2 scopes
read
write
Now, you could define two applications. One application that only has read permissions and one that has read and write permissions.
For the common use case of one Web App and one Web API it adds no value. I've been using a scope of no-op for such cases.
I've used and implemented Claims-based authentication based on a user's role in the database
You can use custom attributes to assign "role(s)" to the user. You can set them via the Azure AD Graph API to keep the setting of them secure. You can also set them during sign-up (this is much more involved though).
When you request an access token for that user, the custom attirbute(s) you defined and set will be readable in the API to check permission(s).
Comment Feedback
If I promote or demote a user, I need to change the endpoints (policies) they access at the client.
No need to change the policies. You would update the custom attribute for that user via the Azure AD Graph API.
My problem is that I'm mystified at the an authentication system that authorizes endpoints ("scopes") instead of users
Yeah, me too! I think it might have to do w/ the purpose of the product. B2C is about self-service sign-up, password reset and federating w/ other IDPs (like FB, Google, etc). Maybe Azure AD is a better solution when you want to control permissions on a user. Not sure, still learning!
I still don't see the practicality of splitting your API into several different parts based on the security. An API should be a collection of functionally related services
You don't split your API. You can split your app(s) that utilize the API. See above.
Documentation Reference: Requesting access tokens, GitHub Issue to improve the documentation.
Roles and scopes provide the two halves for this user access control.
Roles -- such as Administrator, Member, and Guest -- determine whether an authenticated user is permitted to delete objects.
Scopes -- such as read, write, and delete -- determine whether an authorized application can delete objects on behalf of an authorizing/consenting user if this user, through their role assignment/s, is permitted to do so.
Azure AD B2C doesn't have any current support for managing roles and assignments of them to users.
It does, however, have support for managing scopes and assignments of them to applications.
We want to create a MVC web application using claims-based authentication, expecting roles as one of the claims. We want to Federate authentication providers using the Azure Access Control Service to manage this federation. One of the authentication providers is our Azure AD.
The problem is that Azure AD doesn't seem to be able to generate role (or even group) claims. What is the appropriate method to manage group or role access in Azure AD and have role claims served by Azure Access Control Service.
Thanks.
Edit:
A previous comment asked for details: We want to provide access to our cloud application to 3rd parties using their active directory (to simplify user management for them). Our application has a few levels of access to information that the 3rd parties can configure. We were hoping they could do this in their AD (based on our instructions). Groups seemed like the obvious choice, but if there is another way that works, as long as we can provide instructions, it'll work.
We want our application to get claims for a user's level of access. If we had only one partner that was using Azure AD, we could use the graph API against that endpoint, but with multiple partners changing over time, we wanted to federate them so our application only needs to trust the federation server. We were assuming that we needed Azure ACS to manage the federation.
AAD does support roles / groups and you can administer them from the Azure Portal.
Howeve, these are not passed in the "canned" set of claims.
You need to use the Graph API and then convert them e.g. Windows Azure Active Directory: Converting group memberships to role claims.
Update:
ACS requires something to federate with. You can't hook a customer AD up to ACS - you need something like ADFS on top of their AD.
I assume your cloud app. runs in Azure?
Then make your app. multi-tenanted. If your customers have their own Azure tenant, it will work. You just need to add the Graph API code to your app. ACS is not required.
Your customers then run DirSync. This keeps their Azure tenant in sync. with their AD changes.
So two options:
Customer does not have Azure tenant. They install ADFS and federate with AAD.
Customer's who do have Azure tenant use DirSync.
Good news: we have recently turned on the Application Roles and Groups Claim features in Azure AD.
Get a quick overview here: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/authorization-cloud-applications-using-ad-groups/
Hope that helps.
Groups aren't the best choice because they are unique within each directory. Unless you get your customers to define a set of groups that have well-known names and match against the strings, that is (the object IDs of a group is different per directory even if they have the same name). I'm actually from the Azure AD team and we are seriously considering releasing a feature to allow you to define roles in your app that your customers can assign their users to. Please stay tuned on this. In the meantime, unfortunately groups are the only way to go. You would have to call "GetMemberGroups" using the Graph to retrieve the groups that the user is assigned to.
What are your timelines for releasing this application? You can contact me directly to see if we can work with your scenario.