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.
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.
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.
I have created an azure signalr service with serverless option.
The negotiate function is able to generate JWT token with 'x-ms-client-principal-name' and the connection gets established without issues.
I have referred https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-concept-serverless-development-config and the function is able to send events to a particular userid/groups.
I have been asked to secure the client - server communication.
I am new to security domain. I referred https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-tutorial-authenticate-azure-functions this link but I am not able to configure the given sample app and not able to understand the concept.
My scenario is: I have a Client .net web app in which user can login using organization account as well as using google.
This app calls azure signlar negotiate function with userID and the deviceId in which it is interested to receive events through signalR function.
Signalr function gets events from the azure eventhub trigger and sends it to the groups.
Please help me to increase the security of this application. Is the token received from negotiate function sufficient as far as security is concerned?
Can any unauthorized user connect to my azure subscribeToGroup/sendEvent functions with the acquired jwt token from negotiate?
I am trying to use this https://github.com/Azure/azure-functions-signalrservice-extension in which idToken and claimTypeList are additional parameters along with x-ms-client-principal-name(userid). But I am not able to understand this with respect to security.
The client in this sample is index.html with auth.js. But how it is said to be secure is not understandable.
Please help and direct me for the correct setup and code.
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.
I'm trying to design a green-field project that will have several services (serving data) and web-applications (serving HTML). I've read about microservices and they look like good fit.
The problem I still have is how to implement SSO. I want the user to authenticate once and have access to all the different services and applications.
I can think of several approaches:
Add Identity service and application. Any service that has protected resources will talk to the Identity service to make sure the credentials it has are valid. If they are not it will redirect the user for authentication.
Use a web-standard such as OpenID and have each service handle it own identities. This means the user will have to authorize individually each service/application but after that it will be SSO.
I'll be happy to hear other ideas. If a specific PaaS (such as Heroku) has a proprietary solution that would also be acceptable.
While implementing a microservice architecture at my previous job we decided the best approach was in alignment with #1, Add identity service and authorize service access through it. In our case this was done with tokens. If a request came with an authorization token then we could verify that token with the identity service if it was the first call in the user's session with the service. Once the token had been validated then it was saved in the session so subsequent calls in the user's session did not have to make the additional call. You can also create a scheduled job if tokens need to be refreshed in that session.
In this situation we were authenticating with an OAuth 2.0 endpoint and the token was added to the HTTP header for calls to our domain. All of the services were routed from that domain so we could get the token from the HTTP header. Since we were all part of the same application ecosystem, the initial OAuth 2.0 authorization would list the application services that the user would be giving permission to for their account.
An addition to this approach was that the identity service would provide the proxy client library which would be added to the HTTP request filter chain and handle the authorization process to the service. The service would be configured to consume the proxy client library from the identity service. Since we were using Dropwizard this proxy would become a Dropwizard Module bootstrapping the filter into the running service process. This allowed for updates to the identity service that also had a complimentary client side update to be easily consumed by dependent services as long as the interface did not change significantly.
Our deployment architecture was spread across AWS Virtual Private Cloud (VPC) and our own company's data centers. The OAuth 2.0 authentication service was located in the company's data center while all of our application services were deployed to AWS VPC.
I hope the approach we took is helpful to your decision. Let me know if you have any other questions.
Chris Sterling explained standard authentication practice above and it makes absolute sense. I just want to put another thought here for some practical reasons.
We implemented authentication services and multiple other micro services relying on auth server in order to authorize resources. At some point we ran in to performance issues due to too many round trips to authentication server, we also had scalability issues for auth server as number of micro services increased. We changed the architecture little bit to avoid too many round trips.
Auth server will be contacted only once with credentials and it will generate the token based on a private key. Corresponding public key will be installed in each client (micro service server) which will be able to validate the authentication key with out contacting auth server. Key contain time generated and a client utility installed in micro service will validity as well. Even though it was not standard implementation we have pretty good success with this model especially when all the micro services are internally hosted.