Re: SSO SPNEGO GSS API CheckSum Failed Error
Please don't respond to this email. I was able to figure out the issue. The server hosting devexample.domain.com was using a canonicalized hostname. This was throwing tomcat off when reading over the token and keytab file. I only wish there was a better way for this error to pick up on that. On Fri, Feb 23, 2024 at 11:36 AM Thomas Delaney wrote: > > > Hi all, > > I have a redhat 9.2 server hosting a web application on 5 seperate > instances of Apache Tomcat. I have configured SPNEGO on instances 1,2,3 and > 4. These instances are behind an apache proxy load balancer on version > 2.4.57. Instance 1,2, and 3 are load balanced. While 4 and 5 are not. The > application is hosted on Tomcat 9.0.54. > > Domain: domain.com > Site: devexample.domain.com > > URL hit: https://devexample.domain.com/webclient_devex/exclient.jsp > > *I keep getting this when accessing the application on instance 5:* > HTTP Status 500 – Internal Server Error > Type Exception Report > > Message GSSException: Failure unspecified at GSS-API level (Mechanism > level: Checksum failed) > Description The server encountered an unexpected condition that prevented > it from fulfilling the request. > Exception > javax.servlet.ServletException: GSSException: Failure unspecified at > GSS-API level (Mechanism level: Checksum failed) > net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:287) > Root Cause > GSSException: Failure unspecified at GSS-API level (Mechanism level: > Checksum failed) > sun.security.jgss.krb5.Krb5Context.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(Unknown Source) > sun.security.jgss.spnego.SpNegoContext.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > > net.sourceforge.spnego.SpnegoAuthenticator.doSpnegoAuth(SpnegoAuthenticator.java:487) > > net.sourceforge.spnego.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:327) > net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:283) > Root Cause > KrbException: Checksum failed > sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Unknown > Source) > sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Unknown > Source) > sun.security.krb5.EncryptedData.decrypt(Unknown Source) > sun.security.krb5.KrbApReq.authenticate(Unknown Source) > sun.security.krb5.KrbApReq.(Unknown Source) > sun.security.jgss.krb5.InitSecContextToken.(Unknown Source) > sun.security.jgss.krb5.Krb5Context.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(Unknown Source) > sun.security.jgss.spnego.SpNegoContext.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > > net.sourceforge.spnego.SpnegoAuthenticator.doSpnegoAuth(SpnegoAuthenticator.java:487) > > net.sourceforge.spnego.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:327) > net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:283) > Root Cause > java.security.GeneralSecurityException: Checksum failed > sun.security.krb5.internal.crypto.dk.AesDkCrypto.decryptCTS(Unknown Source) > sun.security.krb5.internal.crypto.dk.AesDkCrypto.decrypt(Unknown Source) > sun.security.krb5.internal.crypto.Aes256.decrypt(Unknown Source) > sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Unknown > Source) > sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Unknown > Source) > sun.security.krb5.EncryptedData.decrypt(Unknown Source) > sun.security.krb5.KrbApReq.authenticate(Unknown Source) > sun.security.krb5.KrbApReq.(Unknown Source) > sun.security.jgss.krb5.InitSecContextToken.(Unknown Source) > sun.security.jgss.krb5.Krb5Context.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(Unknown Source) > sun.security.jgss.spnego.SpNegoContext.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) > > net.sourceforge.spnego.SpnegoAuthenticator.doSpnegoAuth(SpnegoAuthenticator.java:487) > > net.sourceforge.spnego.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:327) > net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:283) > > > In the catalina logs: > Entered SpNegoContext.acceptSecContext with state=STATE_NEW > SpNegoContext.acceptSecContext: re
Re: SSO Token not found with RewriteRules
On 1/17/2023 12:30 PM, Jerry Malcolm wrote: On 1/17/2023 3:43 AM, Mark Thomas wrote: On 16/01/2023 23:07, Jerry Malcolm wrote: Well, after downloading and installing the Tomcat source in my Eclipse environment and tracking through a bunch of breakpoints, I figured out what was happening. SingleSignOn.invoke() was querying for the list of cookies in the request (that were indeed present in the request), but was returning null. Since no cookies were 'found' there was no JSESSIONIDSSO cookie found, and everything failed from that point on. So I started tracking why the cookies that were present were being ignored. convertCookies was called, which did a getContext() which returned null, so everything aborted. getContext() failed apparently because I did not have a ROOT webapp (context) defined. I added a dummy ROOT webapp, and voila So the bottom line to the entire problem is that RewriteRules with SSO is not permitted UNLESS there is a dummy ROOT webapp defined. I'm not sure why this would be a requirement, and I was not able to find any documentation about it. I understand why SSO might require contexts. But the primary purpose of RewriteRules is to hide the plumbing on the URL line. If the requirement for context present is required for SSO, then it would seem to me that the context should be checked on the target of the rewrite, not the original string being rewritten, since it most likely will not have a valid context. And a dummy unused ROOT webapp just takes up resources. The reason it worked in the other virtual host is that I actually did have a need in that host for a ROOT context. This one was painful. Just out of curiosity, is this restriction intended? If so, error messages and/or documentation of it might need a review. No. The restriction isn't intended. See this discussion around a similar issue: https://github.com/apache/tomcat/pull/479 Generally, not having a ROOT context is sufficiently unusual that it is rare for users to fund bugs like this. A similar approach should fix this - assume the default CookieProcessor if no context is found. Mark Thanks for the reply, Mark. In my philosophy for years (possibly not the best philosophy...), the root was for primarily static stuff. And any JSPs that might need to be in root were sent to other non-root contexts via a rewrite. I've been moving away from that philosophy in recent projects and including a ROOT context. But this current situation is migrating a legacy domain off of httpd/tomcat to pure tomcat. So it bit me. No big deal now that I've figured it out. The cookie processing was inside the Tomcat request object. So I assume that statement about using the default CookieProcessor was meant for TC development. Or is there a way I can control which cookie processor is used? Thanks again... on to the next hill to climb. Jerry Mark, You know a day or two earlier it crossed my mind that order of the valves might be significant. I was convinced that if I found out 'working host A' and 'non-working host B' had the valves declared in different orders then obviously problem solved... But then I saw that they both had SSO above rewrite, and since they were identical and one worked, one didn't, that couldn't be the problem. But now that you mentioned it, I'm wondering if the order could be significant, and having the ROOT domain defined simply masked the ordering differences. If I get some time to play, I'll re-order them and pull the ROOT context temporarily and see what happens. Thanks. Jerry On 1/16/2023 12:40 AM, Jerry Malcolm wrote: I have one virtual host working fine on a Windows 11 TC 9 install. I am adding a 2nd virtual host to that same running installation. This TC is standalone, handling http requests directly (not via httpd). Both virtual hosts have a rewrite.config. On the new domain, I go to a page that requires a login, do the standard login, and it show the page. I can F5 refresh the page and it continues to appear. But if I enter a url that redirects to this same page, I get the signin screen. If I try to sign in again, I get an error "The requested resource [/idmanager/j_security_check] is not available" I enabled redirect logs, and they show SSO token not found. I know the redirect is working fine for the new virtual host since there's no problems going to unprotected (no sign-in) redirected pages. This exact scenario works perfectly fine (with rewrite rules) on the other virtual host in the same TC. I've compared the two host configurations in server.xml and they appear identical other than than the name and path. i.e. SingleSignOn valve is specified on both. The fact that SSO only fails on redirects and not on URLs without redirects, plus the fact that it works fine on one virtual host and not on the other is baffling me. All indications point to some sort of config error or typo on the som
Re: SSO Token not found with RewriteRules
On 1/17/2023 3:43 AM, Mark Thomas wrote: On 16/01/2023 23:07, Jerry Malcolm wrote: Well, after downloading and installing the Tomcat source in my Eclipse environment and tracking through a bunch of breakpoints, I figured out what was happening. SingleSignOn.invoke() was querying for the list of cookies in the request (that were indeed present in the request), but was returning null. Since no cookies were 'found' there was no JSESSIONIDSSO cookie found, and everything failed from that point on. So I started tracking why the cookies that were present were being ignored. convertCookies was called, which did a getContext() which returned null, so everything aborted. getContext() failed apparently because I did not have a ROOT webapp (context) defined. I added a dummy ROOT webapp, and voila So the bottom line to the entire problem is that RewriteRules with SSO is not permitted UNLESS there is a dummy ROOT webapp defined. I'm not sure why this would be a requirement, and I was not able to find any documentation about it. I understand why SSO might require contexts. But the primary purpose of RewriteRules is to hide the plumbing on the URL line. If the requirement for context present is required for SSO, then it would seem to me that the context should be checked on the target of the rewrite, not the original string being rewritten, since it most likely will not have a valid context. And a dummy unused ROOT webapp just takes up resources. The reason it worked in the other virtual host is that I actually did have a need in that host for a ROOT context. This one was painful. Just out of curiosity, is this restriction intended? If so, error messages and/or documentation of it might need a review. No. The restriction isn't intended. See this discussion around a similar issue: https://github.com/apache/tomcat/pull/479 Generally, not having a ROOT context is sufficiently unusual that it is rare for users to fund bugs like this. A similar approach should fix this - assume the default CookieProcessor if no context is found. Mark Thanks for the reply, Mark. In my philosophy for years (possibly not the best philosophy...), the root was for primarily static stuff. And any JSPs that might need to be in root were sent to other non-root contexts via a rewrite. I've been moving away from that philosophy in recent projects and including a ROOT context. But this current situation is migrating a legacy domain off of httpd/tomcat to pure tomcat. So it bit me. No big deal now that I've figured it out. The cookie processing was inside the Tomcat request object. So I assume that statement about using the default CookieProcessor was meant for TC development. Or is there a way I can control which cookie processor is used? Thanks again... on to the next hill to climb. Jerry Thanks. Jerry On 1/16/2023 12:40 AM, Jerry Malcolm wrote: I have one virtual host working fine on a Windows 11 TC 9 install. I am adding a 2nd virtual host to that same running installation. This TC is standalone, handling http requests directly (not via httpd). Both virtual hosts have a rewrite.config. On the new domain, I go to a page that requires a login, do the standard login, and it show the page. I can F5 refresh the page and it continues to appear. But if I enter a url that redirects to this same page, I get the signin screen. If I try to sign in again, I get an error "The requested resource [/idmanager/j_security_check] is not available" I enabled redirect logs, and they show SSO token not found. I know the redirect is working fine for the new virtual host since there's no problems going to unprotected (no sign-in) redirected pages. This exact scenario works perfectly fine (with rewrite rules) on the other virtual host in the same TC. I've compared the two host configurations in server.xml and they appear identical other than than the name and path. i.e. SingleSignOn valve is specified on both. The fact that SSO only fails on redirects and not on URLs without redirects, plus the fact that it works fine on one virtual host and not on the other is baffling me. All indications point to some sort of config error or typo on the something in the new virtual host. But I have spent more hours that I want to admit on this, and I simply can't figure out anything that would cause this. I'm sure I made some config change somewhere a long time ago on the first virtual host that's making it work correctly. But I can't find anything, and I'm at a total loss. What could be causing rewrite rules to not find SSO cookies? Where did I mess up? Thanks Jerry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail:
Re: SSO Token not found with RewriteRules
On 17/01/2023 09:43, Mark Thomas wrote: On 16/01/2023 23:07, Jerry Malcolm wrote: Well, after downloading and installing the Tomcat source in my Eclipse environment and tracking through a bunch of breakpoints, I figured out what was happening. SingleSignOn.invoke() was querying for the list of cookies in the request (that were indeed present in the request), but was returning null. Since no cookies were 'found' there was no JSESSIONIDSSO cookie found, and everything failed from that point on. So I started tracking why the cookies that were present were being ignored. convertCookies was called, which did a getContext() which returned null, so everything aborted. getContext() failed apparently because I did not have a ROOT webapp (context) defined. I added a dummy ROOT webapp, and voila So the bottom line to the entire problem is that RewriteRules with SSO is not permitted UNLESS there is a dummy ROOT webapp defined. I'm not sure why this would be a requirement, and I was not able to find any documentation about it. I understand why SSO might require contexts. But the primary purpose of RewriteRules is to hide the plumbing on the URL line. If the requirement for context present is required for SSO, then it would seem to me that the context should be checked on the target of the rewrite, not the original string being rewritten, since it most likely will not have a valid context. And a dummy unused ROOT webapp just takes up resources. The reason it worked in the other virtual host is that I actually did have a need in that host for a ROOT context. This one was painful. Just out of curiosity, is this restriction intended? If so, error messages and/or documentation of it might need a review. No. The restriction isn't intended. See this discussion around a similar issue: https://github.com/apache/tomcat/pull/479 Generally, not having a ROOT context is sufficiently unusual that it is rare for users to fund bugs like this. A similar approach should fix this - assume the default CookieProcessor if no context is found. Quick question. Is the SingleSignOn valve configured before the Rewrite valve in your Host? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSO Token not found with RewriteRules
On 16/01/2023 23:07, Jerry Malcolm wrote: Well, after downloading and installing the Tomcat source in my Eclipse environment and tracking through a bunch of breakpoints, I figured out what was happening. SingleSignOn.invoke() was querying for the list of cookies in the request (that were indeed present in the request), but was returning null. Since no cookies were 'found' there was no JSESSIONIDSSO cookie found, and everything failed from that point on. So I started tracking why the cookies that were present were being ignored. convertCookies was called, which did a getContext() which returned null, so everything aborted. getContext() failed apparently because I did not have a ROOT webapp (context) defined. I added a dummy ROOT webapp, and voila So the bottom line to the entire problem is that RewriteRules with SSO is not permitted UNLESS there is a dummy ROOT webapp defined. I'm not sure why this would be a requirement, and I was not able to find any documentation about it. I understand why SSO might require contexts. But the primary purpose of RewriteRules is to hide the plumbing on the URL line. If the requirement for context present is required for SSO, then it would seem to me that the context should be checked on the target of the rewrite, not the original string being rewritten, since it most likely will not have a valid context. And a dummy unused ROOT webapp just takes up resources. The reason it worked in the other virtual host is that I actually did have a need in that host for a ROOT context. This one was painful. Just out of curiosity, is this restriction intended? If so, error messages and/or documentation of it might need a review. No. The restriction isn't intended. See this discussion around a similar issue: https://github.com/apache/tomcat/pull/479 Generally, not having a ROOT context is sufficiently unusual that it is rare for users to fund bugs like this. A similar approach should fix this - assume the default CookieProcessor if no context is found. Mark Thanks. Jerry On 1/16/2023 12:40 AM, Jerry Malcolm wrote: I have one virtual host working fine on a Windows 11 TC 9 install. I am adding a 2nd virtual host to that same running installation. This TC is standalone, handling http requests directly (not via httpd). Both virtual hosts have a rewrite.config. On the new domain, I go to a page that requires a login, do the standard login, and it show the page. I can F5 refresh the page and it continues to appear. But if I enter a url that redirects to this same page, I get the signin screen. If I try to sign in again, I get an error "The requested resource [/idmanager/j_security_check] is not available" I enabled redirect logs, and they show SSO token not found. I know the redirect is working fine for the new virtual host since there's no problems going to unprotected (no sign-in) redirected pages. This exact scenario works perfectly fine (with rewrite rules) on the other virtual host in the same TC. I've compared the two host configurations in server.xml and they appear identical other than than the name and path. i.e. SingleSignOn valve is specified on both. The fact that SSO only fails on redirects and not on URLs without redirects, plus the fact that it works fine on one virtual host and not on the other is baffling me. All indications point to some sort of config error or typo on the something in the new virtual host. But I have spent more hours that I want to admit on this, and I simply can't figure out anything that would cause this. I'm sure I made some config change somewhere a long time ago on the first virtual host that's making it work correctly. But I can't find anything, and I'm at a total loss. What could be causing rewrite rules to not find SSO cookies? Where did I mess up? Thanks Jerry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSO Token not found with RewriteRules
Well, after downloading and installing the Tomcat source in my Eclipse environment and tracking through a bunch of breakpoints, I figured out what was happening. SingleSignOn.invoke() was querying for the list of cookies in the request (that were indeed present in the request), but was returning null. Since no cookies were 'found' there was no JSESSIONIDSSO cookie found, and everything failed from that point on. So I started tracking why the cookies that were present were being ignored. convertCookies was called, which did a getContext() which returned null, so everything aborted. getContext() failed apparently because I did not have a ROOT webapp (context) defined. I added a dummy ROOT webapp, and voila So the bottom line to the entire problem is that RewriteRules with SSO is not permitted UNLESS there is a dummy ROOT webapp defined. I'm not sure why this would be a requirement, and I was not able to find any documentation about it. I understand why SSO might require contexts. But the primary purpose of RewriteRules is to hide the plumbing on the URL line. If the requirement for context present is required for SSO, then it would seem to me that the context should be checked on the target of the rewrite, not the original string being rewritten, since it most likely will not have a valid context. And a dummy unused ROOT webapp just takes up resources. The reason it worked in the other virtual host is that I actually did have a need in that host for a ROOT context. This one was painful. Just out of curiosity, is this restriction intended? If so, error messages and/or documentation of it might need a review. Thanks. Jerry On 1/16/2023 12:40 AM, Jerry Malcolm wrote: I have one virtual host working fine on a Windows 11 TC 9 install. I am adding a 2nd virtual host to that same running installation. This TC is standalone, handling http requests directly (not via httpd). Both virtual hosts have a rewrite.config. On the new domain, I go to a page that requires a login, do the standard login, and it show the page. I can F5 refresh the page and it continues to appear. But if I enter a url that redirects to this same page, I get the signin screen. If I try to sign in again, I get an error "The requested resource [/idmanager/j_security_check] is not available" I enabled redirect logs, and they show SSO token not found. I know the redirect is working fine for the new virtual host since there's no problems going to unprotected (no sign-in) redirected pages. This exact scenario works perfectly fine (with rewrite rules) on the other virtual host in the same TC. I've compared the two host configurations in server.xml and they appear identical other than than the name and path. i.e. SingleSignOn valve is specified on both. The fact that SSO only fails on redirects and not on URLs without redirects, plus the fact that it works fine on one virtual host and not on the other is baffling me. All indications point to some sort of config error or typo on the something in the new virtual host. But I have spent more hours that I want to admit on this, and I simply can't figure out anything that would cause this. I'm sure I made some config change somewhere a long time ago on the first virtual host that's making it work correctly. But I can't find anything, and I'm at a total loss. What could be causing rewrite rules to not find SSO cookies? Where did I mess up? Thanks Jerry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSO fails on Tomcat 9
Hello Mark,André, No success on my side for SSO, I have installed 9.0.26 and changed the config according to this mail but no success. Regards, Heidi Leerink - Duverger -Oorspronkelijk bericht- Van: Mark Thomas Verzonden: dinsdag 10 september 2019 18:07 Aan: users@tomcat.apache.org Onderwerp: Re: SSO fails on Tomcat 9 On 10/09/2019 16:47, André Warnier (tomcat) wrote: > On 10.09.2019 15:38, Mark Thomas wrote: >> On 06/09/2019 13:20, Heidi Leerink - Duverger wrote: >>> Hello Mark, >>> >>> That helps somewhat, my browser now shows the login page for our >>> application, BUT I do not get my username in HTTP variable >>> REMOTE_USER but the principal keytab related name. >>> >>> So instead of hduverge I get HTTP/nlsl-decadetst.u4agr.com@U$AGR.COM >> >> The Tomcat Authenticator takes care of validating the user. In the >> configuration you provided the JAASRealm is - effectively - >> (re-)validating the contents of the keytab file. That is why you see >> the keytab principal as the authenticated user. >> >> Try replacing the JAASRealm with the AuthenticatedUserRealm. >> Something >> like: >> >> > allRolesMode="authOnly" > > Mmm. That looks like a typo, likely to confuse this OP even more, no ? Yep. Copy paste error. Should be: Tx. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSO fails on Tomcat 9
On 10/09/2019 16:47, André Warnier (tomcat) wrote: > On 10.09.2019 15:38, Mark Thomas wrote: >> On 06/09/2019 13:20, Heidi Leerink - Duverger wrote: >>> Hello Mark, >>> >>> That helps somewhat, my browser now shows the login page for our >>> application, BUT I do not get my username in HTTP variable >>> REMOTE_USER but the principal keytab related name. >>> >>> So instead of hduverge I get HTTP/nlsl-decadetst.u4agr.com@U$AGR.COM >> >> The Tomcat Authenticator takes care of validating the user. In the >> configuration you provided the JAASRealm is - effectively - >> (re-)validating the contents of the keytab file. That is why you see the >> keytab principal as the authenticated user. >> >> Try replacing the JAASRealm with the AuthenticatedUserRealm. Something >> like: >> >> > allRolesMode="authOnly" > > Mmm. That looks like a typo, likely to confuse this OP even more, no ? Yep. Copy paste error. Should be: Tx. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSO fails on Tomcat 9
On 10.09.2019 15:38, Mark Thomas wrote: On 06/09/2019 13:20, Heidi Leerink - Duverger wrote: Hello Mark, That helps somewhat, my browser now shows the login page for our application, BUT I do not get my username in HTTP variable REMOTE_USER but the principal keytab related name. So instead of hduverge I get HTTP/nlsl-decadetst.u4agr.com@U$AGR.COM The Tomcat Authenticator takes care of validating the user. In the configuration you provided the JAASRealm is - effectively - (re-)validating the contents of the keytab file. That is why you see the keytab principal as the authenticated user. Try replacing the JAASRealm with the AuthenticatedUserRealm. Something like: Mmm. That looks like a typo, likely to confuse this OP even more, no ? Note: This Realm should *only* be used with Authenticators like org.apache.catalina.authenticator.SpnegoAuthenticator that authenticate the user since this Realm simply takes the information provided and assumes it is valid. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSO fails on Tomcat 9
On 06/09/2019 13:20, Heidi Leerink - Duverger wrote: > Hello Mark, > > That helps somewhat, my browser now shows the login page for our application, > BUT I do not get my username in HTTP variable REMOTE_USER but the principal > keytab related name. > > So instead of hduverge I get HTTP/nlsl-decadetst.u4agr.com@U$AGR.COM The Tomcat Authenticator takes care of validating the user. In the configuration you provided the JAASRealm is - effectively - (re-)validating the contents of the keytab file. That is why you see the keytab principal as the authenticated user. Try replacing the JAASRealm with the AuthenticatedUserRealm. Something like:
RE: SSO fails on Tomcat 9
Thank you André for this analysis, I am an Oracle developer and I understand most of the reasoning in you answer, but I need to chew on it for some time and seek help in our organization for Kerberos knowledge. Our application first only had a database authentication and over time more and more customers required SSO. So I configured Tomcat with Spnego based on an Oracle blog, and that worked fine in Tomcat 7 and 8. But now some customers want to upgrade to Tomcat 9 The application only uses the HTTP variable :REMOTE_USER to decide if there is a SSO configuration present and if so links the Windows user to an application user and else de user has to login against the database to authenticate. Met vriendelijke groeten van Heidi Leerink - Duverger Technisch Consultant In business for people. Unit4 Business Software Netherlands B.V. Papendorpseweg 100, 3710 BJ Utrecht, Netherlands T +31 88 247 1444 E heidi.duver...@unit4.com This message and any attachment(s) are intended only for the use of the named recipient and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient, please notify the sender by return e-mail and delete this message from your system. Do not disclose the contents of this document to any other persons. Violation of this notice may be unlawful. Please note that internet communications are not secure and e-mails are susceptible to change. Thank you for your cooperation. -Original Message- From: André Warnier (tomcat) [mailto:a...@ice-sa.com] Sent: vrijdag 6 september 2019 12:15 To: users@tomcat.apache.org Subject: Re: SSO fails on Tomcat 9 Hi Heidi. We have kind of a conundrum here : - Mark (who is one of the main tomcat developers) tested the SPNEGO (Kerberos) authentication under both tomcat8 and tomcat9, using the standard instructions provided in the respective on-line tomcat documentation pages, and reported that it works in both cases. - You report that your installation works with tomcat8, but not with tomcat9, and that you are using the same infrastructure and the same parameters in both cases. (Someone else also reported a case with problems with tomcat9). - The description of your problem (and the tomcat9 logfiles) seems to indicate a problem with the Kerberos "pre-authentication". (These lines of the log : >>>KRBError: ... error code is 25 error Message is Additional pre-authentication required ) And based on my own previous experience with Windows authentication in general (but not Kerberos), it is also my impression that your problem is at the Kerberos level, not really at the tomcat level. I have looked for "Kerberos Additional pre-authentication required" in the www, and despite the fact that I do not really know Kerberos, it seems that the error message above indicates that your browser and the server cannot even agree between them, to actually start exchanging Kerberos tokens (keys) between them, to complete a Kerberos authentication. (And that may be why you see a single 401 response in your logs, and why SPNEGO immediately concludes that the user is not authenticated). (There are also lines in that logfile, which seem to hint at some DNS (name resolution) issue, but that may be a false alarm or a secondary issue). One way to reconcile the above conflicting information, would be if for example some SPNEGO Valve parameter, in your configuration, would be unspecified and defaulting to some value in your case, and a different value in Mark's case. (Or vice-versa, that you are specifying a value, and Mark is using the default, and the result is not the same.) Another possibility would be that the available (or default) encryption methods are different between tomcat8 and tomcat9 (or between different browsers), and that in your case and Mark's, the browser and the server arrive at different encryption choices and cannot agree on a common one. It may be useful for you and Mark to compare in detail, the settings which you use for the SPNEGO Valve (and/or for encryption ?). Another very vague (and maybe wrong) suspicion that I would have is based on some questions : - does the tomcat hostname play a role in the Kerberos authentication ? - if yes, does the SPNEGO Valve obtain this name via some ".getServerName()"-like method, whose result may be different under tomcat8 and tomcat9 in some circumstances ? On 05.09.2019 22:10, Heidi Leerink - Duverger wrote: > Hello Mark, > > I have spent a lot of time comparing both T8 and T9 installations on de > nsl-decadetst.u4agr.com PC. > Sorry but I can't find a major difference in the conf file, apart from > differences Tomcat itself came with in the conf files. > The stdout is mainly the same and the stderr show in Tomcat 8 hduverge > authenticated and in Tomcat 9 not authenticate
RE: SSO fails on Tomcat 9
Hello Mark, That helps somewhat, my browser now shows the login page for our application, BUT I do not get my username in HTTP variable REMOTE_USER but the principal keytab related name. So instead of hduverge I get HTTP/nlsl-decadetst.u4agr.com@U$AGR.COM To be complete this I the keytab creation statement issued by our AD admin: ktpass /out c:\Temp\tomcat.keytab /mapuser decade_sso...@u4agr.com /princ HTTP/nlsl-decadetst.u4agr@u4agr.com /pass "" /kvno 0 -ptype KRB5_NT_PRINCIPAL Met vriendelijke groeten van Heidi Leerink - Duverger Technisch Consultant In business for people. Unit4 Business Software Netherlands B.V. Papendorpseweg 100, 3710 BJ Utrecht, Netherlands T +31 88 247 1444 E heidi.duver...@unit4.com This message and any attachment(s) are intended only for the use of the named recipient and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient, please notify the sender by return e-mail and delete this message from your system. Do not disclose the contents of this document to any other persons. Violation of this notice may be unlawful. Please note that internet communications are not secure and e-mails are susceptible to change. Thank you for your cooperation. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: vrijdag 6 september 2019 11:55 To: users@tomcat.apache.org Subject: Re: SSO fails on Tomcat 9 On 05/09/2019 21:10, Heidi Leerink - Duverger wrote: > Hello Mark, > > I have spent a lot of time comparing both T8 and T9 installations on de > nsl-decadetst.u4agr.com PC. > Sorry but I can't find a major difference in the conf file, apart from > differences Tomcat itself came with in the conf files. > The stdout is mainly the same and the stderr show in Tomcat 8 hduverge > authenticated and in Tomcat 9 not authenticated. > I'm lost now I have no ideas left where to look for differences or how to > find a solution for this major issue. > Attached once again the files from our Tomcat 8 and Tomcat 9 installation. I took another look and I think the issue is with the JAASRealm configuration rather than with SPNEGO. I think you have been caught out by this change: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fcommit%2Fb5ca3e08b8cdd998e22f486293bca6b89e2644e3&data=01%7C01%7Cheidi.duverger%40unit4.com%7C1d4983f01ef74742b7fe08d732b03c7d%7Cee137cc45d4343cf9da5f75728b8d21f%7C1&sdata=oHIwRhtka1MiYOIAYg5okvI3BRC0IFNCWaE2oNR%2FZd4%3D&reserved=0 Try adding: userClassNames="javax.security.auth.kerberos.KerberosPrincipal" to your JAASRealm configuration in apex42a.xml Mark > > Met vriendelijke groeten van > Heidi Leerink - Duverger > Technisch Consultant > > Met vriendelijke groeten van > Heidi Leerink - Duverger > Technisch Consultant > > > In business for people. > Unit4 Business Software Netherlands B.V. > Papendorpseweg 100, 3710 BJ Utrecht, Netherlands T +31 88 247 1444 E > heidi.duver...@unit4.com This message and any attachment(s) are > intended only for the use of the named recipient and may contain information > that is privileged, confidential or otherwise exempt from disclosure under > applicable law. If you are not the intended recipient, please notify the > sender by return e-mail and delete this message from your system. Do not > disclose the contents of this document to any other persons. Violation of > this notice may be unlawful. Please note that internet communications are not > secure and e-mails are susceptible to change. Thank you for your cooperation. > > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: woensdag 4 september 2019 11:09 > To: users@tomcat.apache.org > Subject: Re: SSO fails on Tomcat 9 > > Heidi, > > I have just completed the tests and SPNEGO works as expected with both Tomcat > 8.5.x and 9.0.x. > > The test environment was as per: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftomca > t.apache.org%2Ftomcat-9.0-doc%2Fwindows-auth-howto.html&data=01%7C > 01%7Cheidi.duverger%40unit4.com%7C1d4983f01ef74742b7fe08d732b03c7d%7Ce > e137cc45d4343cf9da5f75728b8d21f%7C1&sdata=K4sjAdNob45pzLu6Y3TqQf6S > nd%2BeKdzhwaEVhwSY37g%3D&reserved=0 > > with the following changes: > - Updated the Domain Controller and Tomcat instance with all the latest > patches from Windows update > - Oracle Java 1.8.0u162 / Adopt OpenJDK Java 11.0.4_11 (tested Tomcat > running under both) > - Tomcat 8.5.x, Tomcat 9.0.x (current HEAD at the time of writing), > 9.0.24 (from the tag) > > The test environment uses separate CATALINA_HOME / CATALINA_BASE so the > Tomcat instance
Re: SSO fails on Tomcat 9
Hi Heidi. We have kind of a conundrum here : - Mark (who is one of the main tomcat developers) tested the SPNEGO (Kerberos) authentication under both tomcat8 and tomcat9, using the standard instructions provided in the respective on-line tomcat documentation pages, and reported that it works in both cases. - You report that your installation works with tomcat8, but not with tomcat9, and that you are using the same infrastructure and the same parameters in both cases. (Someone else also reported a case with problems with tomcat9). - The description of your problem (and the tomcat9 logfiles) seems to indicate a problem with the Kerberos "pre-authentication". (These lines of the log : >>>KRBError: ... error code is 25 error Message is Additional pre-authentication required ) And based on my own previous experience with Windows authentication in general (but not Kerberos), it is also my impression that your problem is at the Kerberos level, not really at the tomcat level. I have looked for "Kerberos Additional pre-authentication required" in the www, and despite the fact that I do not really know Kerberos, it seems that the error message above indicates that your browser and the server cannot even agree between them, to actually start exchanging Kerberos tokens (keys) between them, to complete a Kerberos authentication. (And that may be why you see a single 401 response in your logs, and why SPNEGO immediately concludes that the user is not authenticated). (There are also lines in that logfile, which seem to hint at some DNS (name resolution) issue, but that may be a false alarm or a secondary issue). One way to reconcile the above conflicting information, would be if for example some SPNEGO Valve parameter, in your configuration, would be unspecified and defaulting to some value in your case, and a different value in Mark's case. (Or vice-versa, that you are specifying a value, and Mark is using the default, and the result is not the same.) Another possibility would be that the available (or default) encryption methods are different between tomcat8 and tomcat9 (or between different browsers), and that in your case and Mark's, the browser and the server arrive at different encryption choices and cannot agree on a common one. It may be useful for you and Mark to compare in detail, the settings which you use for the SPNEGO Valve (and/or for encryption ?). Another very vague (and maybe wrong) suspicion that I would have is based on some questions : - does the tomcat hostname play a role in the Kerberos authentication ? - if yes, does the SPNEGO Valve obtain this name via some ".getServerName()"-like method, whose result may be different under tomcat8 and tomcat9 in some circumstances ? On 05.09.2019 22:10, Heidi Leerink - Duverger wrote: Hello Mark, I have spent a lot of time comparing both T8 and T9 installations on de nsl-decadetst.u4agr.com PC. Sorry but I can't find a major difference in the conf file, apart from differences Tomcat itself came with in the conf files. The stdout is mainly the same and the stderr show in Tomcat 8 hduverge authenticated and in Tomcat 9 not authenticated. I'm lost now I have no ideas left where to look for differences or how to find a solution for this major issue. Attached once again the files from our Tomcat 8 and Tomcay 9 installation. Met vriendelijke groeten van Heidi Leerink - Duverger Technisch Consultant Met vriendelijke groeten van Heidi Leerink - Duverger Technisch Consultant In business for people. Unit4 Business Software Netherlands B.V. Papendorpseweg 100, 3710 BJ Utrecht, Netherlands T +31 88 247 1444 E heidi.duver...@unit4.com This message and any attachment(s) are intended only for the use of the named recipient and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient, please notify the sender by return e-mail and delete this message from your system. Do not disclose the contents of this document to any other persons. Violation of this notice may be unlawful. Please note that internet communications are not secure and e-mails are susceptible to change. Thank you for your cooperation. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: woensdag 4 september 2019 11:09 To: users@tomcat.apache.org Subject: Re: SSO fails on Tomcat 9 Heidi, I have just completed the tests and SPNEGO works as expected with both Tomcat 8.5.x and 9.0.x. The test environment was as per: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fwindows-auth-howto.html&data=01%7C01%7Cheidi.duverger%40unit4.com%7Cc8223b9bd1f34f08008608d731178dde%7Cee137cc45d4343cf9da5f75728b8d21f%7C1&sdata=I%2BJLU837vV78VExqcHdf5Z5MYat2HDEPbNKvpsmq6%2FE%3D&reserved=0 with the following ch
Re: SSO fails on Tomcat 9
On 05/09/2019 21:10, Heidi Leerink - Duverger wrote: > Hello Mark, > > I have spent a lot of time comparing both T8 and T9 installations on de > nsl-decadetst.u4agr.com PC. > Sorry but I can't find a major difference in the conf file, apart from > differences Tomcat itself came with in the conf files. > The stdout is mainly the same and the stderr show in Tomcat 8 hduverge > authenticated and in Tomcat 9 not authenticated. > I'm lost now I have no ideas left where to look for differences or how to > find a solution for this major issue. > Attached once again the files from our Tomcat 8 and Tomcat 9 installation. I took another look and I think the issue is with the JAASRealm configuration rather than with SPNEGO. I think you have been caught out by this change: https://github.com/apache/tomcat/commit/b5ca3e08b8cdd998e22f486293bca6b89e2644e3 Try adding: userClassNames="javax.security.auth.kerberos.KerberosPrincipal" to your JAASRealm configuration in apex42a.xml Mark > > Met vriendelijke groeten van > Heidi Leerink - Duverger > Technisch Consultant > > Met vriendelijke groeten van > Heidi Leerink - Duverger > Technisch Consultant > > > In business for people. > Unit4 Business Software Netherlands B.V. > Papendorpseweg 100, 3710 BJ Utrecht, Netherlands > T +31 88 247 1444 > E heidi.duver...@unit4.com > This message and any attachment(s) are intended only for the use of the named > recipient and may contain information that is privileged, confidential or > otherwise exempt from disclosure under applicable law. If you are not the > intended recipient, please notify the sender by return e-mail and delete this > message from your system. Do not disclose the contents of this document to > any other persons. Violation of this notice may be unlawful. Please note that > internet communications are not secure and e-mails are susceptible to change. > Thank you for your cooperation. > > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: woensdag 4 september 2019 11:09 > To: users@tomcat.apache.org > Subject: Re: SSO fails on Tomcat 9 > > Heidi, > > I have just completed the tests and SPNEGO works as expected with both Tomcat > 8.5.x and 9.0.x. > > The test environment was as per: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fwindows-auth-howto.html&data=01%7C01%7Cheidi.duverger%40unit4.com%7Cc8223b9bd1f34f08008608d731178dde%7Cee137cc45d4343cf9da5f75728b8d21f%7C1&sdata=I%2BJLU837vV78VExqcHdf5Z5MYat2HDEPbNKvpsmq6%2FE%3D&reserved=0 > > with the following changes: > - Updated the Domain Controller and Tomcat instance with all the latest > patches from Windows update > - Oracle Java 1.8.0u162 / Adopt OpenJDK Java 11.0.4_11 (tested Tomcat > running under both) > - Tomcat 8.5.x, Tomcat 9.0.x (current HEAD at the time of writing), > 9.0.24 (from the tag) > > The test environment uses separate CATALINA_HOME / CATALINA_BASE so the > Tomcat instance configuration (CATALINA_BASE) is guaranteed to be identical > while I vary the Tomcat binary (CATALINA_HOME) to use. > > > It looks like there is something not quite right with the Tomcat 9 > configuration. > > You could try adding: > > -Dsun.security.spnego.debug=true > > in setenv.bat. That might provide some insight although I've had mixed > experience using that to debug SPNEGO issues in the past. > > > >>> Thank you for your help with this, it must be that Tomcat 9 SPNEGO is more >>> strict than the Tomcat 8 implementation was... > I haven't found any evidence to support the above conclusion at this point. > All the evidence so far (diff of the relevant code and my own test > environment) points to a configuration difference in your Tomcat 9 > installation. > > You mentioned starting and stopping services. I wondered if the change of > default user from "Local System" to "Local Service" had triggered this issue > but that makes no difference. > > Looking at your log files in more detail, I do notice a few things: > > -Djava.security.krb5.ini=... > > The above system property is incorrect. It should be: > > -Djava.security.krb5.conf=... > > It won't impact your environment because it appears to be set to the default. > This affects both Tomcat 8 and Tomcat 9. > > The conf\krb5.ini does not specify the keytab file. In the config files in > the Tomcat docs this looks like: > default_keytab_name = FILE:c:\apache-tomcat-9.0.x\conf\tomcat.keytab > > The debug logs for the authentication p
Re: SSO fails on Tomcat 9
Heidi, I have just completed the tests and SPNEGO works as expected with both Tomcat 8.5.x and 9.0.x. The test environment was as per: http://tomcat.apache.org/tomcat-9.0-doc/windows-auth-howto.html with the following changes: - Updated the Domain Controller and Tomcat instance with all the latest patches from Windows update - Oracle Java 1.8.0u162 / Adopt OpenJDK Java 11.0.4_11 (tested Tomcat running under both) - Tomcat 8.5.x, Tomcat 9.0.x (current HEAD at the time of writing), 9.0.24 (from the tag) The test environment uses separate CATALINA_HOME / CATALINA_BASE so the Tomcat instance configuration (CATALINA_BASE) is guaranteed to be identical while I vary the Tomcat binary (CATALINA_HOME) to use. It looks like there is something not quite right with the Tomcat 9 configuration. You could try adding: -Dsun.security.spnego.debug=true in setenv.bat. That might provide some insight although I've had mixed experience using that to debug SPNEGO issues in the past. >> Thank you for your help with this, it must be that Tomcat 9 SPNEGO is more >> strict than the Tomcat 8 implementation was... I haven't found any evidence to support the above conclusion at this point. All the evidence so far (diff of the relevant code and my own test environment) points to a configuration difference in your Tomcat 9 installation. You mentioned starting and stopping services. I wondered if the change of default user from "Local System" to "Local Service" had triggered this issue but that makes no difference. Looking at your log files in more detail, I do notice a few things: -Djava.security.krb5.ini=... The above system property is incorrect. It should be: -Djava.security.krb5.conf=... It won't impact your environment because it appears to be set to the default. This affects both Tomcat 8 and Tomcat 9. The conf\krb5.ini does not specify the keytab file. In the config files in the Tomcat docs this looks like: default_keytab_name = FILE:c:\apache-tomcat-9.0.x\conf\tomcat.keytab The debug logs for the authentication processes look very different. That strongly suggests that the configurations are not the same. I would concentrated on comparing the configuration of the two systems. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSO fails on Tomcat 9
Thanks Mark! Take your time, I have in a meeting tomorrow most part of the day... Heidi Met vriendelijke groeten van Heidi Leerink - Duverger Technisch Consultant In business for people. Unit4 Business Software Netherlands B.V. Papendorpseweg 100, 3710 BJ Utrecht, Netherlands T +31 88 247 1444 E heidi.duver...@unit4.com This message and any attachment(s) are intended only for the use of the named recipient and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient, please notify the sender by return e-mail and delete this message from your system. Do not disclose the contents of this document to any other persons. Violation of this notice may be unlawful. Please note that internet communications are not secure and e-mails are susceptible to change. Thank you for your cooperation. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: dinsdag 3 september 2019 20:31 To: users@tomcat.apache.org Subject: Re: SSO fails on Tomcat 9 Heidi, I have the set of test VMs I used when first implementing this feature. They are the ones I used when I wrote: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fwindows-auth-howto.html&data=01%7C01%7Cheidi.duverger%40unit4.com%7C4fd1fb493ccf40d2b02008d7309ce714%7Cee137cc45d4343cf9da5f75728b8d21f%7C1&sdata=Mro6GR3fy4X2cEpm0mbZBwszTt1jfHl7knJifFnKrao%3D&reserved=0 I'll fire them up, install 9.0.24, test and report back. I have done a quick diff of the key classes between 9.0.x and 8.5.x and I don't see any changes that should cause problems. Experience tells me I am going to spend more time getting the VMs updated with the latest patches (I don't turn them on that often) than I am going to spend testing. Don't be surprised if it takes until tomorrow for me to report back. Mark On 03/09/2019 17:38, Heidi Leerink - Duverger wrote: > Hello Alex, > > This is the result of the nslookup: > > C:\Users\hduverge>nslookup nlsl-decadetest > Server: nlsl-dccrp01p.corp.u4agr.com > Address: 10.100.2.2 > > *** nlsl-dccrp01p.corp.u4agr.com can't find nlsl-decadetest: > Non-existent domain > > C:\Users\hduverge> > C:\Users\hduverge>nslookup nlsl-decadetest.u4agr.com > Server: nlsl-dccrp01p.corp.u4agr.com > Address: 10.100.2.2 > > *** nlsl-dccrp01p.corp.u4agr.com can't find nlsl-decadetest.u4agr.com: > Non-existent domain > >> Q3: Is the PC where you are using the browser to test, also the same one >> where Tomcat is installed ? >> (I am not sure that this type of authentication should work, if the same >> machine is at the same time the client and the server) In any case, it may >> >be a good idea if you tested the same access, with a browser on another PC >> workstation. > I test the SSO URL on my own desktop in Google chrome and IE11, but if I test > de URL in IE11 on de nls-decadetest it asks for a window login and then gives > the same error as I get on my desktop. > > I think that it would be better to move this test to a real server , but ATM > we have everything in the cloud (azure) and it is so nearly impossible to get > a setup (AD user principal and tomcat.keytab) from support, but I will check > if I can further test at our customers site > > Thank you for your help with this, it must be that Tomcat 9 SPNEGO is more > strict than the Tomcat 8 implementation was... > > Met vriendelijke groeten van > Heidi Leerink - Duverger > Technisch Consultant > > > In business for people. > Unit4 Business Software Netherlands B.V. > Papendorpseweg 100, 3710 BJ Utrecht, Netherlands T +31 88 247 1444 E > heidi.duver...@unit4.com This message and any attachment(s) are > intended only for the use of the named recipient and may contain information > that is privileged, confidential or otherwise exempt from disclosure under > applicable law. If you are not the intended recipient, please notify the > sender by return e-mail and delete this message from your system. Do not > disclose the contents of this document to any other persons. Violation of > this notice may be unlawful. Please note that internet communications are not > secure and e-mails are susceptible to change. Thank you for your cooperation. > > -Original Message- > From: André Warnier (tomcat) [mailto:a...@ice-sa.com] > Sent: dinsdag 3 september 2019 14:27 > To: users@tomcat.apache.org > Subject: Re: SSO fails on Tomcat 9 > > Hi. > See below. > > On 03.09.2019 11:56, Heidi Leerink - Duverger wrote: >> Hello Alex, >> >> Thank you for the extensive answer. >> >> Q1: Are you sure that it is *exactly* the same
Re: SSO fails on Tomcat 9
Heidi, I have the set of test VMs I used when first implementing this feature. They are the ones I used when I wrote: http://tomcat.apache.org/tomcat-9.0-doc/windows-auth-howto.html I'll fire them up, install 9.0.24, test and report back. I have done a quick diff of the key classes between 9.0.x and 8.5.x and I don't see any changes that should cause problems. Experience tells me I am going to spend more time getting the VMs updated with the latest patches (I don't turn them on that often) than I am going to spend testing. Don't be surprised if it takes until tomorrow for me to report back. Mark On 03/09/2019 17:38, Heidi Leerink - Duverger wrote: > Hello Alex, > > This is the result of the nslookup: > > C:\Users\hduverge>nslookup nlsl-decadetest > Server: nlsl-dccrp01p.corp.u4agr.com > Address: 10.100.2.2 > > *** nlsl-dccrp01p.corp.u4agr.com can't find nlsl-decadetest: Non-existent > domain > > C:\Users\hduverge> > C:\Users\hduverge>nslookup nlsl-decadetest.u4agr.com > Server: nlsl-dccrp01p.corp.u4agr.com > Address: 10.100.2.2 > > *** nlsl-dccrp01p.corp.u4agr.com can't find nlsl-decadetest.u4agr.com: > Non-existent domain > >> Q3: Is the PC where you are using the browser to test, also the same one >> where Tomcat is installed ? >> (I am not sure that this type of authentication should work, if the same >> machine is at the same time the client and the server) In any case, it may >> >be a good idea if you tested the same access, with a browser on another PC >> workstation. > I test the SSO URL on my own desktop in Google chrome and IE11, but if I test > de URL in IE11 on de nls-decadetest it asks for a window login and then gives > the same error as I get on my desktop. > > I think that it would be better to move this test to a real server , but ATM > we have everything in the cloud (azure) and it is so nearly impossible to get > a setup (AD user principal and tomcat.keytab) from support, but I will check > if I can further test at our customers site > > Thank you for your help with this, it must be that Tomcat 9 SPNEGO is more > strict than the Tomcat 8 implementation was... > > Met vriendelijke groeten van > Heidi Leerink - Duverger > Technisch Consultant > > > In business for people. > Unit4 Business Software Netherlands B.V. > Papendorpseweg 100, 3710 BJ Utrecht, Netherlands > T +31 88 247 1444 > E heidi.duver...@unit4.com > This message and any attachment(s) are intended only for the use of the named > recipient and may contain information that is privileged, confidential or > otherwise exempt from disclosure under applicable law. If you are not the > intended recipient, please notify the sender by return e-mail and delete this > message from your system. Do not disclose the contents of this document to > any other persons. Violation of this notice may be unlawful. Please note that > internet communications are not secure and e-mails are susceptible to change. > Thank you for your cooperation. > > -Original Message- > From: André Warnier (tomcat) [mailto:a...@ice-sa.com] > Sent: dinsdag 3 september 2019 14:27 > To: users@tomcat.apache.org > Subject: Re: SSO fails on Tomcat 9 > > Hi. > See below. > > On 03.09.2019 11:56, Heidi Leerink - Duverger wrote: >> Hello Alex, >> >> Thank you for the extensive answer. >> >> Q1: Are you sure that it is *exactly* the same ? >> Yes the installation is done on the same PC with the same user principal for >> the Tomcat service to log in . >> The Tomcat 8 service is stopped during the Tomcat 9 test. >> We had the exact same problem when installing in a test environment at one >> of our Customer sites. Most of our customers that are using SSO with our >> application are still using Tomcat 8 with no problems and all with the same >> spnego config. >> My colleague initially set up this Tomcat 9 installation using a few tomcat >> 9 versions ( .8 .20 and .24). I myself, reinstalled and configured Tomcat >> 9.024 from scratch, with no success and always the same results. >> > > Q3: Is the PC where you are using the browser to test, also the same one > where Tomcat is installed ? > (I am not sure that this type of authentication should work, if the same > machine is at the same time the client and the server) In any case, it may be > a good idea if you tested the same access, with a browser on another PC > workstation. > >> Q2: when "it does not work", does the browser popup a login dialog ? >> Yes I have seen that one be not with the recent config. >> Browser response : >> >> Google Chrome &
RE: SSO fails on Tomcat 9
Hello Alex, This is the result of the nslookup: C:\Users\hduverge>nslookup nlsl-decadetest Server: nlsl-dccrp01p.corp.u4agr.com Address: 10.100.2.2 *** nlsl-dccrp01p.corp.u4agr.com can't find nlsl-decadetest: Non-existent domain C:\Users\hduverge> C:\Users\hduverge>nslookup nlsl-decadetest.u4agr.com Server: nlsl-dccrp01p.corp.u4agr.com Address: 10.100.2.2 *** nlsl-dccrp01p.corp.u4agr.com can't find nlsl-decadetest.u4agr.com: Non-existent domain >Q3: Is the PC where you are using the browser to test, also the same one where >Tomcat is installed ? >(I am not sure that this type of authentication should work, if the same >machine is at the same time the client and the server) In any case, it may >be >a good idea if you tested the same access, with a browser on another PC >workstation. I test the SSO URL on my own desktop in Google chrome and IE11, but if I test de URL in IE11 on de nls-decadetest it asks for a window login and then gives the same error as I get on my desktop. I think that it would be better to move this test to a real server , but ATM we have everything in the cloud (azure) and it is so nearly impossible to get a setup (AD user principal and tomcat.keytab) from support, but I will check if I can further test at our customers site Thank you for your help with this, it must be that Tomcat 9 SPNEGO is more strict than the Tomcat 8 implementation was... Met vriendelijke groeten van Heidi Leerink - Duverger Technisch Consultant In business for people. Unit4 Business Software Netherlands B.V. Papendorpseweg 100, 3710 BJ Utrecht, Netherlands T +31 88 247 1444 E heidi.duver...@unit4.com This message and any attachment(s) are intended only for the use of the named recipient and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient, please notify the sender by return e-mail and delete this message from your system. Do not disclose the contents of this document to any other persons. Violation of this notice may be unlawful. Please note that internet communications are not secure and e-mails are susceptible to change. Thank you for your cooperation. -Original Message- From: André Warnier (tomcat) [mailto:a...@ice-sa.com] Sent: dinsdag 3 september 2019 14:27 To: users@tomcat.apache.org Subject: Re: SSO fails on Tomcat 9 Hi. See below. On 03.09.2019 11:56, Heidi Leerink - Duverger wrote: > Hello Alex, > > Thank you for the extensive answer. > > Q1: Are you sure that it is *exactly* the same ? > Yes the installation is done on the same PC with the same user principal for > the Tomcat service to log in . > The Tomcat 8 service is stopped during the Tomcat 9 test. > We had the exact same problem when installing in a test environment at one of > our Customer sites. Most of our customers that are using SSO with our > application are still using Tomcat 8 with no problems and all with the same > spnego config. > My colleague initially set up this Tomcat 9 installation using a few tomcat 9 > versions ( .8 .20 and .24). I myself, reinstalled and configured Tomcat 9.024 > from scratch, with no success and always the same results. > Q3: Is the PC where you are using the browser to test, also the same one where Tomcat is installed ? (I am not sure that this type of authentication should work, if the same machine is at the same time the client and the server) In any case, it may be a good idea if you tested the same access, with a browser on another PC workstation. > Q2: when "it does not work", does the browser popup a login dialog ? > Yes I have seen that one be not with the recent config. > Browser response : > > Google Chrome > This site can't be reachedThe webpage at http://nlsl-decadetst:8787/apex42a/ > might be temporarily down or it may have moved permanently to a new web > address. > ERR_INVALID_RESPONSE > > Internet Explorer 11: > Can't reach this page > .Make sure the web address http://nlsl-decadetst:8787 is correct > .Search for this site on Bing .Refresh the page More information More > information The connection to the website was reset. > Error Code: INET_E_DOWNLOAD_FAILURE > Both of the errors above indicate more a DNS or TCP issue, than a tomcat or authentication issue. (As shown, they indicate that the browser can either not find the server "nlsl-decadetst", or cannot make a TCP connection to "nlsl-decadetst:8787") On the same workstation PC where you are doing these tests, can you a) open a command window b) enter : nslookup nlsl-decadetst c) tell us what the response is ? d) enter : nslookup nlsl-decadetst.u4agr.com e) tell us what the response is ? > (attachements the most recent stderr and stdout) > Unfortunately, I am no Kerberos specialist a
Re: SSO fails on Tomcat 9
Hi. See below. On 03.09.2019 11:56, Heidi Leerink - Duverger wrote: Hello Alex, Thank you for the extensive answer. Q1: Are you sure that it is *exactly* the same ? Yes the installation is done on the same PC with the same user principal for the Tomcat service to log in . The Tomcat 8 service is stopped during the Tomcat 9 test. We had the exact same problem when installing in a test environment at one of our Customer sites. Most of our customers that are using SSO with our application are still using Tomcat 8 with no problems and all with the same spnego config. My colleague initially set up this Tomcat 9 installation using a few tomcat 9 versions ( .8 .20 and .24). I myself, reinstalled and configured Tomcat 9.024 from scratch, with no success and always the same results. Q3: Is the PC where you are using the browser to test, also the same one where Tomcat is installed ? (I am not sure that this type of authentication should work, if the same machine is at the same time the client and the server) In any case, it may be a good idea if you tested the same access, with a browser on another PC workstation. Q2: when "it does not work", does the browser popup a login dialog ? Yes I have seen that one be not with the recent config. Browser response : Google Chrome This site can't be reachedThe webpage at http://nlsl-decadetst:8787/apex42a/ might be temporarily down or it may have moved permanently to a new web address. ERR_INVALID_RESPONSE Internet Explorer 11: Can't reach this page .Make sure the web address http://nlsl-decadetst:8787 is correct .Search for this site on Bing .Refresh the page More information More information The connection to the website was reset. Error Code: INET_E_DOWNLOAD_FAILURE Both of the errors above indicate more a DNS or TCP issue, than a tomcat or authentication issue. (As shown, they indicate that the browser can either not find the server "nlsl-decadetst", or cannot make a TCP connection to "nlsl-decadetst:8787") On the same workstation PC where you are doing these tests, can you a) open a command window b) enter : nslookup nlsl-decadetst c) tell us what the response is ? d) enter : nslookup nlsl-decadetst.u4agr.com e) tell us what the response is ? (attachements the most recent stderr and stdout) Unfortunately, I am no Kerberos specialist and cannot tell you what the messages in the log really mean. But the following (from the stderr) should probably be investigated further : >>>KRBError: sTime is Tue Sep 03 11:47:29 CEST 2019 1567504049000 suSec is 329207 error code is 25 error Message is Additional pre-authentication required sname is krbtgt/u4agr@u4agr.com eData provided. msgType is 30 That seems to indicate that something is not working as expected, at the Kerberos level. Note : why it would work with tomcat8 and not with tomcat9 is still not clear to me, unless there have been some changes between the tomcat8 SPNEGO Valve and the tomcat9 SPNGEGO Valve, or else maybe in terms of the tomcat hostname considerations. I know off Fiddler2 but never used it before, I will try to set that up... Met vriendelijke groeten van Heidi Leerink - Duverger Technisch Consultant In business for people. Unit4 Business Software Netherlands B.V. Papendorpseweg 100, 3710 BJ Utrecht, Netherlands T +31 88 247 1444 E heidi.duver...@unit4.com This message and any attachment(s) are intended only for the use of the named recipient and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient, please notify the sender by return e-mail and delete this message from your system. Do not disclose the contents of this document to any other persons. Violation of this notice may be unlawful. Please note that internet communications are not secure and e-mails are susceptible to change. Thank you for your cooperation. -Original Message- From: André Warnier (tomcat) [mailto:a...@ice-sa.com] Sent: dinsdag 3 september 2019 10:39 To: users@tomcat.apache.org Subject: Re: SSO fails on Tomcat 9 Hello Heidi. Thank you for the complete information provided in your post below. I do not have any experience with the Tomcat SPNEGO Valve per se, but quite a bit of experience with Windows Integrated Authentication. To me, the symptoms that you describe below, do not really look like a problem at the Tomcat level, but more like a problem between the browser and the Windows authentication in general. See notes and questions in the text below. On 02.09.2019 12:35, Heidi Leerink - Duverger wrote: We have the following problem with connecting from the tomcat environment 9.024 with the Active Directory of Windows, Kerberos database. (win2008 DC's) In Tomcat's log files, with Tomcat8, which gives no problems, it is connected to the Act
RE: SSO fails on Tomcat 9
Hello Alex,
Thank you for the extensive answer.
Q1: Are you sure that it is *exactly* the same ?
Yes the installation is done on the same PC with the same user principal for
the Tomcat service to log in .
The Tomcat 8 service is stopped during the Tomcat 9 test.
We had the exact same problem when installing in a test environment at one of
our Customer sites. Most of our customers that are using SSO with our
application are still using Tomcat 8 with no problems and all with the same
spnego config.
My colleague initially set up this Tomcat 9 installation using a few tomcat 9
versions ( .8 .20 and .24). I myself, reinstalled and configured Tomcat 9.024
from scratch, with no success and always the same results.
Q2: when "it does not work", does the browser popup a login dialog ?
Yes I have seen that one be not with the recent config.
Browser response :
Google Chrome
This site can't be reachedThe webpage at http://nlsl-decadetst:8787/apex42a/
might be temporarily down or it may have moved permanently to a new web address.
ERR_INVALID_RESPONSE
Internet Explorer 11:
Can't reach this page
.Make sure the web address http://nlsl-decadetst:8787 is correct
.Search for this site on Bing
.Refresh the page
More information More information
The connection to the website was reset.
Error Code: INET_E_DOWNLOAD_FAILURE
(attachements the most recent stderr and stdout)
I know off Fiddler2 but never used it before, I will try to set that up...
Met vriendelijke groeten van
Heidi Leerink - Duverger
Technisch Consultant
In business for people.
Unit4 Business Software Netherlands B.V.
Papendorpseweg 100, 3710 BJ Utrecht, Netherlands
T +31 88 247 1444
E heidi.duver...@unit4.com
This message and any attachment(s) are intended only for the use of the named
recipient and may contain information that is privileged, confidential or
otherwise exempt from disclosure under applicable law. If you are not the
intended recipient, please notify the sender by return e-mail and delete this
message from your system. Do not disclose the contents of this document to any
other persons. Violation of this notice may be unlawful. Please note that
internet communications are not secure and e-mails are susceptible to change.
Thank you for your cooperation.
-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: dinsdag 3 september 2019 10:39
To: users@tomcat.apache.org
Subject: Re: SSO fails on Tomcat 9
Hello Heidi.
Thank you for the complete information provided in your post below.
I do not have any experience with the Tomcat SPNEGO Valve per se, but quite a
bit of experience with Windows Integrated Authentication.
To me, the symptoms that you describe below, do not really look like a problem
at the Tomcat level, but more like a problem between the browser and the
Windows authentication in general.
See notes and questions in the text below.
On 02.09.2019 12:35, Heidi Leerink - Duverger wrote:
> We have the following problem with connecting from the tomcat
> environment 9.024 with the Active Directory of Windows, Kerberos
> database. (win2008 DC's)
>
> In Tomcat's log files, with Tomcat8, which gives no problems, it is
> connected to the Active directory.
>
> It indicates that a login attempt is made 3 times whether the person
> can log in with the Active directory account.
>
> After that the login is accepted and qualified as successful.
>
> In tomcat 9, different versions tried, also version 9.024, the control
> of 1 attempt becomes visible,
>
> which is successful. But then the check is stopped (not 3 times as
> Tomcat8) and the connection is marked as unsuccessful.
>
> The environment for Tomcat9 is the same as from Tomcat8.
Q1: Are you sure that it is *exactly* the same ?
For example, do the tomcat8 installation, and the tomcat9 installation, run on
the same server, and is the server *domain* the same in both cases ?
Q2: when "it does not work", does the browser popup a login dialog ?
Reason for the questions :
Typically, a succesful Windows authentication consists of indeed 3 exchanges
(what you say happens with tomcat8).
The first of these exchanges consists of the browser requesting the original
URL.
The server then responds with a 401 response ("need authentication"), in which
it indicates that it wants an authentication, of the SPNEGO type.
The browser then normally responds with a 2d request for the same URL,
containing a partial "Authorization:" header containing some encrypted token.
If the browser does NOT send this 2d request, it indicates that *the browser
refuses* to do an SPNEGO authentication in this case.
And that happens when the browser does not think that the server "can be
trusted" for doing SPNEGO authentication.
The browser will not trust the server, if it thinks that the server is not in
the same domain as itse
Re: SSO fails on Tomcat 9
Hello Heidi.
Thank you for the complete information provided in your post below.
I do not have any experience with the Tomcat SPNEGO Valve per se, but quite a bit of
experience with Windows Integrated Authentication.
To me, the symptoms that you describe below, do not really look like a problem at the
Tomcat level, but more like a problem between the browser and the Windows authentication
in general.
See notes and questions in the text below.
On 02.09.2019 12:35, Heidi Leerink - Duverger wrote:
We have the following problem with connecting from the tomcat environment 9.024
with the
Active Directory of Windows, Kerberos database. (win2008 DC's)
In Tomcat's log files, with Tomcat8, which gives no problems, it is connected
to the
Active directory.
It indicates that a login attempt is made 3 times whether the person can log in
with the
Active directory account.
After that the login is accepted and qualified as successful.
In tomcat 9, different versions tried, also version 9.024, the control of 1
attempt
becomes visible,
which is successful. But then the check is stopped (not 3 times as Tomcat8) and
the
connection is marked as unsuccessful.
The environment for Tomcat9 is the same as from Tomcat8.
Q1: Are you sure that it is *exactly* the same ?
For example, do the tomcat8 installation, and the tomcat9 installation, run on the same
server, and is the server *domain* the same in both cases ?
Q2: when "it does not work", does the browser popup a login dialog ?
Reason for the questions :
Typically, a succesful Windows authentication consists of indeed 3 exchanges (what you say
happens with tomcat8).
The first of these exchanges consists of the browser requesting the original
URL.
The server then responds with a 401 response ("need authentication"), in which it
indicates that it wants an authentication, of the SPNEGO type.
The browser then normally responds with a 2d request for the same URL, containing a
partial "Authorization:" header containing some encrypted token.
If the browser does NOT send this 2d request, it indicates that *the browser refuses* to
do an SPNEGO authentication in this case.
And that happens when the browser does not think that the server "can be trusted" for
doing SPNEGO authentication.
The browser will not trust the server, if it thinks that the server is not in the same
domain as itself (unless you have manually added this server in the "trusted servers", at
the browser level).
Q2: Usually, when the browser refuses to do a WIA authentication, it tries a Basic
authentication instead, and this login dialog pops up. With Windows authentication, that
is usually the first sign that something is not correct in the browser/server setup.
Note: I'm not saying that this IS your problem. But it is the first thing to verify, with
WIA authentication.
To see this more clearly, you could try to install on the workstation, some software that
allows you to trace the HTTP exchanges between the browser and the server (example :
Fiddler2), and compare what happens with tomcat8 and tomcat9 (look at the HTTP headers for
request/response).
Windows 10 PRO
Oracle database rdbms 11.203
Apex 4.2.3.008
Ords2019 - Oracle listener
ojdbc6.jar
Tried both java versions:
E:\java\jre64b\bin>java -version
java version "1.8.0_202"
Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)
And
E:\java\openjdk\bin>java -version
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
Tomcat 9.024 directory structure.
( log files in the attachments )
e:\Tomcat9\
\Cataline\localhost\apex42a.xml
+++...+++
+++...+++
\conf\jaas.conf
+++...+++
APEX42A {
com.sun.security.auth.module.Krb5LoginModule required
doNotPrompt=true
principal="HTTP/nlsl-decadetst.u4agr@u4agr.com"
useKeyTab=true
keyTab="E:/Decade_appl/Tomcat9/conf/tomcat.keytab"
storeKey=true;
};
+++...+++
\conf\krb5.ini
+++...+++
[libdefaults]
default_realm= U4AGR.COM
default_tkt_enctypes = rc4-hmac aes256-cts-hmac-sha1-96
aes128-cts-hmac-sha1-96
default_tgs_enctypes = rc4-hmac aes256-cts-hmac-sha1-96
aes128-cts-hmac-sha1-96
permitted_enctypes = rc4-hmac aes256-cts-hmac-sha1-96
aes128-cts-hmac-sha1-96
dns_lookup_kdc = true
dns_lookup_relam = false
[realms]
U4AGR.COM = {
kdc = u4agr.com
default_domain = U4AGR.COM
}
[domain_realm]
.u4agr.com= U4AGR.COM
u4agr.com= U4AGR.COM
+++...+++
\conf\tomcat.keytab
Creation statement for tomcat.keytab:
ktpass /out c:\Temp\tomcat.keytab /mapuser DECADE_SSO_TC.U4AGR.COM /princ
HTTP/nlsl-decadetst.u4agr@u4agr.com /pass "D3cad3401" /kvno 0 -ptype
KRB5_NT_PRINCIPAL
ktpass /out c:\temp\1c-tomcat.keytab /mapuser DECADE_SSO_TC.U4AGR.COM /princ
HTTP/nlsl-decadetst.u4agr
Re: sso integration with tomcat
On 07/07/2014 12:02, Randeep wrote: > Hi all, > > We are trying to implement a single sign on tool with our website. > > Our architecture is as follows. > > httpd 2.2 (front end) + mod_jk + apache_tomcat 7.0.53 (back end) > we have 5 web applications in the webapps > we are using centos 5.4 > > We are currently testing with josso. (if you know something better please > let me know) Don't know if it is better, but quite a few of the SSO deployments I have come across have used CAS: http://www.jasig.org/cas You might want to try the JOSSO support forum. Mark > we are testing with josso's inbuilt sample app. > in tomcat/lib/*josso-gateway-stores.xml* > I have configured as follows. > > id="josso-identity-store" > driverName="com.mysql.jdbc.Driver" > connectionURL="jdbc:mysql:// > stagingxyz.us-east-1.rds.amazonaws.com:3306/josso" > connectionName="root" > connectionPassword="abcde" > userQueryString="SELECT LOGIN AS NAME FROM JOSSO_USER WHERE > LOGIN = ?" > rolesQueryString="SELECT NAME AS ROLE FROM JOSSO_USER_ROLE > WHERE LOGIN = ?" > credentialsQueryString="SELECT LOGIN AS USERNAME, PASSWORD FROM > JOSSO_USER WHERE LOGIN = ?" > userPropertiesQueryString="SELECT NAME, VALUE FROM > JOSSO_USER_PROPERTY WHERE LOGIN = ?" > resetCredentialDml="UPDATE JOSSO_USER SET PASSWORD = ? WHERE > LOGIN = ?" > relayCredentialQueryString="SELECT LOGIN FROM JOSSO_USER WHERE > #?# = ?" > certificateCredentialsQueryString="SELECT CERTIFICATE AS > USERCERTIFICATE FROM JOSSO_USER_CERTIFICATE WHERE CN = ?" > uidQueryString="SELECT LOGIN FROM > JOSSO_USER_CERTIFICATE WHERE CERTIFICATE = ?" > /> > > But I can see db-sstore and db-astore do I need to configure these too? I > have followed this tutorial > http://www.josso.org/confluence/display/JOSSO1/Database+Setup > > it doesnt have schema for session and other tables. > > in josso-gateway-config.xml > I have added > > > > > as we are using plain text for testing I have configured > *josso-gateway-auth.xml > as follows:* > id="josso-basic-authentication" > ignorePasswordCase="false" > ignoreUserCase="false"> > > but the problem is when we try to login using the partner app(In this > parter app i have configured web.xml and redirect pages accordingly) > it is not taking the credentials from the database. it is taking the > default ones only. > > Kindly advice. > Please let me know if I have to provide any other details. > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Brosh, On 3/23/14, 3:37 AM, Brosh, Yossi wrote: > I am trying to install SSO on Linux machine with Tomcat in order > to working with Jenkins without the needed to login, any idea ? Lots of ideas. What have you tried so far? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTL184AAoJEBzwKT+lPKRYMNYP/RgB+ww/MvukT83n0IcA6Y27 Plzqcoii26RwgFXsa3UniobRn7mrAxp4VW0yAG89oLRnk3dyo0NSwDP8HghhisY7 SYA/6ruwF6ovG6MQeKWiTj2yP/zcxcT3r1oGuB7WNhexWS+9PawiiXak+1oCl5gj MTv/PC2yuDqSb/4EKltGxTgF2mLeKNHRR3GemdmJSJe5ZxuoHoUYhPBlnOaPl/Az zwjQcHPeo45gjfW1CIMlAnzxBwioJoG5DduoP+P0FCxq72rG8xeWzAjH8tHAoeoo HbtmirNKnNF++Tl6+kG0osfSYfCzTqEuc7/3LMRxv1auAU7BQoFxNhfIFh2L0JWD bL838HjGoUg/OPxApQQE4dzadlrdNPFI/rJa9UYVAvoTTvKHGY+7yR+ewKbK0zpo tsXAXdJ63GAagcmzSLWdcpa5HQBTyG1XZ8fZ6DNgDHsRn4/53UZGYzWSw5pk2ls0 ZeGh8fM7yl4JD56A6co/6fRiMK+bV5XGZkoJ6xBR2Xc+7S66tjWdn2yXu18swzYo JuM3vGdLuUoS4Bl87dbrVHoc4AjCHdV5lRSjbWk0PYAwFp+j29DKuknFBYsCIkZi JQRPVQLvkTt/B+CwAeB0nzDNOAheIV4Vnt3P40v+UkMGCDI2MWvHoz4YLRyVM4uQ f2ClUpfmIkl5gzuFv6X/ =YRZA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSO
When you say Linux I assume you are implementing "Red Hat Enterprise Linux SSO" https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/sso-ov.html Martin __ Please do not alter or disrupt this email transmission...Thank You > From: yossi.br...@sap.com > To: users@tomcat.apache.org > Subject: SSO > Date: Sun, 23 Mar 2014 07:37:41 + > > > Hi to all , > > I am trying to install SSO on Linux machine with Tomcat in order to working > with Jenkins without the needed to login, any idea ? > > Thanks a lot , > Yos >
Re: SSO
Brosh, Yossi wrote: Hi to all , I am trying to install SSO on Linux machine with Tomcat in order to working with Jenkins without the needed to login, any idea ? http://www.catb.org/esr/faqs/smart-questions.html ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSO session replication within TC 5.5.23 cluster
you sure can, there is a single sign on valve, you would have to change
the code for that one
filip
ROOKIE wrote:
Hi Filip,
I had posted earlier and u had confirmed that SSO replication is not complete.
I would like to know if there is a way by which I can edit the SSO cookie generated by tomcat to also contain jvmRoute (mentioned in Engine node in server.xml) so that my load balancer rewrites my SSO sessions directly to the correct cluster member.
Thanks,
Vinod
- Original Message
From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
To: Tomcat Users List
Sent: Tuesday, August 7, 2007 9:40:04 PM
Subject: Re: SSO session replication within TC 5.5.23 cluster
I'm not sure the replicated SSO cookie implementation ever was
completed, I think it was abandoned before it reached a functional stage
Filip
ROOKIE wrote:
Hi,
I have a problem with tomcat cluster + mod_proxy load balancer :
We have a main app which authenticate itself to a webapp and from this app one
can launch embedded apps which use the SSO cookie to access other webapps on
the server (Single-Sign-On for the user).
Things are working perfectly for the normal cookie but not for the sso cookie.
The problem I have is that tomcat does not replicate SSO sessions so when these embedded apps route through the load balancer we get 401s on all the other cluster members except the one which actually generated the SSO cookie.
I wanted to know if we can edit the SSO cookie generated by tomcat to also
contain the jvmRoute parameter so that the load balancer directly goes to the
correct cluster member.
I tried doing this in my code by fetching the SSO cookie and appending to it
the jvmRoute as follows :
HttpServletRequest request =
(HttpServletRequest)Security.getContext(HttpServletRequest.class);
HttpServletResponse response =
(HttpServletResponse)Security.getContext(HttpServletResponse.class);
if(request != null) {
String jvmRoute = "Vinod_Cluster_1";// as mentioned in
server.xml
Cookie[] cookies = request.getCookies();
for(int nc=0; cookies != null && nc < cookies.length; nc++) {
if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
_sessionId = cookies[nc].getValue();
}
else
if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
_ssoSessionId = cookies[nc].getValue();
if (!_ssoSessionId.contains("." + jvmRoute)) {
_ssoSessionId += "." + jvmRoute;
response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
}
}
But after this I started getting 401s from even the correct cluster member. My guess is addCookie doesnt update the cookie in tomcat's cache which is reasonable.
Other thought was to edit tomcat's sso cookie generation code to append the
jvmRoute to the sso cookie.
Is there an better way to achieve this in my code base ?
Thanks In Advance,
Vinod
- Original Message
From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
To: Tomcat Users List
Sent: Wednesday, May 30, 2007 2:49:59 PM
Subject: Re: SSO session replication within TC 5.5.23 cluster
It was contributed but never completed, so it is not working properly
Filip
ROOKIE wrote:
Hi,
Can someone please clarify if tomcat 5.5 supports replication of single-sign-on
sessions across cluster members, if so how to configure it ?
Thanks,
Vinod
- Original Message
From: ROOKIE <[EMAIL PROTECTED]>
To: users@tomcat.apache.org
Sent: Tuesday, May 29, 2007 5:20:03 PM
Subject: SSO session replication within TC 5.5.23 cluster
Hi,
I have created a simple TCP cluster of 2 TC 5.5.23 servers and added a Apache
2.2 (mod_proxy) load balancer in front. Our tomcat has SSO valve enabled.
I wanted to know if TC 5.5.23 supports SSO session replication ?
Googling tells me that a patch was submitted for this,
http://fabien.carrion.free.fr/TomcatCluster.html and even the
catalina-cluster.jar has the ClusterSingleSignOn valve. But TC mailing lists
suggest that the support is still not complete.
In any case I have not been able to get it working.
Whenever I use the SSO cookie for authentication I get 401 from all the other cluster members (except the one who generated the SSO session id).
The requested resource is protected and the UserPrincipal found in the
HttpRequest by the other cluster members is null. I use a customized NTLM
authenticator which expects a non-null UserPrincipal in the HttpRequest if user
is already authenticated.
Following is my cluster node in server.xml (embedded in Host node) :
className="org.apache.catalina.cluster.mcast.McastService"
Re: SSO session replication within TC 5.5.23 cluster
Hi Filip,
I had posted earlier and u had confirmed that SSO replication is not complete.
I would like to know if there is a way by which I can edit the SSO cookie
generated by tomcat to also contain jvmRoute (mentioned in Engine node in
server.xml) so that my load balancer rewrites my SSO sessions directly to the
correct cluster member.
Thanks,
Vinod
- Original Message
From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
To: Tomcat Users List
Sent: Tuesday, August 7, 2007 9:40:04 PM
Subject: Re: SSO session replication within TC 5.5.23 cluster
I'm not sure the replicated SSO cookie implementation ever was
completed, I think it was abandoned before it reached a functional stage
Filip
ROOKIE wrote:
> Hi,
> I have a problem with tomcat cluster + mod_proxy load balancer :
>
> We have a main app which authenticate itself to a webapp and from this app
> one can launch embedded apps which use the SSO cookie to access other webapps
> on the server (Single-Sign-On for the user).
>
> Things are working perfectly for the normal cookie but not for the sso cookie.
>
> The problem I have is that tomcat does not replicate SSO sessions so when
> these embedded apps route through the load balancer we get 401s on all the
> other cluster members except the one which actually generated the SSO cookie.
>
> I wanted to know if we can edit the SSO cookie generated by tomcat to also
> contain the jvmRoute parameter so that the load balancer directly goes to the
> correct cluster member.
>
>
> I tried doing this in my code by fetching the SSO cookie and appending to it
> the jvmRoute as follows :
>
> HttpServletRequest request =
> (HttpServletRequest)Security.getContext(HttpServletRequest.class);
> HttpServletResponse response =
> (HttpServletResponse)Security.getContext(HttpServletResponse.class);
> if(request != null) {
> String jvmRoute = "Vinod_Cluster_1";// as mentioned in
> server.xml
> Cookie[] cookies = request.getCookies();
> for(int nc=0; cookies != null && nc < cookies.length; nc++) {
> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
> _sessionId = cookies[nc].getValue();
> }
> else
> if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
> _ssoSessionId = cookies[nc].getValue();
> if (!_ssoSessionId.contains("." + jvmRoute)) {
> _ssoSessionId += "." + jvmRoute;
> response.addCookie(new
> Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
> }
>
> }
>
> But after this I started getting 401s from even the correct cluster member.
> My guess is addCookie doesnt update the cookie in tomcat's cache which is
> reasonable.
>
> Other thought was to edit tomcat's sso cookie generation code to append the
> jvmRoute to the sso cookie.
>
> Is there an better way to achieve this in my code base ?
>
> Thanks In Advance,
> Vinod
> - Original Message
> From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
> To: Tomcat Users List
> Sent: Wednesday, May 30, 2007 2:49:59 PM
> Subject: Re: SSO session replication within TC 5.5.23 cluster
>
> It was contributed but never completed, so it is not working properly
>
> Filip
>
> ROOKIE wrote:
>
>> Hi,
>> Can someone please clarify if tomcat 5.5 supports replication of
>> single-sign-on sessions across cluster members, if so how to configure it ?
>>
>> Thanks,
>> Vinod
>>
>> - Original Message
>> From: ROOKIE <[EMAIL PROTECTED]>
>> To: users@tomcat.apache.org
>> Sent: Tuesday, May 29, 2007 5:20:03 PM
>> Subject: SSO session replication within TC 5.5.23 cluster
>>
>> Hi,
>>
>> I have created a simple TCP cluster of 2 TC 5.5.23 servers and added a
>> Apache 2.2 (mod_proxy) load balancer in front. Our tomcat has SSO valve
>> enabled.
>>
>> I wanted to know if TC 5.5.23 supports SSO session replication ?
>>
>> Googling tells me that a patch was submitted for this,
>> http://fabien.carrion.free.fr/TomcatCluster.html and even the
>> catalina-cluster.jar has the ClusterSingleSignOn valve. But TC mailing lists
>> suggest that the support is still not complete.
>>
>> In any case I have not been able to get it working.
>>
>> Whenever I use the SSO cookie for authentication I get 401 from all the
>> other cluster members (except the one who generated the
Re: SSO session replication within TC 5.5.23 cluster
I'm not sure the replicated SSO cookie implementation ever was
completed, I think it was abandoned before it reached a functional stage
Filip
ROOKIE wrote:
Hi,
I have a problem with tomcat cluster + mod_proxy load balancer :
We have a main app which authenticate itself to a webapp and from this app one
can launch embedded apps which use the SSO cookie to access other webapps on
the server (Single-Sign-On for the user).
Things are working perfectly for the normal cookie but not for the sso cookie.
The problem I have is that tomcat does not replicate SSO sessions so when these embedded apps route through the load balancer we get 401s on all the other cluster members except the one which actually generated the SSO cookie.
I wanted to know if we can edit the SSO cookie generated by tomcat to also
contain the jvmRoute parameter so that the load balancer directly goes to the
correct cluster member.
I tried doing this in my code by fetching the SSO cookie and appending to it
the jvmRoute as follows :
HttpServletRequest request =
(HttpServletRequest)Security.getContext(HttpServletRequest.class);
HttpServletResponse response =
(HttpServletResponse)Security.getContext(HttpServletResponse.class);
if(request != null) {
String jvmRoute = "Vinod_Cluster_1";// as mentioned in
server.xml
Cookie[] cookies = request.getCookies();
for(int nc=0; cookies != null && nc < cookies.length; nc++) {
if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
_sessionId = cookies[nc].getValue();
}
else
if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
_ssoSessionId = cookies[nc].getValue();
if (!_ssoSessionId.contains("." + jvmRoute)) {
_ssoSessionId += "." + jvmRoute;
response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId));
}
}
But after this I started getting 401s from even the correct cluster member. My guess is addCookie doesnt update the cookie in tomcat's cache which is reasonable.
Other thought was to edit tomcat's sso cookie generation code to append the
jvmRoute to the sso cookie.
Is there an better way to achieve this in my code base ?
Thanks In Advance,
Vinod
- Original Message
From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
To: Tomcat Users List
Sent: Wednesday, May 30, 2007 2:49:59 PM
Subject: Re: SSO session replication within TC 5.5.23 cluster
It was contributed but never completed, so it is not working properly
Filip
ROOKIE wrote:
Hi,
Can someone please clarify if tomcat 5.5 supports replication of single-sign-on
sessions across cluster members, if so how to configure it ?
Thanks,
Vinod
- Original Message
From: ROOKIE <[EMAIL PROTECTED]>
To: users@tomcat.apache.org
Sent: Tuesday, May 29, 2007 5:20:03 PM
Subject: SSO session replication within TC 5.5.23 cluster
Hi,
I have created a simple TCP cluster of 2 TC 5.5.23 servers and added a Apache
2.2 (mod_proxy) load balancer in front. Our tomcat has SSO valve enabled.
I wanted to know if TC 5.5.23 supports SSO session replication ?
Googling tells me that a patch was submitted for this,
http://fabien.carrion.free.fr/TomcatCluster.html and even the
catalina-cluster.jar has the ClusterSingleSignOn valve. But TC mailing lists
suggest that the support is still not complete.
In any case I have not been able to get it working.
Whenever I use the SSO cookie for authentication I get 401 from all the other cluster members (except the one who generated the SSO session id).
The requested resource is protected and the UserPrincipal found in the
HttpRequest by the other cluster members is null. I use a customized NTLM
authenticator which expects a non-null UserPrincipal in the HttpRequest if user
is already authenticated.
Following is my cluster node in server.xml (embedded in Host node) :
className="org.apache.catalina.cluster.mcast.McastService"
mcastAddr="228.0.0.4"
mcastPort="45564"
mcastFrequency="500"
mcastDropTime="3000"/>
className="org.apache.catalina.cluster.tcp.ReplicationListener"
tcpListenAddress="auto"
tcpListenPort="4002"
tcpSelectorTimeout="100"
tcpThreadCount="4"/>
Any ideas why SSO session replication is not working, is it a configuration
error or does TC 5.5.23 not support this.
TIA,
Vi
Re: SSO session replication within TC 5.5.23 cluster
Hi,
I have a problem with tomcat cluster + mod_proxy load balancer :
We have a main app which authenticate itself to a webapp and from this app one
can launch embedded apps which use the SSO cookie to access other webapps on
the server (Single-Sign-On for the user).
Things are working perfectly for the normal cookie but not for the sso cookie.
The problem I have is that tomcat does not replicate SSO sessions so when these
embedded apps route through the load balancer we get 401s on all the other
cluster members except the one which actually generated the SSO cookie.
I wanted to know if we can edit the SSO cookie generated by tomcat to also
contain the jvmRoute parameter so that the load balancer directly goes to the
correct cluster member.
I tried doing this in my code by fetching the SSO cookie and appending to it
the jvmRoute as follows :
HttpServletRequest request =
(HttpServletRequest)Security.getContext(HttpServletRequest.class);
HttpServletResponse response =
(HttpServletResponse)Security.getContext(HttpServletResponse.class);
if(request != null) {
String jvmRoute = "Vinod_Cluster_1";// as mentioned in
server.xml
Cookie[] cookies = request.getCookies();
for(int nc=0; cookies != null && nc < cookies.length; nc++) {
if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
_sessionId = cookies[nc].getValue();
}
else
if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) {
_ssoSessionId = cookies[nc].getValue();
if (!_ssoSessionId.contains("." + jvmRoute)) {
_ssoSessionId += "." + jvmRoute;
response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME,
_ssoSessionId));
}
}
But after this I started getting 401s from even the correct cluster member. My
guess is addCookie doesnt update the cookie in tomcat's cache which is
reasonable.
Other thought was to edit tomcat's sso cookie generation code to append the
jvmRoute to the sso cookie.
Is there an better way to achieve this in my code base ?
Thanks In Advance,
Vinod
- Original Message
From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
To: Tomcat Users List
Sent: Wednesday, May 30, 2007 2:49:59 PM
Subject: Re: SSO session replication within TC 5.5.23 cluster
It was contributed but never completed, so it is not working properly
Filip
ROOKIE wrote:
> Hi,
> Can someone please clarify if tomcat 5.5 supports replication of
> single-sign-on sessions across cluster members, if so how to configure it ?
>
> Thanks,
> Vinod
>
> - Original Message
> From: ROOKIE <[EMAIL PROTECTED]>
> To: users@tomcat.apache.org
> Sent: Tuesday, May 29, 2007 5:20:03 PM
> Subject: SSO session replication within TC 5.5.23 cluster
>
> Hi,
>
> I have created a simple TCP cluster of 2 TC 5.5.23 servers and added a Apache
> 2.2 (mod_proxy) load balancer in front. Our tomcat has SSO valve enabled.
>
> I wanted to know if TC 5.5.23 supports SSO session replication ?
>
> Googling tells me that a patch was submitted for this,
> http://fabien.carrion.free.fr/TomcatCluster.html and even the
> catalina-cluster.jar has the ClusterSingleSignOn valve. But TC mailing lists
> suggest that the support is still not complete.
>
> In any case I have not been able to get it working.
>
> Whenever I use the SSO cookie for authentication I get 401 from all the other
> cluster members (except the one who generated the SSO session id).
>
> The requested resource is protected and the UserPrincipal found in the
> HttpRequest by the other cluster members is null. I use a customized NTLM
> authenticator which expects a non-null UserPrincipal in the HttpRequest if
> user is already authenticated.
>
> Following is my cluster node in server.xml (embedded in Host node) :
>
> clusterName="rooksCluster"
>
> managerClassName="org.apache.catalina.cluster.session.DeltaManager"
> expireSessionsOnShutdown="false"
> useDirtyFlag="true"
> notifyListenersOnReplication="true">
>
>
> className="org.apache.catalina.cluster.mcast.McastService"
> mcastAddr="228.0.0.4"
> mcastPort="45564"
> mcastFrequency="500"
> mcastDropTime="3000"/>
>
>
> className="org.apache.catalina.cluster.tcp.ReplicationListener"
> tcpListenAddress=&qu
Re: SSO session replication within TC 5.5.23 cluster
It was contributed but never completed, so it is not working properly Filip ROOKIE wrote: Hi, Can someone please clarify if tomcat 5.5 supports replication of single-sign-on sessions across cluster members, if so how to configure it ? Thanks, Vinod - Original Message From: ROOKIE <[EMAIL PROTECTED]> To: users@tomcat.apache.org Sent: Tuesday, May 29, 2007 5:20:03 PM Subject: SSO session replication within TC 5.5.23 cluster Hi, I have created a simple TCP cluster of 2 TC 5.5.23 servers and added a Apache 2.2 (mod_proxy) load balancer in front. Our tomcat has SSO valve enabled. I wanted to know if TC 5.5.23 supports SSO session replication ? Googling tells me that a patch was submitted for this, http://fabien.carrion.free.fr/TomcatCluster.html and even the catalina-cluster.jar has the ClusterSingleSignOn valve. But TC mailing lists suggest that the support is still not complete. In any case I have not been able to get it working. Whenever I use the SSO cookie for authentication I get 401 from all the other cluster members (except the one who generated the SSO session id). The requested resource is protected and the UserPrincipal found in the HttpRequest by the other cluster members is null. I use a customized NTLM authenticator which expects a non-null UserPrincipal in the HttpRequest if user is already authenticated. Following is my cluster node in server.xml (embedded in Host node) : className="org.apache.catalina.cluster.mcast.McastService" mcastAddr="228.0.0.4" mcastPort="45564" mcastFrequency="500" mcastDropTime="3000"/> className="org.apache.catalina.cluster.tcp.ReplicationListener" tcpListenAddress="auto" tcpListenPort="4002" tcpSelectorTimeout="100" tcpThreadCount="4"/> Any ideas why SSO session replication is not working, is it a configuration error or does TC 5.5.23 not support this. TIA, Vinod Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSO session replication within TC 5.5.23 cluster
Hi, Can someone please clarify if tomcat 5.5 supports replication of single-sign-on sessions across cluster members, if so how to configure it ? Thanks, Vinod - Original Message From: ROOKIE <[EMAIL PROTECTED]> To: users@tomcat.apache.org Sent: Tuesday, May 29, 2007 5:20:03 PM Subject: SSO session replication within TC 5.5.23 cluster Hi, I have created a simple TCP cluster of 2 TC 5.5.23 servers and added a Apache 2.2 (mod_proxy) load balancer in front. Our tomcat has SSO valve enabled. I wanted to know if TC 5.5.23 supports SSO session replication ? Googling tells me that a patch was submitted for this, http://fabien.carrion.free.fr/TomcatCluster.html and even the catalina-cluster.jar has the ClusterSingleSignOn valve. But TC mailing lists suggest that the support is still not complete. In any case I have not been able to get it working. Whenever I use the SSO cookie for authentication I get 401 from all the other cluster members (except the one who generated the SSO session id). The requested resource is protected and the UserPrincipal found in the HttpRequest by the other cluster members is null. I use a customized NTLM authenticator which expects a non-null UserPrincipal in the HttpRequest if user is already authenticated. Following is my cluster node in server.xml (embedded in Host node) : Any ideas why SSO session replication is not working, is it a configuration error or does TC 5.5.23 not support this. TIA, Vinod Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSO ID in the first request
Hi Fredrik, > > HttpSession session = .; > session.setAttribute(String nameOfYourObject, Object yourObject); > Object yourObject = session.getAttribute(String nameOfYourObject); Surely, this cannot be correct? It would take me some effort to try sharing attributes between webapps, so I can't try it immediately, but different webapps even set different session cookies (JSESSIONID, that is) to the client, so it is very hard for me to believe that all webapps are sharing the same session. Sure they do, we're doing it here, and it's pretty easy to implement. However, to make all webapps using the same JSSOSessionID, you have to enable the SingleSignOn-valve in your server.xml: This ensures that all webapps share the same session. Cheers Greg -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSO ID in the first request
On Tue, 2007-03-13 at 19:34 +0100, Gregor Schneider wrote: > I guess you're talking about JSSOSessionID-Cookie, right? Indeed. > I believe the whole design is not too smart: > > Since all webapps are sharing the same session, I'd store the needed > values as session-attributes (too lazy to look it up right now, but > should work like > > HttpSession session = .; > session.setAttribute(String nameOfYourObject, Object yourObject); > Object yourObject = session.getAttribute(String nameOfYourObject); Surely, this cannot be correct? It would take me some effort to try sharing attributes between webapps, so I can't try it immediately, but different webapps even set different session cookies (JSESSIONID, that is) to the client, so it is very hard for me to believe that all webapps are sharing the same session. In any event, though, it isn't so much about sharing data. We have one webapp that produces a common header for all pages, and the others fetch that header through an HTTP GET call. > However, this works only when running all your webapps within the same > Tomcat-instance. > If this is not the case, take a look at webservices. Thanks for the tip, but I think any SSO hack would be far easier to implement and maintain than starting to use web services. Fredrik Tolf - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSO ID in the first request
I guess you're talking about JSSOSessionID-Cookie, right? I believe the whole design is not too smart: Since all webapps are sharing the same session, I'd store the needed values as session-attributes (too lazy to look it up right now, but should work like HttpSession session = .; session.setAttribute(String nameOfYourObject, Object yourObject); Object yourObject = session.getAttribute(String nameOfYourObject); However, this works only when running all your webapps within the same Tomcat-instance. If this is not the case, take a look at webservices. HTH Greg -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSO and session security
Mikolaj Rydzewski wrote: > Would it be a problem if I enable single sign-on for the server? Would > my apps overwrite each other's session form-beans? The web application sessions will remain separate. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSO + CLustering
One people in IRC tell me about SSO + Clustering, do you know if this is possible? Sorry I don't have a firsthand experience but I wonder if clustering and SSO are two orthogonal issues... except for scalability ... I found a somewhat rlevant discussion. http://tp.its.yale.edu/pipermail/cas/2006-June/002938.html There was also an interesting article. http://www.infosys.com/industries/banking/white-papers/Linux-SSO.pdf My 2 pence. HTH. Ben K. Developer http://benix.tamu.edu - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SSO - 2 applications in 2 Tomcats - Realm
Concerning the questions on Realm ... I think if you re-read the section http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#JDBCRealm you will find the answer. The names of the tables are not important, they can be specified using the XML attributes userTable and userRoleTable on the Real element. Also the names of the columns are not important, they also can be specified using attributes on the Realm element. Someone else will need to answer the SSO question. HTH - Richard -Original Message- From: Paulo Cheque [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 11:28 AM To: users@tomcat.apache.org Subject: SSO - 2 applications in 2 Tomcats - Realm Hi, I have two applications, each one in a differente machine with its own Tomcat (5.5.x) server. I want to make a SSO to this applications. I've asked in IRC about it and answer me to use SSO + Clusters because Tomcat 5.5.x has a nice support. So, I have to configure: - A Realm - A Valve to SSO - My web.xml right? My problem is that I have already a database and it don't have the table "USER" and another "USER_ROLE" how it is necessary like documentation ( http://tomcat.apache.org/tomcat-5.0-doc/realm-howto.html). Indeed the table of users has to many columns like "date of last access". Have I to make my own Realm to work with this? Thanks in advance. Paulo - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SSO question
>-Original Message- >From: Peter Crowther [mailto:[EMAIL PROTECTED] >Sent: Friday, November 11, 2005 4:20 AM >To: Tomcat Users List >Subject: RE: SSO question > >> From: Klotz Jr, Dennis [mailto:[EMAIL PROTECTED] >> Is it possible using LDAP, whether it is using custom JAAS code or a >> third party product such as Vintela's VSJ >> (http://www.vintela.com/products/vsj/), to do the following: >> >> "... prevent, control or limit the simultaneous active usage >> of the same >> user id. The number of simultaneous active sessions shall be settable >> per user id." >> >> The show stopper for me is whether I can inform the LDAP >> server when the >> user has logged out. The default JNDIRealm does not, to my knowledge, >> provide that ability. JNDIRealm is just for authenticating and role >> retrieval. >You *could* do something like this by storing a custom attribute in LDAP >and incrementing/decrementing that when a user logs in/out. I'm not >sure where it'd get you, though, given users' distressing habits of >closing browsers without logging out of an app and hence leaving the >session open for a period. That sounds like it's come straight out of a >requirements doc. I'd ask who wrote the requirements doc, what's the >business reason behind that requirement, and can it be accomplished >another way? > > - Peter In our case the client is a single applet where we "will" know when the user leaves the page or logs out. Hopefully we will be able to send a message to the server when the applet is being unloaded. You are correct about this coming from a requirements spec and unfortunately the people that wrote it do not know or care whether my code is controlling / preventing the multiple logins or an LDAP server. I'm simply trying to figure out if LDAP servers have that functionality built in. For example, can I specify login limitations for a specific user within an LDAP server such as Active Directory? One co-worker mentioned that Active Directory has no way of limiting logins per "group". For example, if I make a "tomcat" group and assign that to the users LDAP "memberof" attribute, AD has no way of limiting or knowing that a login from a tomcat server is tied to that Group ID and thus limiting the logins. That does make sense to me. What I hope isn't happening is that our marketing people are confusing who is actually doing the work. The main requirement is LDAP integration so that IT doesn't have to manage two different user databases. In addition to that they've been asked to provide this other functionality such as limiting logins etc.. Does that mean we provide tighter integration with LDAP so that the LDAP server can do that job? Or is that something completely out of the scope of a LDAP server and I need to code it on our tomcat server side? If that is the case, that I need to code the per user limit for logging into our tomcat server, am I not defeating the whole purpose of LDAP? Won't I have to maintain another user database on our side to limit per user logins? A person could keep attributes per user that are updated by a JAAS realm but is this how this functionality is typically implemented? That is why I questioned whether LDAP servers have that functionality built in. Any help is greatly appreciated. -Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SSO question
> From: Klotz Jr, Dennis [mailto:[EMAIL PROTECTED] > Is it possible using LDAP, whether it is using custom JAAS code or a > third party product such as Vintela's VSJ > (http://www.vintela.com/products/vsj/), to do the following: > > "... prevent, control or limit the simultaneous active usage > of the same > user id. The number of simultaneous active sessions shall be settable > per user id." > > The show stopper for me is whether I can inform the LDAP > server when the > user has logged out. The default JNDIRealm does not, to my knowledge, > provide that ability. JNDIRealm is just for authenticating and role > retrieval. You *could* do something like this by storing a custom attribute in LDAP and incrementing/decrementing that when a user logs in/out. I'm not sure where it'd get you, though, given users' distressing habits of closing browsers without logging out of an app and hence leaving the session open for a period. That sounds like it's come straight out of a requirements doc. I'd ask who wrote the requirements doc, what's the business reason behind that requirement, and can it be accomplished another way? - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSO with JASS
Hi Abhilash, It is very embryonic but I have implemented the beginnings of a container portable SSO solution including a Tomcat valve.. The source is here.. http://ssso.codehaus.org/ I need to do some more work on the docs though. :-) Regards, Damon. - Original Message - From: "Abhilash Kumar" <[EMAIL PROTECTED]> To: Sent: Wednesday, November 09, 2005 8:28 AM Subject: FW: SSO with JASS Hello: Is there a way in Tomcat to implement SSO with JAAS (instead of using the Valve implementaion of SSO) so that my web app will be portable across containers ? thanks and regards, -- Kannan. -- Amritha Institute of Medical Sciences, Cochin, India Sent using "PostMaster" by QuantumLink Communications One Internet account, unlimited personal e-mail addresses Get your free copy of "PostMaster" at http://www.mailserve.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
