I have a on-premise API that use OAuth, so I use the "Authorization:Bearer ..." header when calling it from on-prem. Now I want to call this API from external using Azure Application Proxy with authentication. I know how to acquire a Bearer Token to authenticate against the Application Proxy.
The problem is that in the same HTTP Call to the on-prem API from external, I need to have 2 different "Authorization:Bearer ..." headers, one for the Application Proxy and one for the on-prem API.
I cannot just have 2 Authorization headers, right? So how do I call my on-prem API from external?
Edit : I've never found the real solution so I built an "On-Premise Proxy" that swap Authorization:Bearer after the Azure App Proxy. Here's how it works :
The outside app inserts 2 headers with the call to Azure App Proxy (AAP). First is Authorization:Bearer with the token required by AAP. The second is a dummy header "AuthorizationOnPrem" with the token that is required by the app behind the Azure Proxy (on-prem).
The Azure Proxy redirect the call to my custom "On-Premise Proxy".
This On-Prem Proxy copy the token from AuthorizationOnPrem to Authorization.
Then the On-Prem Proxy call the real on-prem app with the same data that it got called but with the right token.
I know it's quite patched but it worked for me with the on-prem app I needed. And it was surprisingly easy to do. Might not scale well though.
Related
Currently doing some research to setup an (azure) api gateway with oauth (jwt token) security.
an external partner/app sends a request to an api endpoint published on the gateway including a valid JWT-token in the header that gets validated by the gateway against AzureAD for example. When validated the request is routed to the backend service. No problems here.
My question is, what is best practice for the external app to obtain that JWT-token (to use for the api call) ?
Obviously, It could send a request to AzureAD with a clientid+secret to obtain a valid JWT token. But to do so it has to call my internal AzureAD directly ? Is this the way to do it ?
or should I expose a 'get-jwt-token' api on my api gateway and route that request to AD ? How should I secure that API ? with basic auth ?
or am I missing something, and is there a much better best/proven practice ?
HOSTING BEST PRACTICE
A reverse proxy or API gateway is placed in front of both APIs and the Authorization Server (AS). This ensures that an attacker who somehow gains access to the back end entry point cannot access data sources.
OAUTH REQUESTS TO GET TOKENS
OAuth requests are typically proxied straight through the reverse proxy / API gateway to the AS with no extra logic. All credentials, auditing of login attempts etc remain in the AS.
MANAGED SERVICES
If using Azure AD as a cloud managed AS, this is a special case: the system is already hardened for internet clients, so most companies don't add their own proxying - though it is possible to do so.
FURTHER INFO
The first of these covers the infra setup and the second gives you an idea of extensibility options once a reverse proxy / gateway is in place.
IAM Primer
API Gateway Guides
I have been trying to configure access to an on-premise Web API from a native application using this walkthrough: How to enable native client applications to interact with proxy applications
According to the walkthrough,
"To support native client applications, Application Proxy accepts Azure AD-issued tokens that are sent in the header."
However, regardless of the tokens that I send in the request header, the proxy always responds with HTTP 302 and redirects me to the sign in page.
Has anyone been able to pass Azure app proxy pre-authentication using a token?
I'm running a hello world azure function app with an HTTP trigger in a windows container on-prem (yay!).
The question I have now is is it possible to impersonate the user initiating a request from the HTTP trigger? The goal is to allow the function to talk to our in-house authorization system and get back an authorization token.
Could it be just a matter of changing the authorization level to something like Authorization.User?
It's possible. We send identity info to the Http Trigger, it talks to authorization backend and brings back a token to the trigger, we get the token as a response of the Http trigger.
Since it's an in-house authorization system we can't rely on the authorization level of Http trigger. It is used for Functions deployed in Azure site, where we need to provide a corresponding key to access Http trigger secured by different auth level.
BTW, the auth level should always be anonymous(e.g AuthorizationLevel.Anonymous in c#) if we work with Http trigger in on-prem container. Because locally we don't have any key to access the trigger secured by level other than anonymous.
I have a web app configured in my Azure AD.
On a machine, i have installed a connector and configured an application proxy with that connector.
I am now trying to connect from an Android mobile application to the web app through the application proxy.
If I use a WebView inside my app, I can load the User access URL, enter my credentials and I receive a cookie for use by following connections.
I need to be able to use other HTTP clients that do not have the possibility to show UI.
I was wondering if it was possible to somehow request access and refresh tokens, and add those to future requests. or if possible convert them to a cookie in some manner and add that in a header.
Your client app can simply use MSAL (or ADAL, or another OpenID Connect client library) to sign the user in and an access token for the App Proxy app. Then you can include that token in the Authorization header in requests to the endpoint from App Proxy. App Proxy will recognize it, validate it, and (if everything checks out) proxy the call down to the App Proxy connector, where the rest of the process happens as normal.
Here are the relevant docs: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-native-client-application
This may sound a silly question...
I want to authenticate an end user that connects to a webapi service against Azure AD.
The Web Server (where the webapi service is hosted) is located in a zone without internet connection due to security reasons, behind a reverse proxy.
The client (end user) is at home with internet (of course) and connects to the webApi service through the reverse proxy.
Does all/any of the available authentication methods against AZURE AD require that the server that hosts the webapi service has Internet connection?
Thanks
You can do this! :) As long as there is internet between the client and the identity provider (AD), you can always obtain a token and send it to the API - the API does not need a live connection to authenticate, it just needs to validate the token supplied by the client in the call.
The only tricky part is that today's OWIN middleware automates the acquisition of the token validation parameters by reading a discovery document hosted on Azure AD. That is clearly not an option in your case, but what you can do is to acquire that document out of band and use the info you find in there to initialize the middleware manually. Unfortunately we don't have samples that show how to do this, but let me see if I can get a snippet to post here.