We have a corporative KeyCloak server which sits on Azure Account “A”.
We are now developing an ASP.Net Core Application that is on Azure Account “B”. This application is behind an Azure WAG.
The users access the application from the internet through the WAG and hits the Azure WebApp:
"https://myexternaldomain.com" => "https://myinternalazuredomain.azuresites.net".
As expected the users is redirected to Keycloak corporate server ("https://sso.corporate.com"). Once the user is logged in, he is being redirected to the callback address "https://myexternaldomain.com/oauth/callback".
At this moment we get a exception “Correlation Failed”, “Unknown Location”.
Architecture and Exception below:
Architecture and Exception
We believe that the problem is related to the address the users is using ("https://myexternaldomain.com") being different from the actual address the server is on ("https://myinternalazuredomain.azuresites.net"). And this makes even more sense when we take into account that it was working fine before the addition of the WAG.
Can you guys give us some insight?
Thanks
Best Regards
Take Care
There were a couple things that needed to be done to get KeyCloak + AppService to work in this scenario.
We had to add the same Certs to Wag and AppService, so KeyCloak would understand it as the same request.
Also the network team misconfigured the WAG, and some of the headers were not being forwarded, and KeyCloak would not accept the given Auth Token as valid for the current request.
Related
One Azure App service hosts a asp.net core API, another different Azure app service hosts a Web app. The web app can be accessed by end users that don't need to sign in (public). The web app calls the API. How can the API access can be restricted so that only the web app hosted in Azure can make calls to it, but end users cannot directly call the API end points, but the end users can still access the website (webapp)?
You asked a simple question that risks taking you down a rabbit hole. There are many ways to secure an API. The good ones require some thought.
On way is to involve a token server. The application and the token server share secrets. When application that wants to call an API, it is somehow redirected to the token server, and is granted a token. The session is redirected back at the API. The API checks with the token server that the token is authentic. If it is, the API serves the data, otherwise it fails.
This is an incredibly simplistic description of what really happens. Read everything in https://oauth.net/2/ for more details. Azure has mechanisms in the portal that can be used. https://identityserver4.readthedocs.io/en/latest/endpoints/token.html talks about how Identity Server could be used. There are other services of varying complexity and expense to do this. There are experts with varying rates that can help. I hope these couple links can get you started on your security journey.
you should be able to tweak the access restrictions of the app service to control the inbound access.
It allows to IP restrict/ Service tag based restrictions for an app service to accept traffic only from these entities.
I have an IIS website on a server internal to my domain that is also published via azure application proxy, which is secured using windows authentication. Our AD structure is hosted locally and published to Azure AD via AD connect.
Users visiting from outside the domain are authenticated first via the login.microsoftonline.com page.
My problem is that users external to the domain are on shared devices and need to change users occasionally, and I can't figure out how to do that.
I have read that navigating to an url like https://login.microsoftonline.com/{tenant id}/oauth2/logout?client_id={client id}&post_logout_redirect_uri={???} is supposed to achieve this, but after arriving at the login page and logging in as a different user, when we return to the site the user turns out not to be the user that authenticated, but remains the same user as before the attempt to change the user.
I have also read that deleting the cookies named like AzureAppProxyUserSessionCookie, AzureAppProxyAnalyticCookie and AzureAppProxyAccessCookie can help, but doing so does not seem to make any difference.
I thought that perhaps the browser was auto-authenticating or pre filling in forms etc, but turning those features off does not affect anything.
My questions are:
Are any log-off / log-on via Azure AD event logs kept that I can view, and if so, where?
How are you meant to log-off for my scenario?
I would like to secure my Azure WebApi with 3rd party providers (FB, G+... I basically just need a valid email). Was looking at Auth0 and seems like it will do the thing paired with Jwt middleware in web api project, but I was wondering if the same can be done using Azure only.
Azure Web App authentication confused me a bit - it does not seem to give anything to my Asp.Net web app. I still have to configure all the middleware in Startup.cs and the app still works fine if I completely turn authentication off.
I could do the same thing Auth0 does - issue my own Jwt tokens based on access tokens from FB or G+ - but would like to avoid that.
Could you please point me to the right direction?
You have a couple options:
App Service Authentication
Configure the authentication via middle ware
App Service Authentication
The App Service Authentication does not require any code inside your application because your App Service has a gateway that inspects request for authorization. Depending on the setting you can either secure the entire site or secure individual resources (by using the [Authorize] attribute on the endpoint in MVC/WebAPI).
With the latest release you can control authorization on a site by site basis including manually triggering the sign in by navigating the user to the <yoursiteurl>/.auth/login/<provider>. By defualt the token store is enabled so you can make a request to <yoursiteurl>/.auth/me and get back information from the provider.
Middleware Authentication
This is the default way authorization happens in the Single Page ASP.NET Template. The middleware authentication uses OAuth/OpenId to secure the resources. This option does it at the application layer instead of at the gateway. If you are using ASP.NET Identity (from the single page project template) the email from the persons log in will automatically be stored in the Users table. The tutorial in the link above gives lots of details on how to get it working.
Make sure you use the [Authorize] attribute to trigger the Authorization in either case.
Hope that helps you get started in the right direction.
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.
I have a ASP.NET application that need to access to ANOTHER application, the ANOTHER application expecting Kerberos authentication, it based on the user credential to response to the request. My ASP.NET app is running on a AD service account that is setup to allow delegate to the ANOTHER application (with proper SPN).
So the process is, user requests to the ASP.NET app, the ASP.NET app will impersonate the request to the ANOTHER application by delegation (with kerberos).
When I run the app in local machine (My ASP.NET resides), the request was successful, however, if the request is coming from remote client machine, it failed, from the ANOTHER application's log, it shows the Identity is not presented.
Any clue?
Have a look at the following which appears to be very similar to your situation:
https://serverfault.com/questions/270293/moving-my-website-to-different-server-changes-authentication-from-kerberos-to-ntl/270306#270306
There are some resources that that should help you troubleshoot.