Proxy server doing NTLMV2 authentication

[cirruslogic]

We are going to host a Tomcat web app in an external server in the cloud. Now because of security this server cannot have any settings of our domain controller and any NTLMV2 credentials. Our intranet users will be using the external web app and it must be SSO. So what we want to have is another Tomcat server in the DMZ acting as a proxy. This server will SSO authenticate the intranet user and then pass the username to the external web app for access rights determination before returning the response to the client. Will this work and what configuration needs to be done in Tomcat, what Java filter needs to be used, How do I use the Waffle API?

[Daniel Doubrovkine]

This will work, and will be secure as long as your cloud service and proxy share some real secret for authentication. The cloud service has to trust that when the proxy in the DMZ tells it that the user is X, it's actually the user X :)

I don't know what you're using for proxy, but lets assume it's something running inside a Tomcat container. In this case start by deploying the proxy 'normally' as a filter with Waffle doing SSO and make sure it works to serve some page (see https://github.com/dblock/waffle/blob/master/Docs/ServletSingleSignOnSecurityFilter.md). Once you have that, you can extract the current user ID (use SIDs) from the authenticated user principal in your code that will need to inject it into, say, a header and then forward the request. This is really your proxying implementation. There's an example of how to do it from a JSP page here: https://github.com/dblock/waffle/blob/master/Docs/tomcat/TomcatJSPDemo.md. 

If/when you get this working, would appreciate at least a doc that explains how to do this, it's a generally useful example and you should definitely get a proper security review - I've seen many people mess up proxying big time and doing things like forwarding someone else's request to a back-end, returning data that belonged to other people.

On Thu, Apr 4, 2013 at 8:19 AM, cirruslogic <anthony...@gmail.com> wrote:

We are going to host a Tomcat web app in an external server in the cloud. Now because of security this server cannot have any settings of our domain controller and any NTLMV2 credentials. Our intranet users will be using the external web app and it must be SSO. So what we want to have is another Tomcat server in the DMZ acting as a proxy. This server will SSO authenticate the intranet user and then pass the username to the external web app for access rights determination before returning the response to the client. Will this work and what configuration needs to be done in Tomcat, what Java filter needs to be used, How do I use the Waffle API?

--
You received this message because you are subscribed to the Google Groups "waffle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to waffle-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

dB. | Moscow - Geneva - Seattle - New York
dblock.org - @dblockdotorg

[cirruslogic]

Daniel, thank you for replying.

How does this thing work? Does this mean that within the the Tomcat servlet in the DMZ in our organisation (and this is also the proxy web app), the Waffle API is the filter class and we use something like Apache's httpclient pass the client requests + username (after a successful authentication) to the cloud web app. And the session variables/cookies need to be passed through this proxy to the cloud app?

[Daniel Doubrovkine]

Yes, that's how I see it.

An important thing though is that I don't have the context of your application. Context changes everything and sometimes little details matter a lot.

Another possibility for your system may be to do single sign-on via the client, say OAuth2. The user hits your cloud service (C), gets redirected to your DMZ auth server (A), which negotiates authentication, and redirects the client back to C with a code. C makes a request to A to confirm that the code is valid and gives its own auth to the client.

In a proper SOA, I would build an app in the DMZ that abstracts away the cloud service instead of "proxying" raw requests. Kinda like if you want to upload a file to S3, you upload it to your web server, which then turns around and writes it to S3. 

--

You received this message because you are subscribed to the Google Groups "waffle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to waffle-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[cirruslogic]

The route you suggested seems to make a lot of sense but we have to be careful not to pass the wrong code or route to the wrong user.

A vendor is building a Struts application (A) in Amazon. We want the internal network users (B) to be able to use the application (A) without having to log in. Our users use IE so the browser will authenticate with the AD inside the domain controller (C) if the application is in the Intranet. But this new application (A) is hosted in the cloud. Our security group tells us (and rightfully so) that the application (A) should never connect with the DC directly. Some application (D) needs to be housed in the DMZ to serve as a "AD replicator" or intermediary or proxy and do the authentication.

[Daniel Doubrovkine]

Personally, I would go the OAuth route rather than proxy in the DMZ. It's much cleaner and also "standard" on the internet. You authenticate to thousands of sites with Twitter or Facebook, this would be the same thing except your service is the OAuth provider.

On Sat, Apr 6, 2013 at 4:14 AM, cirruslogic <anthony...@gmail.com> wrote:

The route you suggested seems to make a lot of sense but we have to be careful not to pass the wrong code or route to the wrong user.

A vendor is building a Struts application (A) in Amazon. We want the internal network users (B) to be able to use the application (A) without having to log in. Our users use IE so the browser will authenticate with the AD inside the domain controller (C) if the application is in the Intranet. But this new application (A) is hosted in the cloud. Our security group tells us (and rightfully so) that the application (A) should never connect with the DC directly. Some application (D) needs to be housed in the DMZ to serve as a "AD replicator" or intermediary or proxy and do the authentication.

--
You received this message because you are subscribed to the Google Groups "waffle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to waffle-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.