Is there an apache authentication module out there, that can blindly trust a header?
For instance if a reverse proxy were to put the user "mboorshtein" into an http header is there a module that take that header and set the correct data structure in httpd? (2.2.x). I know its insecure but this is just for a prototype, before I go and implement a custom authentication provider.
You can use probably use Apache anonymous auth. It doesn't help you build a new module, though. And the header must be the same as what basic auth uses (i.e. Authorization). For this to be secure, you need to make absolutely sure the server won't accept requests from any other host than the reverse proxy.
http://httpd.apache.org/docs/2.2/mod/mod_authn_anon.html
Related
I have an internal REST API (running as a Windows service on a specific port number) that needs to be setup for external access. It only supports/requires NTLM (Windows) authentication and doesn't accept another authentication method. However, the client only supports Basic authentication.
Is there a way to set-up a (Windows-based) reverse proxy server, that is able to accept "Basic authenticated" requests and can pass them through using NTLM authentication instead? So, basically what I'm looking for, is a way to change the authentication method from Basic (client) to NTLM (server).
A simple IIS url rewrite won't solve this matter, of course. I thought I had found a solution here, however, I guess this will only work if both client and server authenticate via NTLM (and thus only acts as a "passthrough" solution), which is not what I'm looking for.
Does anyone know a way of solving this?
I have configured TLS Mutual Authentication on my Apache server.
The server now accepts calls only if they specify a certificate that was signed by a CA that I have added in Apache.
Everything works, but I need now to use this configuration to actually authenticate the user: Apache is used to proxy (via ajp) requests to a java application. This java application is expecting the username in a predefined header parameter.
Is there a way to configure Apache to get the username from the certificate and automatically set the expected header parameter?
You can use mod_ssl's SSLUserName for this, or mod_auth_basics AuthBasicFake.
I never liked the latter because instead of just acting as authentication provider it makes you set a dummy password then let a real authentication module validate it.
Another option is this third-party module which like a certificate-specific AuthBasicFake without the password stuff:
https://github.com/covener/apache-modules/blob/master/mod_authn_cert.c
I am connecting to an external soap endpoint using Apache CXF. I am going through a proxy server (using credentials) before I hit the https/SSL external endpoint. The team that supports the external web service is saying that they do not see my basic authentication header. I logged the header and payload from my workstation before just before it leaves my workstation. I can see both the basic authentication and the proxy authentication headers.
My question is really twofold:
1. At what point is the SSL message from my computer actually encrypted?
2. Is it possible for something in the network to be dropping the Basic authorization header?
3. What additional troubleshooting steps can I take?
I found the issue, my proxy server was dropping any header with the word Basic in it.
Thanks,
Brian
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.
I have an Apache/2.2.15 web server with the modules, mod_shib, mod_ssl, and mod_jk. I have a virtual host which is configured (attached below) with AuthType Shibboleth, SSLCertificates, and JKMount to direct requests using AJP to my Tomcat 8 server after a session is successfully established with the correct IDP. When my http request reaches my app server, I can see the various Shib-* headers, along with the attributes my SP requested from the IDP.
Is there a way my app server can validate the shibsession cookie or other headers? I am trying to protect against the scenario where my web server, which resides in the DMZ is somehow compromised, and an attacker makes requests to my app server, which resides in an internal zone.
Is there a way I can validate a signature of something available in the headers, to guarantee that the contents did indeed originate from the IDP, and were not manufactured by an attacker who took control of my web server?
Is there something in the OpenSAML library I could use to achieve this?
Is there a way my app server can validate the shibsession cookie or other headers?
mod_shib has already done that difficult work for you. After validating the return of information from the Identity Provider (IdP), mod_shib then sets environment variables (cannot be set by the client) for your application to read and trust. Implementing OpenSAML in your application is unnecessary as mod_shib has done the validation work for you.
From the docs:
The safest mechanism, and the default for servers that allow for it,
is the use of environment variables. The term is somewhat generic
because environment variables don't necessarily always imply the
actual process environment in the traditional sense, since there's
often no separate process. It really refers to a set of controlled
data elements that the web server supplies to applications and that
cannot be manipulated in any way from outside the web server.
Specifically, the client has no say in them.