windows single sign on tomcat through IIS Url rewrite

963 views
Skip to first unread message

Jelle Victoor

unread,
Dec 11, 2014, 7:55:44 AM12/11/14
to waffle...@googlegroups.com

I'm facing a difficult setup where I have to configure single sign on, based on the logged in used on my tomcat application. I already took some steps which allow me to login via single sign on directly on my tomcat application by using waffle.

I have 1 server where I have a tomcat running and a IIS running (but this IIS will move to another server in the same domain in the future). I have the Tomcat running on port 8205 and the IIS configure to accept url's from authpoc.company.com. IIS does a redirect to localhost:8025 via URL Rewrite. My web.xml from IIS

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule1">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://localhost:8205/{R:1}" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

What works

  • When opening the application directly on localhost:8205 on the server. I get a nice single sign on based on my domain user.
  • When opening the application directly on the ip of the server. 192.168.1.1:8205.

What doesn't work

  • When redirecting from IIS, I don't get to login into my tomcat application. I have windows authentication enabled, with Negotiate and NTML enabled (in this sequence).

I read a lot on the internet but I can't find anyone with this particular setup. I don't really have the impression I'm doing something exotic. One possiblity is that I should connect IIS via AJP instead of a much simpeler URL rewrite.

any help is welcome! Thanks

Daniel Doubrovkine

unread,
Dec 11, 2014, 8:23:14 AM12/11/14
to waffle...@googlegroups.com
When you hit a proxy, you're doing a "hop" and the client knows that it's not talking to the real thing, so SSO can't work without explicit proxy support. I don't think IIS knows how to do that.

--
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/d/optout.



--

Daniel Doubrovkine

unread,
Dec 11, 2014, 8:23:54 AM12/11/14
to waffle...@googlegroups.com
The Microsoft proxy (ISA) is a thing that does, but that's a can of worms. I would try to figure something else out that makes your Tomcat server exposed to the client directly.

Jelle Victoor

unread,
Dec 11, 2014, 8:32:37 AM12/11/14
to waffle...@googlegroups.com
ok, thanks for your awnser.
I do need to go through IIS to enable Single sign on. Is there a way to keep looking. Else I would need to disable waffle and use the windows auth headers I get from IIS

Op donderdag 11 december 2014 13:55:44 UTC+1 schreef Jelle Victoor:

Daniel Doubrovkine

unread,
Dec 11, 2014, 10:08:09 AM12/11/14
to waffle...@googlegroups.com
If you are doing SSO with IIS, and proxying requests, you might as well pass the user information forward. You'll have to develop something secure, for example by adding a signed header on the IIS server with the user information.

--
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/d/optout.

Jelle Victoor

unread,
Dec 11, 2014, 10:49:19 AM12/11/14
to waffle...@googlegroups.com
Yeah, i was also thinking something in that direction.

Then I would enable windows authentication on my IIS server, allow this to propagate (username) through to my tomcat server via headers. Then I would have to lookup my user in the AD and get the groups.

that leaves me with 2 questions. 
- Can I add my user from my windows authentication on IIS to my headers of my rewrite? (I know this is the wrong place to ask this :))
- This means a user can connect directly to the tomcat with the header filled in and act as another user (this isn't really a problem since it is intranet, but still)


Op donderdag 11 december 2014 16:08:09 UTC+1 schreef Daniel Doubrovkine:

Daniel Doubrovkine

unread,
Dec 11, 2014, 11:47:11 AM12/11/14
to waffle...@googlegroups.com
1) I think you should not do AD lookups on the tomcat instance, I would do it in IIS as well. I am not familiar with writing IIS filters, but this i definitely possible. The code is pretty much identical to what waffle does in terms of finding current user's groups from a logon. In fact, if you can write a .NET version these days Waffle's .NET code should get you pretty far - getting current logged on user's security groups is a bit of work, see http://code.dblock.org/jna-win32-platform-api-implementation for a complete implementation.

2) Don't just pass it in the header, establish some security, intranet or not. I suggest sharing a secret and encrypting the data or at least signing it. 


Jelle Victoor

unread,
Dec 11, 2014, 1:20:20 PM12/11/14
to waffle...@googlegroups.com
Would configuring IIS via de ajp protocol instead of via url rewrite cause this to be only one hop?

Op donderdag 11 december 2014 17:47:11 UTC+1 schreef Daniel Doubrovkine:

Jelle Victoor

unread,
Dec 11, 2014, 2:00:01 PM12/11/14
to waffle...@googlegroups.com
I'm still wondering if there is something specific about my setup. Is this something that is exotic? In a real production environment, there is always a sort of web server dispatching the requests to the several applications. When you look on the market there are only 2 popular servers, apache and IIS


Op donderdag 11 december 2014 19:20:20 UTC+1 schreef Jelle Victoor:

Daniel Doubrovkine

unread,
Dec 11, 2014, 3:36:21 PM12/11/14
to waffle...@googlegroups.com
It's not exotic and it can work. You would need to impersonate on the IIS server and then it's a new game making requests to the other server. There's also proxy auth. 

With all MSFT stack this is not rocket science, but once you start mixing things it gets a bit harder ... 

Jelle Victoor

unread,
Dec 12, 2014, 1:44:07 AM12/12/14
to waffle...@googlegroups.com
Could you be more specific in your explanation? A lot of these things are new to me, causing me not to understand fully what you mean.

impersonate on the IIS, what does this mean?
proxy auth, is this a feature of Waffle?


Op donderdag 11 december 2014 21:36:21 UTC+1 schreef Daniel Doubrovkine:

Jelle Victoor

unread,
Dec 12, 2014, 7:54:43 AM12/12/14
to waffle...@googlegroups.com
I had a look at what you proposed Daniel and i found out that there is actually a difference between the ajp connection and the url rewrite.
When I run the waffle filter I now get my username via IIS windows authentication. The default page of the waffle-filter example doesn't show my groups anymore, but my user and impersonation account is coming through

Op vrijdag 12 december 2014 07:44:07 UTC+1 schreef Jelle Victoor:

Daniel Doubrovkine

unread,
Dec 12, 2014, 9:47:02 AM12/12/14
to waffle...@googlegroups.com
So you enabled impersonation in IIS and made no other changes, right?

Make sure your services (IIS and Tomcat) *aren't* running as that user and that effectively what you get is the client account. I am surprised the groups aren't coming through - I'd be curious to see a Tomcat debug level log that shows waffle logging in the user, etc.

Do note that this client -> IIS -> Tomcat scenario only works if the account in question has delegation enabled. This is something that is configured with the domain policies by the domain administrator and it's not uncommon to be disabled. If you're building a generic solution for clients it might not always work. If you control your environment, you should be OK. 

Jelle Victoor

unread,
Dec 16, 2014, 3:20:09 AM12/16/14
to waffle...@googlegroups.com
Daniel
Thanks for the update. some pointers.
1. Customer for a client, I have full control, should not be a problem to do this.
2. The services aren't running with that user, its is really request.getRemoteUser() that returns my user.
3. impersonation is not on.


Op vrijdag 12 december 2014 15:47:02 UTC+1 schreef Daniel Doubrovkine:
Reply all
Reply to author
Forward
0 new messages