I am exploring a possibility to implement Managed Identities for REST API hosted in Azure App Service. This Api consumes multiple third party APIs which are outside our control and secured by AAD.
Currently, we store AAD ApplicationId / Secret in the configuration. Whenever we need to consume any of the third party API, we follow below process -
Use ApplicationId & Secret to generate a Token
Call third party API with the token in header
During a call clientId in token is checked for authorization
Can I we use Managed Identities in this scenario?
Does this require code changes for any of thes APIs?
Can I be able to access ClientIds which I can onboard to third party APIs for authorization?
AFAIK, you may not be able to do that via MSI, MSI is used to let App service/Function app access other azure resources. If you enable the MSI of the web app, it will just create a service principal automatically without an AD App.
Is there a way to find out the ClientId of SPN which Managed Identity is managing?
It is possible, navigate to the Enterprise applications in Azure Active directory-> Search the name of your web app (you need to specific the Application Type filter with All Applications) -> in the Properties, you could find the Application ID, it is also called ClientID which you want.
But even though you could find it, you will not be able to generate the secret of the service principal. I think you could only do that with an AD App(App registartion).
Related
For my current ASP.NET Core MVC application I authenticate directly with a web app registered in Azure AD Portal. This provides me with an access token so on the backend of my web application I can use MS Graph with my users specific account (ie add files to their onedrive , email, etc). However, my organization also has Okta which a lot of applications authenticate against. So I was trying to determine to authenticate through Okta (which has a much cleaner sign in process IMO) as well as authenticate against Azure AD and get an access token. Through my research I found something in my web application registration in Azure AD called Workload Identity Federation. This led me to this useful video
https://www.youtube.com/watch?v=wZ0gCJYMUKI
and also microsofts info site:
https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation
This seems to answer what I want which is to use Okta but allow me to still use MS Graph for my users since it will authenticate against Azure AD (correct me if I am wrong and this is for something else). My issue is none of these resources really go into depth regarding how the access token is passed to my application so I can use MS Graph. My research this is called client credential flow since my application only has delegated permissions so it requires the users to log in and it basically allows my web app to act on their behalf when using MS Graph. So I am trying to understand and fill this void of information regarding how client credential flow fits into Workload Identity Federation and is this the solution to my problem.
We are running an API that is configured for and secured by Azure AD. This is working for us with an Angular app where users login interactively.
Now we have a need for a partner firm to use the API in a system to system way (no user login).
What needs to be configured for their application to get an OAuth token for our API from Azure AD?
I've examined the service to service call flow, but I'm wondering if it's best practice to create an application registration in our tenant for an application we don't own/manage. However this seems to be the fastest way to give them a client ID/Secret in order for them to interact with Azure AD.
Thanks in advance!
-Doug
Azure active directory supports the OAuth 2.0 to authorize the
third-party apps too. It doesn’t actually matter where the web APIs
are hosted.You can even see Azure Active Directory
recommendation on third party apps. It actually adds up security
and different type of apps can be integrated .
But you will need to have your web app authenticate to Azure AD, and
provide the token to the web api.so it requires app registration .
Scenario for external web app to call a web api, you can refer to
this:web-app-call-api
Your application can acquire a token to call a web API on behalf of
itself (not on behalf of a user) i.e; you can achieve scenario where
non-interactive app calls a web api
But if you meant app calling a partner api using another api .
The Azure AD V2.0 doesn't support the Partner API(See Restrictions on services and APIs) when you integrated the web API with third-party application using MSAL(Azure AD V2.0 endpoint) .
One way is using the on-behalf-flow. Here third-party application initially acquires the access token to call the web API. This web API acquire the token for Partner Center API and calls it using on-behalf-flow with that token. This solution uses the Azure AD endpoint instead of v2.0( register the app on Azure portal).
Other References:
asp.net web api - Azure Active Directory Verify Access Token in Web
Api outside of Azure - Stack Overflow
Authentication vs. authorization
I'm working on an application that has an angular 6 front end and a .net core 2.0 back-end and am trying to set it up so that my application authenticates users via Azure active directory. The issue is that I want the .net core back-end to do all the authentication programmatically when I have the front end pass an email and password. Everything that I've seen so far online suggests to have the front end redirect to the Microsoft login page but we are using our application as a boiler plate project and want to be able to change the type of authentication easily in the back-end without having to change the angular front-end. Does anyone know how I could go about this?
You can use Resource Owner Password Credentials Grant .The process will like that you collect the user credentials in Angular app and post to .net core back end , then finish the authentication in back-end app with user's credential. But that is not recommended because The ROPC flow requires a high degree of trust and user exposure and you should only use this flow when other, more secure, flows can't be used.
Also :
The Microsoft identity platform endpoint only supports ROPC for Azure AD tenants, not personal accounts. This means that you must use a tenant-specific endpoint (https://login.microsoftonline.com/{TenantId_or_Name}) or the organizations endpoint.
Personal accounts that are invited to an Azure AD tenant can't use ROPC.
Accounts that don't have passwords can't sign in through ROPC. For this scenario, we recommend that you use a different flow for your app instead.
If users need to use multi-factor authentication (MFA) to log in to the application, they will be blocked instead.
Reference : https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
We are looking to publish an API in an Azure B2C model where customers will use our app to access API's published using Docker Swarm based Azure Container Services. Our assumption here is that this model will require Azure B2C AD as opposed to Azure AD.
All API calls will have an OAuth token issued from B2C AD.
We want to know what is the best approach to validate the token centrally before it reaches the microservices on Azure Container Service. We were using API Gateway to route the API calls to the correct microservice while also using the WAF capability in the API Gateway. However, we realize that the API Gateway does not provide a way to verify the OAuth token before it forwards the request to the microservices.
Also please note, as per the suggestions in Microsoft Documentation we have two tenants with one tenant running all services such as database and microservice and the second tenant hosting the Azure B2C AD.
Can you please suggest the best option to implement the OAuth Verification without having to implement this in each microservice.
One thing you could do is put Azure API Management Service between your clients and services, there you'd have an option to use validate-jwt policy to inspect tokens and authorize calls.
The following is a quick overview of the steps:
Register an application (backend-app) in Azure AD to represent the API.
Register another application (client-app) in Azure AD to represent a client application that needs to call the API.
In Azure AD, grant permissions to allow the client-app to call the backend-app.
Configure the Developer Console to call the API using OAuth 2.0 user authorization.
Add the validate-jwt policy to validate the OAuth token for every incoming request.
Please refer to the following document for steps in detail.
I'm currently trying to implement a multi-tenant Azure AD application that will use Microsoft Graph API's to monitor and analyze Office 365 "metadata" for members of the tenant domain. For example, the application might monitor One Drive user space over time. The architecture of the application will include an AngularJS SPA client along with a web application back-end. The idea is that the web application allows for both local registration (e.g. traditional sign up using an email address and password) in addition to Azure AD authentication. In the case of local registration, the user might be able to associate an Azure AD tenancy with the local account in the future, for example.
I'm struggling to understand how various authentication mechanisms should work. For example, I think that there should be two levels of authentication in the case of Azure AD: one authentication for the users of the client SPA, and another authentication used by the back-end for making continuous calls to the Microsoft API's, requesting refresh tokens, etc.
How might this architecture be implemented using the various Azure AD authentication scenarios Microsoft has already provided examples for?
If my initial inclination that I will have two applications registered with Azure AD (for example, the SPA registered as a native application, say, and the web application registered by itself), how will users allow access to both of them, and what would this workflow look like? In addition, what would the flow of user requests look like? The SPA would make a request to the back-end using its Azure AD token, but what will the back-end do to receive its authentication token and make calls to the Microsoft API's?
How might I best incorporate Azure AD authentication along with local registration into my application?
Generally speaking, you can associate your each user to his entity in Azure AD tenant in your backend server / database. As every user in Azure AD has several unique properties in the entity object. You can use the user's email or objectId as mentioned at Claims in Azure AD Security Tokens as the external column in your user table.
When your user authenticate your site via ADAL.JS, you can grab the access token in your backend server via the Authentication header. You can use the access token to request for the resources protected by Azure AD. And the access token is a JWT token, which you can decode directly to get the user basic claims as we mentioned before. You can retrieve the claim which you stored in your user table and match the special user registered in your server for requesting the resource protected by your self.