Re: Windows Authentication: Issue 49318 vs 47679
On Mon, Mar 28, 2011 at 7:26 AM, Stefan Mayr ste...@mayr-stefan.de wrote: Hello everybody, as many others before we wanted to do single-sign-on for intranet web applications using integrated windows authentication (negotiate because IE sometimes tries NTLM instead of using plain kerberos - breaking all our kerberos-only experiments). We thought that IIS would be the best choice for integrated windows authentication and we could pass the user via AJP (using mod_jk) to our tomcat instances. Our setup: - Windows 2008 R2 using IIS 7.5 (64bit) - mod_jk 1.2.31 - Oracle Java 1.6 U24 - Tomcat 6.0.32 At first glance using tomcatAuthentication=false worked as expected. We got the remote user and started deploying an application. End of happiness - the application complained about a missing user-agent. That header was not passed to tomcat when authentication was enabled on IIS. Some research revealed Bug 47679 - Not all headers get passed to Tomcat server from isapi_redirect.dll (https://issues.apache.org/bugzilla/show_bug.cgi?id=47679) Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator / integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318). The last comment links a new Windows Authentication How-To from Mark Thomas. Looks like we have already tried almost all proposed solutions: - IIS + mod_jk: tried but stuck in Bug 47679. Also tried ARR to pass the user name as a request header from IIS to Tomcat without success - Apache mod_ntlm: used it and we replaced it by the much more stable mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default) - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit plattform - we couldn't get stability problems solved on Apache 2.2 and 64bit Linux. No ongoing development. - Apache mod_auth_sspi: till now in internal use for a very small project (works just fine), not sure about the future. Although there seems to be some new activity on 1.0.5 beta - Waffle: found it on thursday and it is on my our todo-list for testing it next week Any chances to get Bug 47679 solved? How can we help (we are admins, no devs)? What solutions have you deployed? Recommendations? I've committed a fix for Bug 47679, which I hope will resolve the issues people have been having using the ISAPI redirector in an extension only mode. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
Stefan Mayr wrote: Native SPNEGO in Tomcat sounds great. Waiting a little while depends on your scale of little. Is there already some development we can follow? Will this use Java GSS? I never figured out how to configure this with Tomcat. If you are in a hurry, you may want to have a look at Jespa : www.ioplex.com. Have it installed at numerous customers sites and works great. About the sequence of rewrite/forward with IIS, have a look at isapi_rewrite : http://www.helicontech.com/isapi_rewrite/doc/ It can pick up the user's Windows domain user-id, and pass it on as a HTTP header. You would then need a simple servlet filter at the Tomcat level, to pick up the content of this header and use it as the authenticated Tomcat user-id. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On 28/03/2011 22:31, Stefan Mayr wrote: Native SPNEGO in Tomcat sounds great. Waiting a little while depends on your scale of little. Is there already some development we can follow? Will this use Java GSS? I never figured out how to configure this with Tomcat. little hopefully means the next week or so in a 7.0.12 release. I have a handful of things I need/want to get into 7.0.12 and SPNEGO is one of them. Having spent more time than I want to think about and having lost count of the number of times I re-installed Windows 2k8 server to test this, I finally got this working a few minutes ago. The current code is *very* rough and ready and it only does authentication, not authorisation so I still have some work to do. The solution is based on ideas from Spring Security's Kerberos extension and the most recent patches attached to bug 48685. I'll be committing an initial implementation once I have cleaned up the code a bit and then I'll build on that to add authorisation, more configuration etc. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On 29/03/2011 15:20, Mark Thomas wrote: On 28/03/2011 22:31, Stefan Mayr wrote: Native SPNEGO in Tomcat sounds great. Waiting a little while depends on your scale of little. Is there already some development we can follow? Will this use Java GSS? I never figured out how to configure this with Tomcat. little hopefully means the next week or so in a 7.0.12 release. I have a handful of things I need/want to get into 7.0.12 and SPNEGO is one of them. Having spent more time than I want to think about and having lost count of the number of times I re-installed Windows 2k8 server to test this, I finally got this working a few minutes ago. The current code is *very* rough and ready and it only does authentication, not authorisation so I still have some work to do. The solution is based on ideas from Spring Security's Kerberos extension and the most recent patches attached to bug 48685. I'll be committing an initial implementation once I have cleaned up the code a bit and then I'll build on that to add authorisation, more configuration etc. The first part just got committed [1]. More to follow over the next day or so. Mark [1] http://svn.apache.org/viewvc?rev=1086683view=rev - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
Would adding support for client credential delegation be out of scope
for this implementation or not?
Client credential delegation is when you use the spnego token
construct a javax.security.auth.Subject instance that represents the
client - which the server side application can use this to impersonate
the client (eg. connect to some Kerberized database as the client that
sent the request, or consume some other kerberized service as the
client).
The code for creating such a Subject would be something like this:
GSSContext context =
GSSManager.getInstance().createContext((GSSCredential) null);
context.acceptSecContext(...);
//check if the credentials can be delegated
if (!context.getCredDelegState()) {
//get the delegated credentials from the calling peer...
GSSCredential clientCred = context.getDelegCred();
//Create a Subject out of the delegated credentials.
//With this Subject the application server can impersonate the
client that sent the request.
Subject clientSubject =
com.sun.security.jgss.GSSUtil.createSubject(context.getSrcName(),
clientCred);
}
//Store the clientSubject somewhere - maybe to the HttpServletRequest?
I am sure this would be useful for some applications - for example the
one that we are currently developing needs functionality like this.
On Tue, Mar 29, 2011 at 9:09 PM, Mark Thomas ma...@apache.org wrote:
On 29/03/2011 15:20, Mark Thomas wrote:
On 28/03/2011 22:31, Stefan Mayr wrote:
Native SPNEGO in Tomcat sounds great. Waiting a little while depends on
your scale of little. Is there already some development we can follow?
Will this use Java GSS? I never figured out how to configure this with
Tomcat.
little hopefully means the next week or so in a 7.0.12 release. I have
a handful of things I need/want to get into 7.0.12 and SPNEGO is one of
them.
Having spent more time than I want to think about and having lost count
of the number of times I re-installed Windows 2k8 server to test this, I
finally got this working a few minutes ago. The current code is *very*
rough and ready and it only does authentication, not authorisation so I
still have some work to do.
The solution is based on ideas from Spring Security's Kerberos extension
and the most recent patches attached to bug 48685.
I'll be committing an initial implementation once I have cleaned up the
code a bit and then I'll build on that to add authorisation, more
configuration etc.
The first part just got committed [1]. More to follow over the next day
or so.
Mark
[1] http://svn.apache.org/viewvc?rev=1086683view=rev
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Why?
Because YES!
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
Whoops, i reversed the condition of the if statement, it should be:
//check if the credentials can be delegated
if (context.getCredDelegState()) {
...
}
On Tue, Mar 29, 2011 at 9:47 PM, Borut Hadžialić
borut.hadzia...@gmail.com wrote:
Would adding support for client credential delegation be out of scope
for this implementation or not?
Client credential delegation is when you use the spnego token
construct a javax.security.auth.Subject instance that represents the
client - which the server side application can use this to impersonate
the client (eg. connect to some Kerberized database as the client that
sent the request, or consume some other kerberized service as the
client).
The code for creating such a Subject would be something like this:
GSSContext context =
GSSManager.getInstance().createContext((GSSCredential) null);
context.acceptSecContext(...);
//check if the credentials can be delegated
if (!context.getCredDelegState()) {
//get the delegated credentials from the calling peer...
GSSCredential clientCred = context.getDelegCred();
//Create a Subject out of the delegated credentials.
//With this Subject the application server can impersonate the
client that sent the request.
Subject clientSubject =
com.sun.security.jgss.GSSUtil.createSubject(context.getSrcName(),
clientCred);
}
//Store the clientSubject somewhere - maybe to the HttpServletRequest?
I am sure this would be useful for some applications - for example the
one that we are currently developing needs functionality like this.
On Tue, Mar 29, 2011 at 9:09 PM, Mark Thomas ma...@apache.org wrote:
On 29/03/2011 15:20, Mark Thomas wrote:
On 28/03/2011 22:31, Stefan Mayr wrote:
Native SPNEGO in Tomcat sounds great. Waiting a little while depends on
your scale of little. Is there already some development we can follow?
Will this use Java GSS? I never figured out how to configure this with
Tomcat.
little hopefully means the next week or so in a 7.0.12 release. I have
a handful of things I need/want to get into 7.0.12 and SPNEGO is one of
them.
Having spent more time than I want to think about and having lost count
of the number of times I re-installed Windows 2k8 server to test this, I
finally got this working a few minutes ago. The current code is *very*
rough and ready and it only does authentication, not authorisation so I
still have some work to do.
The solution is based on ideas from Spring Security's Kerberos extension
and the most recent patches attached to bug 48685.
I'll be committing an initial implementation once I have cleaned up the
code a bit and then I'll build on that to add authorisation, more
configuration etc.
The first part just got committed [1]. More to follow over the next day
or so.
Mark
[1] http://svn.apache.org/viewvc?rev=1086683view=rev
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Why?
Because YES!
--
Why?
Because YES!
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On 29/03/2011 20:47, Borut Hadžialić wrote: Would adding support for client credential delegation be out of scope for this implementation or not? It is in scope with the caveat - as always - that it depends on what the final implementation looks like. I do know (from debug logging) that right now tokens do not allow delegation. I suspect the hardest part of implementing this will be figuring out what config needs tweaking to allow that. //Store the clientSubject somewhere - maybe to the HttpServletRequest? That needs a little more thought. I am leaning towards a request attribute at the moment unless I can find a way to get it into the result of getUserPrincipal() (which I don't think I can without requiring a cast to a Tomcat internal class which is just horrible). I am sure this would be useful for some applications - for example the one that we are currently developing needs functionality like this. Testing help always appreciated if you are happy running the latest 7.0.x release (this should be in 7.0.12 which I plan to start releasing just as soon as I finish everything on my todo list). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On Tue, Mar 29, 2011 at 9:57 PM, Mark Thomas ma...@apache.org wrote: It is in scope with the caveat - as always - that it depends on what the final implementation looks like. I do know (from debug logging) that right now tokens do not allow delegation. I suspect the hardest part of implementing this will be figuring out what config needs tweaking to allow that. I think that credential delegation is configured at the domain controller and client side, as this nice article describes: http://spnego.sourceforge.net/credential_delegation.html I am sure this would be useful for some applications - for example the one that we are currently developing needs functionality like this. Testing help always appreciated if you are happy running the latest 7.0.x release (this should be in 7.0.12 which I plan to start releasing just as soon as I finish everything on my todo list). We already have some hand written custom code for this. We will not be switching to 7.0.x (we will be deploying to tcServer in producion, and it will probably take lots of time for 7.0.12 changes to appear in some version of tcServer, so we need the custom code we have at the moment). I might however try to deploy our app to 7.0.12 when it is out - and see how much of our custom code will get removed by this spnego support that you are writing now. -- Why? Because YES! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On 29/03/2011 21:18, Borut Hadžialić wrote: On Tue, Mar 29, 2011 at 9:57 PM, Mark Thomas ma...@apache.org wrote: It is in scope with the caveat - as always - that it depends on what the final implementation looks like. I do know (from debug logging) that right now tokens do not allow delegation. I suspect the hardest part of implementing this will be figuring out what config needs tweaking to allow that. I think that credential delegation is configured at the domain controller and client side, as this nice article describes: http://spnego.sourceforge.net/credential_delegation.html Thanks. That is one of the many articles I have read over the last few days but I had forgotten which ones mentioned what. I'll take a look. I am sure this would be useful for some applications - for example the one that we are currently developing needs functionality like this. Testing help always appreciated if you are happy running the latest 7.0.x release (this should be in 7.0.12 which I plan to start releasing just as soon as I finish everything on my todo list). We already have some hand written custom code for this. We will not be switching to 7.0.x (we will be deploying to tcServer in producion, and it will probably take lots of time for 7.0.12 changes to appear in some version of tcServer, so we need the custom code we have at the moment). Fair enough. off-topic With my VMware hat on that is is probably going to be sooner than you think it is but I can't give you any firm dates. /off-topic I might however try to deploy our app to 7.0.12 when it is out - and see how much of our custom code will get removed by this spnego support that you are writing now. That would be great. Any testing and feedback is always helpful. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
Hellos Stefan, if you can't fix your problem with configuration and decide that you want to solve the problem by programming, then this might help you http://blog.springsource.com/2009/09/28/spring-security-kerberos/ After understanding that article a developer should be able to add a SPNEGO implementation (probably not the whole protocol, just as much it is needed for your app) to your Tomcat application by adding some filters. What the implementation needs to do is basically: 1. If there is a 'Negotiate ..' http header or other authentication, read it and process it. 2. Otherwise if there is no authentication, send a spnego challenge //HttpServletResponse response response.addHeader(WWW-Authenticate, Negotiate); response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); response.flushBuffer(); On Sun, Mar 27, 2011 at 8:26 PM, Stefan Mayr ste...@mayr-stefan.de wrote: Hello everybody, as many others before we wanted to do single-sign-on for intranet web applications using integrated windows authentication (negotiate because IE sometimes tries NTLM instead of using plain kerberos - breaking all our kerberos-only experiments). We thought that IIS would be the best choice for integrated windows authentication and we could pass the user via AJP (using mod_jk) to our tomcat instances. Our setup: - Windows 2008 R2 using IIS 7.5 (64bit) - mod_jk 1.2.31 - Oracle Java 1.6 U24 - Tomcat 6.0.32 At first glance using tomcatAuthentication=false worked as expected. We got the remote user and started deploying an application. End of happiness - the application complained about a missing user-agent. That header was not passed to tomcat when authentication was enabled on IIS. Some research revealed Bug 47679 - Not all headers get passed to Tomcat server from isapi_redirect.dll (https://issues.apache.org/bugzilla/show_bug.cgi?id=47679) Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator / integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318). The last comment links a new Windows Authentication How-To from Mark Thomas. Looks like we have already tried almost all proposed solutions: - IIS + mod_jk: tried but stuck in Bug 47679. Also tried ARR to pass the user name as a request header from IIS to Tomcat without success - Apache mod_ntlm: used it and we replaced it by the much more stable mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default) - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit plattform - we couldn't get stability problems solved on Apache 2.2 and 64bit Linux. No ongoing development. - Apache mod_auth_sspi: till now in internal use for a very small project (works just fine), not sure about the future. Although there seems to be some new activity on 1.0.5 beta - Waffle: found it on thursday and it is on my our todo-list for testing it next week Any chances to get Bug 47679 solved? How can we help (we are admins, no devs)? What solutions have you deployed? Recommendations? Thank you, Stefan Mayr - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Why? Because YES! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On 28/03/2011 08:42, Borut Hadžialić wrote: Hellos Stefan, if you can't fix your problem with configuration and decide that you want to solve the problem by programming, then this might help you http://blog.springsource.com/2009/09/28/spring-security-kerberos/ After understanding that article a developer should be able to add a SPNEGO implementation (probably not the whole protocol, just as much it is needed for your app) to your Tomcat application by adding some filters. Or you could just add Spring Security to your app. I'll add that as an option to the new How-To. Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator / integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318). The last comment links a new Windows Authentication How-To from Mark Thomas. Looks like we have already tried almost all proposed solutions: Thanks for the great feedback on the options. I put the existing how-to together pretty much entirely on some Google searches. I'll add your feedback to the how-to / maybe remove some options that don't look viable. - IIS + mod_jk: tried but stuck in Bug 47679. Also tried ARR to pass the user name as a request header from IIS to Tomcat without success - Apache mod_ntlm: used it and we replaced it by the much more stable mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default) - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit plattform - we couldn't get stability problems solved on Apache 2.2 and 64bit Linux. No ongoing development. - Apache mod_auth_sspi: till now in internal use for a very small project (works just fine), not sure about the future. Although there seems to be some new activity on 1.0.5 beta - Waffle: found it on thursday and it is on my our todo-list for testing it next week Any chances to get Bug 47679 solved? How can we help (we are admins, no devs)? What solutions have you deployed? Recommendations? It is tricky to recommend something right now. I'm guessing you want something that a) works reliably and b) is likely to be supported for the long term. Right now Waffle probably comes closest to that. It you can wait a little while, I should have SPNEGO support in Tomcat 7 fairly soon. It may - or may not - get back-ported to Tomcat 6. It will depend on the eventual solution. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Windows Authentication: Issue 49318 vs 47679
I should have SPNEGO support in Tomcat 7 fairly soon. This would be great! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
Hi Mark, Am 28.03.2011 10:49, schrieb Mark Thomas: On 28/03/2011 08:42, Borut Hadžialić wrote: Hellos Stefan, if you can't fix your problem with configuration and decide that you want to solve the problem by programming, then this might help you http://blog.springsource.com/2009/09/28/spring-security-kerberos/ After understanding that article a developer should be able to add a SPNEGO implementation (probably not the whole protocol, just as much it is needed for your app) to your Tomcat application by adding some filters. Or you could just add Spring Security to your app. I'll add that as an option to the new How-To. I guess this is the classic kerberos/keytab approach (no NTLM-fallback) that many solutions offer. Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator / integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318). The last comment links a new Windows Authentication How-To from Mark Thomas. Looks like we have already tried almost all proposed solutions: Thanks for the great feedback on the options. I put the existing how-to together pretty much entirely on some Google searches. I'll add your feedback to the how-to / maybe remove some options that don't look viable. - IIS + mod_jk: tried but stuck in Bug 47679. Also tried ARR to pass the user name as a request header from IIS to Tomcat without success - Apache mod_ntlm: used it and we replaced it by the much more stable mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default) - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit plattform - we couldn't get stability problems solved on Apache 2.2 and 64bit Linux. No ongoing development. - Apache mod_auth_sspi: till now in internal use for a very small project (works just fine), not sure about the future. Although there seems to be some new activity on 1.0.5 beta - Waffle: found it on thursday and it is on my our todo-list for testing it next week Any chances to get Bug 47679 solved? How can we help (we are admins, no devs)? What solutions have you deployed? Recommendations? It is tricky to recommend something right now. I'm guessing you want something that a) works reliably and b) is likely to be supported for the long term. Right now Waffle probably comes closest to that. It you can wait a little while, I should have SPNEGO support in Tomcat 7 fairly soon. It may - or may not - get back-ported to Tomcat 6. It will depend on the eventual solution. You're definitely right. We search for the holy grail of intranet authentication. a+b is a must. The idea of using IIS with ARR in reverse proxy mode passing a username was dead end: Microsoft pointed us to a nice article describing HTTP request processing order. Rewriting a request comes before the authentication modul - so nothing to append to a header or request in the first place. See http://learn.iis.net/page.aspx/501/iis-70-request-filtering-and-url-rewriting/ Leaves IIS with mod_jk if you can live with Bug 47679. Our first test with Waffle is promising. Now it needs to be integrated and in our application for further testing. Native SPNEGO in Tomcat sounds great. Waiting a little while depends on your scale of little. Is there already some development we can follow? Will this use Java GSS? I never figured out how to configure this with Tomcat. Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
