I've been playing around with API Management and it looks great. The only issue I have is that when calling an API you need to pass a subscription key, which is linked to a 'User'. In the majority of use cases the caller of our APIs are Applications (back-end services).
Am I supposed to be creating a User account per Application, or is there another way for me to obtain a security key for the App?
I have had a brief look at AD, however I don't want to go down that route straight away.
Thanks
You can create a single "API Consumer" user and use the key assigned to that user for all your back end services. Or you could create a separate user for each of your services. But creating a separate user you would have the ability to independently revoke access to certain services and control rate limiting/quotas independently.
Related
I am building a Blazor Server web app that will have locked features only accessible via paid subscription (payment handled with stripe).
I am using Azure AD B2C for user management/authentication.
I also have an Android and iOS app built with Xamarin, from which users will be able to subscribe to the service (payment handled with Android/iOS built-in payment service), and therefore have full access to the web app.
What is the right approach to save the fact that a user has completed payment, and retrieve that data on future sign up ?
I read about custom attributes in Azure AD B2C, so maybe I should build the system on top of Azure AD B2C, but I am not sure it is the appropriate approach for this use case.
Thanks in advance
Yes, you could use a custom policy and custom attributes if you have a simple system where you just want to store a value and deny access during login if the value is not set.
For anything more complicated, rather store all the details in a DB and access it via a REST API.
Update
You can access the attribute direct from custom policies. You just read and write it like any other attribute.
If you want to use the Graph API, be aware the name is different.
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 am the primary developer on a multi-tenant SaaS web application hosted in Microsoft Azure. We use Azure AD for all authentication. Because our application holds personal information, we and our customers want a way to restrict access to specific users. We just need a simple yes/no restriction in place so only assigned users may access the application. We've considered Application Roles, but it seems like a lot of overhead when the only needed option is "authorized".
While researching this, I came across the following "User assignment required" property in Azure AD.
User assignment required property in Azure Portal
After some testing, I found that it functioned exactly as we need it to. The customer has full control over which users may access the application, and neither party has to configure Application Roles. The only downside is that this property is configured on the customer's end. Is there a way for me, as the developer, to require this setting? Or perhaps a way to enable this setting by default?
Clarification: The end-goal is minimal configuration done by the customer. If "User assignment required" can be enabled by the developers (before customer registration), that would be ideal.
Basically you cannot specify it in advance, it is up to the customer's administrator to set up the requirement.
This is their concern, not your application's concern.
One possible way would be to set appRoleAssignmentRequired on the created Service Principal to true via a Graph API call.
But that will require quite privileged access, with their admin logged in.
Service Principal entity reference
Get SP by app Id
I am working with azure API management and struggling on authentication.
Though subscriber key is an option but the question lies like if there are going to be 100's of users it will be very difficult to manage keys of all users
Also I dont want azure AD as an authentication mechanism.
I want to use security provided by API management.
I also tried with token based approach of API management but the thing is it do requires subscriber key in the headers. If I want to get rid of subscriber key
what is the best option ?
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