I am new to Nginx, so please bear with me if my question is obvious.
I am looking for ways to authenticate users to the Nginx server. From my research I've understood there are two primary options:
End-user sends a request that contains the private key (in the header for example) to Nginx, Ngnix sends the authentication to auth server and the Ngnix gets an answer if the user authenticated or not.
The second option is, Nginx plus (A service that costs money), and the Nginx handles the authentication process - If someone knows an open-source version of this option it would be the best.
I would really appreciate the help, thank you all!
The old good Basic authentication still exists, among with the ngx_http_auth_basic_module. Unfortunately the only algorithm that is implemented by nginx itself is the old and weak apache MD5, however using glibc based host systems you have some other options. You can find out more details here.
You can authenticate your users using client-side certificates. There are many articles all over the internet; here is the Client-Side Certificate Authentication with Nginx from the first search results page by google.
You can use the js_content directive from njs module as the auth location content handler (instead of proxying auth request to some backend app). Or you can do both things, you may find the Validating OAuth 2.0 Access Tokens with NGINX and NGINX Plus article to be very interesting.
You can implement almost every authentication mechanism you can ever imagine using the famous lua-nginx-module. Some useful links (again, from the very first page of google search results) are
Method of using Lua to write authentication module of nginx server
NGINX Lua OAuth Proxy Plugin
Nginx Lua script redis based for Basic user authentication
Although this one related only to Nginx Plus, to made the answer complete I had to mention ngx_http_auth_jwt_module and a few official articles from F5:
Setting up JWT Authentication
Authenticating API Clients with JWT and NGINX Plus
Related
In the interest of avoiding yak-shaving, I'll try to provide as much context as possible.
We have an internal application that's also available on the public internet. This application runs on several instances of Apache on the IBM i - most of these instances require http basic authentication, except for one instance that acts as the 'welcome page' so to speak. This 'welcome page' has no authentication, but acts as a navigation hub with links for the user to go to other parts of the app (which DO have authentication and run on different instances of Apache).
We also have some documentation stored in Confluence (a wiki application) that runs on a separate server. This wiki application can display the documentation without requiring authentication, but if you authenticate, you then have the option to edit the documentation (assuming you're authorized to do so, of course). But the key is that the documentation is visible without requiring authentication.
My problem is: we want the documentation in Confluence to be accessible from within the main application (both when being accessed internally and over the internet) but, because the documentation is somewhat sensitive, we don't want it accessible to the internet at large.
The solution we came up with was to use a reverse proxy - we configure the Apache instances on the main application such that requests to /help/ on the main application are proxied to the confluence application. Thus, the Confluence application is not directly exposed to the Internet.
But this is where the problem starts.
If we just proxy /help/ through the main application Apache instance that doesn't require authentication, then the documentation is available from the main application without a problem - but since you don't require authentication, it's available to everyone on the Internet as well - so that's a no-go.
if we instead proxy '/help/' through the main application Apache instances that DO require authentication, it seems as though the basic authentication information is passed from the main application servers onto the Confluence server, and then we get an authentication failure, because not everyone who uses the main application has an account on the Confluence server. (For those that do, it works fine - but the majority of users won't have a Confluence account).
(Possible yak shaving alert from this point forward)
So, it seems as though when dealing with HTTP Basic authentication, if you set up proxy configuration from server A to server B, and set up the proxy on server A to require http basic authentication, then that authentication information is passed straight through to the server B, and in this scenario, server B complains since it doesn't expect authentication information.
My solution to that problem was to set up 2 levels of proxying - use the Apache instances requiring authentication to also require authentication for the proxy to /help/, but have /help/ proxy to a different server (Server C). This Server C doesn't require authentication but is not exposed to the internet. And Server C is configured to proxy /help/ to the actual Confluence server.
I did this on the basis of proxy-chain-auth - an environment variable which seems to indicate that by default, if you have a proxy chain, the authentication information is NOT automatically sent along the chain.
Alas, this did not work - i got an authentication error that seems to indicate that Server C did in fact proxy the authentication info onwards, even though i did not set proxy-chain-auth.
So, that's my yak-shaving journey.
I simply want to set up a configuration such that our documentation stored on Confluence requires some sort of authentication, but that authentication comes from the main application, not from Confluence.
(Without the requirement of having it accessible over the internet, none of this would've been an issue since the Confluence server can be viewed by anyone on its network without a problem).
I hope my question is clear enough - I honestly don't mind being pointed in a different direction to achieve the main goal, with the caveat that I can't change the main application (or Confluence for that matter) from using HTTP Basic Authentication.
Ideas, anyone?
PS. To retrieve the documentation from the Confluence server, I'm actually using their REST API to retrieve the page content - i don't know if that has any relevance, but I just wanted that made clear in case it does.
It turns out that the solution to the issue was pretty straightforward.
For my second proxy that does not require authentication, I had to change the Apache configuration to remove any authorization headers.
RequestHeader unset Authorization
This stops the authentication information from being passed from the second proxy onto Confluence.
Hi guys this is my first time trying to handle Oauth in my project. I have read the tutorials on link. I have tried Google and Facebook Oauths and amazed by how simple it is. Now I am going to try Twitter / Yahoo / Microsoft just for learning purposes. This question might land me negative points as it is a learner question. So my question is when using Facebook Oauth you need the SSL Https URL for LocalHost machine. How about Yahoo/ Twitter/ Microsoft. Which one needs SSL.
When using OAuth, you should use SSL. As a matter of fact, Twitter requires SSL on all of their endpoints as of today. If you study the protocol, you'll see that there are tokens being passed back and forth in the Authorization header. You'll want to protect those. You also want protection on the responses from the provider, which contain tokens and other info. Some applications might not require SSL (though Twitter does now), it's best practice to be secure by design, secure by default, and secure in deployment.
No - your localhost machine does not need to be running SSL.
Indeed, even if you're not using localhost, there's no obligation to use SSL. Theoretically, there's little risk if your tokens do get intercepted, because your private tokens never leave your machine.
So, the OAuth dance can be
User -> Your Website -> SSL to OAuth provider -> Redirect to localost (non SSL)
I am writing an HTTPS web server using express.js. It does not have super secure, I think ssl certificates is overkill and not a good option for client apps. I have routes for my restAPI. There will be a login page. So I will have a user/password pair available to me.
Can I use this information alone to allow access to my HTTPS routes ?
I think you're asking whether basic auth over https is secure. The answer is yes, that's a reasonable security architecture, and is widely used for authenticating APIs. It's fine to route based on the basicAuth credentials. If you start worrying more about security, focus on how to safely store passwords.
I was wondering if the twisted webserver offers the possibility to restrict access to some resources using client certificate based authentication and to allow access to other resources without certs.
I searched trough the questions and found this posting: Client side SSL certificate for a specific web page
Now my question is if someone knows if twisted has implemented the ssl renegotiation and how an example would look like.
Or has there been a different approach since then?
Just to make things clear and to give additional information:
What I actually want to achieve is something like this:
A new user visits a site and has not yet granted access to the resource because he has no token yet that allows him to view the site.
Therefore, he gets redirected to a login resource that is asking for a client certificate. If everything is correct, additional data retrieved from the certificate is stored in the session, which makes up the token.
He then gets redirected back to the entry site, the token is validated, and according to his authorization level specific content is displayed
If I understood you correct Jean-Paul, this seems to be possible to implement with your strategy, right?
Correct me if I'm missing something or doing it wrong.
It doesn't seem to me that SSL renegotiation is particularly applicable here. What you actually want to do is authorize a request based on the client certificate presented. The only reason SSL renegotiation might be required is if you want the client to be able to request multiple resources over a single persistent HTTPS connection, presenting a different client certificate for each. This strikes me as unlikely to be necessary (or at least, the reasons for wanting this - rather than just letting the client establish a new HTTPS connection, or just authorizing all your resources based on a single client certificate - are obscure).
Authorization in Twisted Web is straightforward. Many prefer a capability-like approach, where the server selects a resource object based on the credentials presented by the client. This resource object has complete control over its content and its children, so by selecting one appropriate for the credentials presented, you completely control what content is available to what clients.
You can read about twisted.web.guard in the http auth entry in the web in 60 seconds series.
This will familiarize you with the specifics of authentication and authorization in Twisted Web. It will not tell you how to authenticate or authorize based on an SSL client certificate, though.
To do that, you'll need to write something similar to HTTPAuthSessionWrapper - but which inspects the client SSL certificate instead of implementing HTTP authentication as HTTPAuthSessionWrapper does. This will involve implementing:
IResource to inspect the transport over which the request is received to extract the client certificate
implementing a credentials type which represents an X509 certificate
implementing a credentials checker which can authenticate your users based on their X509 certificate
and possibly implementing a realm which can authorize users (though you may have written this already, since it is orthogonal to the authentication step, and therefore is reusable even if you don't want to authenticate with SSL certificates)
This functionality would be quite welcome in Twisted itself, so I'm sure you can find more help from the Twisted development IRC channel (#twisted-dev on freenode), and I hope you'll contribute whatever you write back to Twisted!
I have a server with SSL certificate and would like to implement a WCF service with username authentication. Can anyone point me to a simple current example?
I find lots that use the 509 certificate and I don't understand why that additional piece would be needed. I don't think I want to give the certificate I have for the SSL to the client either.
I think to use SSL is just setting up the web.config appropriately with wshttpbinding and using https: in the uri that calls the service.
In this case I will have only one or two users (applications at the client actually) that need to use the service so I don't see the overhead for building a database for the store for lots of login credentials or anything like that. I've read you can pass the credentials in the request header. I hope I can just have the service itself check them without tons of overhead.
I'm really struggling to get how a simple authenticate can work for a service but I know I need something in addition to the service being SSL encrypted.
Edit: Hummm having read more I get the impression that using https binding for the message circumvents any notion of username credentials without something mysterious with certificates going on. I hope I haven't wasted money on the ssl certificate for the server at this point.
Can the IP of the requestor be used to allow the service for a known client only?
If you only need a couple of users, then use the inbuilt Windows authentication - create Windows user accounts, put the right security option in your binding config and you're done. If you're using SOAP from a non-windows client you'll have to perform some tricks to make it communicate properly (typically we found using NTLM authentication from PHP client required the use of curl rather than the PHP SOAP client library, but I understand that if you use AD accounts this becomes much easier).
WCF docs have a full description of auth options for you.