I am working on one API which will be exposed to a couple of external clients. And I would like to limit access to my API and let only trusted 3rd parties access my API. I have found that Azure API Management provides subscription keys, which can be used to protect API - https://learn.microsoft.com/en-us/azure/active-directory-b2c/secure-api-management?tabs=app-reg-ga
Moreover, I see that I can connect my API to Azure AD - https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad, which might be useful if I want to restrict access based on roles and types of external systems (for example some external systems will have one role that allows using some additional features)
Could you please help me to understand all other cases when I must use Azure AD instead of subscription keys? And can I use them together?
I also would like to understand which approach is the best for me if you want to give access to the client apps (browser, mobile apps and etc.). As I understand, Azure AD B2C can be the best option here
For your requirement, if APIM is not necessary (you do not need to configure the exposed url of your api by APIM), I suggest you to just use Azure AD to protect your api. You can refer to this document.
If APIM is necessary, and your requirements do not need to limit multiple permissions for different role to access the api (in other words, you just want client can/can't access the api). You can implement it just by subscription key as you mentioned in your question.
If APIM is necessary, and your requirements need to provide different permissions for different roles to access the api, you can do it as the second document link you provided. You can validate the roles or other claims of access token to provide different permissions to client.
Related
I'm adding an external identity provider, Azure multi-tenant, as a login option. I have local accounts right now and they know nothing about Azure AD users.
I want to create an Azure Enterprise App that other tenants can use to set up SSO using OpenID Connect. Also I want the app to support User Provisioning by setting up a SCIM API.
I can't really find any documents on how to handle linking Azure AD users with the existing accounts in my IDP. I've seen examples where users can login using their local account, authenticate with Azure, and then their local account is updated to have the Azure AD User ID. This approach still seems pretty manual. Another thought was to have a step in the login journey, where if no local account has the Azure AD User ID then find a local account with the same email. I don't like this approach either since the emails might not always match. Is there an approach where an admin can automatically link all accounts with a sync or upload?
SYSTEMS
First it's worth clarifying roles:
Role
Details
Authorization Server (AS)
Your UIs and APIs receive tokens from this. It is where accounts and linked accounts are stored. It is where you use SCIM to update account records. It is where you apply account linking logic.
Identity Provider (IDP)
There can be multiple of these. When your apps call the AS it manages connections to them, and exchanges IDP tokens for AS tokens that are returned to apps. It is not usual to use SCIM against an IDP.
You are using IdentityServer as the AS so your UIs and APIs will continue to use IdentityServer tokens and remain simple. Meanwhile Azure AD will become an alternative IDP. So on the data side of things your architecture is in a good place.
AUTHENTICATION ACTIONS
I would aim to solve your problems via custom authentication actions, and to design this in a vendor agnostic way. Not all providers support these concepts, but IdentityServer has some pretty good extensibility features, so hopefully it has what you need.
A bit of code, configuration and technical investigations in IdentityServer feel like the correct direction, with no complexity added to your applications. I will describe techniques in terms of Curity (where I work), but the same principles can apply to any system.
USERNAME AUTHENTICATOR
A great way to deal with user specific differences is to make the initial screen prompt only for an email. See this example for how that looks. Later, when authentication has completed, you could set a cookie so that this screen is not shown on subsequent logins.
Then, before asking for credentials, apply some scripted logic, eg to look up existing account attributes, and decide how the user should authenticate. You might decide to route unknown users to Azure AD or do something based on business partner email suffixes.
DATA UPDATES
Something simple that might work in advance of adding Azure AD support is to assign all users a Tenant ID, and perhaps existing users get a Tenant ID of 1. Only those users are allowed to sign in with Identity Server - all others have to use Azure AD.
SCRIPTED LOGIC AND ACCOUNT LINKING
For a worked example of how this looks, see this Account Linking with Facebook tutorial. In this example the objective is to update the main account with a new linked account. This account linking doc may give you some additional ideas for your scenario. It should be possible to run custom logic before triggering authentication or once your have the Azure IDP attributes.
INVOLVE THE USER IF NEEDED
It may also be useful to present a custom screen to ask the user if they have an existing account when they first login via Azure AD. If not then an Azure AD login can create the primary account in IdentityServer data in addition to a linked account.
USERS AND PARTNERS
How users onboard is interesting, and discussed in this detailed article. I always start by getting a feel for the type of assets involved:
Type
Description
Personal Assets
You allow any user to sign up and they only have access to their own assets
Corporate Assets
Users are provisioned by an administrator, eg a banker is granted access to financial data according to business rules
In your case it feels like users are from the second category, so to enable a user to fully sign up you need data from the partner, either fed in manually or by getting them to call your API, before you can assign the user the correct tenant ID. This might eventually result in TenantID=23, but there is nothing to stop you initially allowing users to onboard and placing them in a default TenantID=0 bucket.
Ultimately this all comes down to data, claims and API authorization. Eg APIs could return certain data to TenantID=0 users but only return privileged data to users whose tenant ID has been asserted by an administrator. Not sure if these thoughts of mine match your scenario but hopefully they provide a useful hint or two.
SUMMARY
Reliable account linking is tricky, but it should be solvable via the building blocks of the Authorization Server, using the above techniques. The end result should be deterministic user data, with no duplicate users.
I have an existing IdentityServer4 installation that is used to federate users between things like Google & Microsoft into a single login identity. In my situation, there are no local user credentials/passwords. Just the identity with an associated external provider. I'm trying to migrate to using Azure B2C and am hitting some roadblocks.
I've found that if I use the same ClientId and ClientSecret that IdentityServer is configured with, then I get the same IDs for users when signing in via an external identity provider. Which is great because I need them to be the same in order to try and migrate accounts over by reading them from the existing MSSQL database, and importing into Azure B2C using MS Graph.
I need to allow both Microsoft work accounts, as well as personal ones. So I need to use custom policies to allow for a multi-tenant configuration, since the built in provider doesn't support this.
However as soon as I flip my implementation over from the built in user flows and provider, to using custom policies, I don't get the expected issuerAssignedId anymore. Originally, the IDs looked something like AAAAAAAAAAAAAAAAAAAAAHGFdaj94jfdsgjifdh4ngd (made up, but you get the idea). Now with the custom policies, the issuerAssignedId being recorded in the B2C user looks like a GUID. So not just a different value, but a total different format. Am I missing something here? What would happen if someone has an fully operational AzureB2C install with built in functionality, and later identified a need to move to custom policies. How would users ever be able to look into their existing accounts with an external identity provider?
My TechnicalProfile for the multi-tenant sign is is essentially copy/pasted from their documentation, so I'm not sure what the deal is here?
I have successfully configured qn Azure AD App Registration, allowing a client_credentials based OAuth 2.0 flow to work. This allows a third party application to access Microsoft Graph API. The app has "Calendar.Read" permission. Meaning the app can pretty much read any of the calendars (including CEO's).
I now have a conversation with security. What is out there in the Microsoft world, that I can use to lock down usage of API access via this Application Permission? Is there ability to do things like:
Restrict IP ranges the App can be accessed from?
Restrict users that can access the App? (However in Client_credentials, there is no user context)
Log traffic / activity happening via the App?
The only thing i can think of now is to say the Redirect URL configuration on the app means, no other application can get an access token using the Client_credentials, even if the application id & passkey get compromised
Any advice on further security controls that can be put in place?
Restricting access: You would need to do this in your application. The Client Credential flow doesn't allow for restricting what users as you point out. However there is nothing stopping you from adding user authentication to your application, possibly using a delegated graph auth flow to determine who they are.
IP Ranges: This is not possible currently.
Logging Traffic: This is not possible on the graph side currently, however you could/should log traffic on your applications side.
Redirect urls will not help you because they are not used int eh client credential flow.
In general application only auth (client credential flow) + a broad authorization scope is very powerful, but must be managed correctly. You don't inadvertently want to build a totally new users/permissions model over the top of the graph :)
There are very few options available currently available to offer these controls at token issuance (in Azure AD) or at API access (in Microsoft Graph). However, you can achieve similar results by carefully managing access to the app's credentials. Here are a couple steps you can take (not exhaustive):
App credentials: keep them secret, keep them safe
Use Key Vault. You can configure many of the restrictions you mention for access to data in Key Vault, including IP ranges and which users access. Key Vault also offers auditing of access to secrets. Don't forget to also be careful about which users have management access to the Key Vault (e.g. other users with access to the same Azure subscription).
Use certificates (public/private key pair), rather than client secrets (passwords), to authenticate the app. People tend to manage certificates much more carefully than they manage shared passwords, and developers are much less likely to hard-code the secret into scripts/code.
Be careful and deliberate about which users can manage the app's credentials
This is often overlooked. A user (or another app) who can access existing credentials, or add a new authorized credential to an app can act as the app and (mis)use all the permissions the app has been granted. This includes:
Users (and apps) in the "Company Administrator", "Application Administrator" and "Cloud Application Administrator" directory roles.
Users who are set as owners of the app registration (Application object) and enterprise app (ServicePrincipal object) for the app.
Users (or systems) who have access to the server or service the application resides on (which will have, or have access to, the credentials).
For all of these cases, ensure this is the smallest possible number of users, and they actually have a legitimate need. For users who do need access, wherever possible enforce just-in-time, time-limited access (not persistent access), such as with Azure AD Privileged Identity Management, for time-bound, just-in-time access for Azure AD directory roles and Azure resources.
What is the correct way to provide users with programmatic access to APIs?
I have an application composed of many services (all trusted services, within the same domain, not external applications), and identity service in the same domain.
I would like to allow a user to user a set of credentials to gain access to any of the APIs I provide.
Is it reasonable to think of a user as a client in this case, and use clientCredentials flow to get a token that will be passed to the target API? specifically, is it a good idea automatically assign a clientId and a clientSecret to every user in my system, and allow all users to use clientCredentials flow to request an access token? the access token would then contain all user's claims. If this is a reasonable approach, is there any way to remove the "client_" prefix from the added claims? or is that a bad idea?
This was originally asked here: https://github.com/IdentityServer/IdentityServer4/issues/1877
I am looking at a scenario wherein we would like to provision (i.e. create) users programmatically into AD from our app. I was wondering if AD offers any kind of SOAP based APIs that can be used for this purpose.
Anyone have experience / information regarding such a scenario?
ADFS doesn't have any users. Authentication (and "users") are always in Active Directory. There are many APIs to interact with AD. (e.g. Directory Services)
I'm not aware of a SOAP based API, but you could build one wrapping the API described above. Also, I would look into whether this is really necessary. If the provisioning engine is meant to be run in the same domain (e.g. on-premises) then you would not need SOAP.