Re: How-to disable SSL V3 on Tomcat 6.0.18.0
On 1/29/2015 10:02 AM, Jammy Chen wrote: Hello Chuck, Thanks for replying, I understood this is old, our product has already upgraded to latest version, but somehow, some of our users are still in such old stage, they do not plan uptake now but they want disable SSL V3 as everybody know this is big security vulnerability. *so now the important thing is how I can disable SSL V3 on Tomcat 6.0.18.0? I cannot find the solution* Jammy 2015-01-29 22:00 GMT+08:00 Caldarale, Charles R : From: Jammy Chen [mailto:jamm...@gmail.com] Subject: How-to disable SSL V3 on Tomcat 6.0.18.0 Do everybody knows how-to disable SSL v3 in older tomcat version Server version: Apache Tomcat/6.0.18 Server built: Jul 22 2008 02:00:36 Yes - move up to a current level and read the docs. Seriously, if you're using a Tomcat of that vintage (this one is more than 6.5 years old), you have a lot more security issues to worry about than SSLv3. It's irresponsible not to upgrade. OS Name:Windows 2003 A few months from end-of-life. JVM Version:1.6.0-b105 Two years past end-of-life. Is there a pattern here? - Chuck Hi, Jammy- I'd suggest downloading Tomcat 6.0.18 which includes the then-current documentation. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FIPS Mode enabling on Tomcat 7.00.057
Thanks Chris! Please find the inline comments from my side On 1/29/15 12:45 AM, Geett Chanddra Singha wrote: > I'm getting the following error when enabling FIPS mode on Apache > Tomcat: > > Jan 28, 2015 5:02:33 PM > org.apache.catalina.core.AprLifecycleListener lifecycleEvent > > SEVERE: Failed to initialize the SSLEngine. > > java.lang.Exception: error:2D06C06E:FIPS > routines:FIPS_mode_set:fingerprint does not match > > at org.apache.tomcat.jni.SSL.fipsModeSet(Native Method) Chris : Looks like your fingerprint doesn't match. Geet: Could you please explain the meaning of the "FIPS_mode_set:fingerprint does not match".It will be helpful for me as I am trying for FIPS mode configuration for the first time. > *Steps I followed to configure: * > > Added the following in server.xml > > > > > > > className="org.apache.catalina.core.AprLifecycleListener" > SSLEngine="on" FIPSMode="on"/> > -- > > 1.)Installing tomcat apr: > > Download from http://apache.mirror.anlx.net/apr/apr-1.5.1.tar.gz Chris :What UNIX are you running? Are you sure you have to build this all yourself? Geett: I am trying on Linux RHEL.6.0_x64. Yes, I got the steps from internet. > tar zxvf apr-1.5.1.tar.gz > > rm apr-1.5.1.tar.gz > > cd apr-1.5.1 * > > sudo ./configure > > sudo make > > sudo make install Chris: Why did you build this as root? Geett: I am trying on Linux RHEL.6.0_x64 test machine. > export LD_LIBRARY_PATH='$LD_LIBRARY_PATH:/usr/local/apr/lib' > > 2.)Installing tomcat tomcat-native: > > Download > > http://apache.bytenet.in/tomcat/tomcat-connectors/native/1.1.32/source/tomcat-native-1.1.32-src.tar.gz > > tar zxvf tomcat-native-1.1.32-src.tar.gz > > rm tomcat-native-1.1.32-src.tar.gz > > cd tomcat-native-1.1.32-src/jni/native > > JAVA_HOME=/usr/lib/jvm/ > > sudo ./configure --with-apr=/usr/local/apr > --with-java-home=$JAVA_HOME > > sudo make > > sudo make install > > > > 3.)Adding the following line > > CATALINA_OPTS="$CATALINA_OPTS > -Djava.library.path=/usr/local/apr/lib" > > 4.) Restarting Tomcat > > Pl > > Please help me resolve this issue and please let me know if i > missed any step. Chris: I didn't see the part where your built OpenSSL with FIPS. Did you do that? Geett: Steps followed to build FIPS tar zxf openssl-1.0.1l.tar.gz cd openssl-1.0.1l ./config --prefix=/usr/local --with-fipsdir=/usr/local/ssl/fips-2.0 make make install Note: I have installed the FIPS module in /usr/local/ssl/fips-2.0 Please suggest me to resolve the issue. Regards, Geett Chanddra Singha On Thu, Jan 29, 2015 at 8:59 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Geett, > > On 1/29/15 12:45 AM, Geett Chanddra Singha wrote: > > I'm getting the following error when enabling FIPS mode on Apache > > Tomcat: > > > > Jan 28, 2015 5:02:33 PM > > org.apache.catalina.core.AprLifecycleListener lifecycleEvent > > > > SEVERE: Failed to initialize the SSLEngine. > > > > java.lang.Exception: error:2D06C06E:FIPS > > routines:FIPS_mode_set:fingerprint does not match > > > > at org.apache.tomcat.jni.SSL.fipsModeSet(Native Method) > > Looks like your fingerprint doesn't match. > > > *Steps I followed to configure: * > > > > Added the following in server.xml > > > > > > > > > > > > > > > className="org.apache.catalina.core.AprLifecycleListener" > > SSLEngine="on" FIPSMode="on"/> > > > -- > > > > 1.)Installing tomcat apr: > > > > Download from http://apache.mirror.anlx.net/apr/apr-1.5.1.tar.gz > > What UNIX are you running? Are you sure you have to build this all > yourself? > > > tar zxvf apr-1.5.1.tar.gz > > > > rm apr-1.5.1.tar.gz > > > > cd apr-1.5.1 * > > > > sudo ./configure > > > > sudo make > > > > sudo make install > > Why did you build this as root? > > > export LD_LIBRARY_PATH='$LD_LIBRARY_PATH:/usr/local/apr/lib' > > > > 2.)Installing tomcat tomcat-native: > > > > Download > > > > > http://apache.bytenet.in/tomcat/tomcat-connectors/native/1.1.32/source/tomcat-native-1.1.32-src.tar.gz > > > > tar zxvf tomcat-native-1.1.32-src.tar.gz > > > > rm tomcat-native-1.1.32-src.tar.gz > > > > cd tomcat-native-1.1.32-src/jni/native > > > > JAVA_HOME=/usr/lib/jvm/ > > > > sudo ./configure --with-apr=/usr/local/apr > > --with-java-home=$JAVA_HOME > > > > sudo make > > > > sudo make install > > > > > > > > 3.)Adding the following line > > > > CATALINA_OPTS="$CATALINA_OPTS > > -Djava.library.path=/usr/local/apr/lib" > > > > 4.) Restarting Tomcat > > > > Pl > > > > Please help me resolve this issue and please let me know if i > > missed any step. > > I didn't see the part where your built OpenSSL with FIPS. Did you do that? > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEB
Re: mod_jk and session stickiness
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rainer,
On 7/23/14 5:14 PM, Christopher Schultz wrote:
> Rainer,
>
> On 7/23/14, 4:10 PM, Rainer Jung wrote:
>> Am 23.07.2014 um 21:03 schrieb Christopher Schultz:
>
>>> On 7/23/14, 1:49 PM, Rainer Jung wrote:
>
The other case, a request with an invalid session ID
accessing a tomcat instance with activation disabled can IMHO
be handled by a filter that
- checks whether the request has a valid session using
getSession(false), if it has one, let the request proceed
- checks activation state, if "active", let the request
proceed
- checks the request method, if not GET, let the request
proceed
- otherwise:
- set the session cookie, e.g. JSESSIONID the an empty value
- issue an external redirect to the same request URL -
optional redirect loop detection: add a query string param or
cookie that gets the local jvmRoute appended during each
redirect. Before doing the redirect, check that the local
jvmRoute is not already part of that token (we have already
been here before)
This would not really interfere with your saved requests:
they would get a redirect which the browser follwos
automatically and after that you will observe the normal
behavior.
>>>
>>> This is exactly what I have implemented -- as a Filter since
>>> we can insert it before SecurityFilter intercepts the requests
>>> -- and my tests suggest that it will work correctly.
>>>
>>> I added code to strip-out any ;jsessionid path parameter from
>>> the URL
>
>> ACK
>
>>> if it exists, but haven't done any of the redirect loop
>>> detection (yet). I think the loop detection is going to have
>>> to keep a running list of visited nodes which, in large
>>> clusters, could grow very large especially if the node names
>>> are long. I'll post my code when it's a little more
>>> featureful.
>
>> As long as nothing goes wrong, the first redirect - having no
>> more session info - should not end up in getting redirected as
>> well, because it should only be send to an active node by mod_jk.
>> So you can even stop redirecting if you detect, that it already
>> happened once. For a large cluster that might be better.
>
>> Multiple might happen (didn't check the code), if all active
>> members are in error state. Even then one would not like to
>> produce many of those redirects for one request, so again, only
>> allowing one redirect might be the right solution.
>
> That's a good thought, and simplifies things. The request
> parameter could then just be a boolean flag and not actually
> identify the node that produced the redirect: any node considering
> redirecting simply would not redirect if that flag had been set.
So, I've implemented all of the above and just given it a real
test-drive in production. It seems to work well on the first shot.
I'll be testing it a bit more as time does on, actually. I also
converted it to a Valve that I will propose to include in Tomcat once
I get some real mileage on it.
I also discovered that I'd like to have a new feature: the ability for
a whitelisted client to ignore the re-balance rules and continue to
contact the server. So, if you have a cluster member called, say,
"foo" and you want to force your way into "foo", you can make a
request to any page with a jsessionid parameter:
http://host/some_page;jsessionid=1234.foo
mod_jk will send you to the "foo" node, even though it is in the
DISABLED state.
Normally, my Filter/Valve would see that you have no valid session
("1234.foo" is not valid) and perform a redirect without the
"jsessionid" path parameter added, thus re-balancing you to another node.
Instead, I've added the ability to configure an "ignore" cookie and
cookie value (like "ignore=SECRETCODE"). If the client presents this
cookie to the Filter/Valve, then it's business as usual.
This allows a trusted user to log into the DISABLED node through the
load-balancer to take a look around, make sure that things are working
properly, etc. before re-enabling the node in the cluster. I'll give
this a shot in the next few days, clean it all up, and publish it (soon?).
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUyucgAAoJEBzwKT+lPKRYi8wQAIi+G/hb0IxXem+yp56n8Lw1
M2TfALSw6JeSmTTrqj6tRDW91b26zj7+3pSZQp0HBkZNiWEZfZNmurLEHe5baWCV
KmKY//zSX8LPOCrTR+hRQ95VAmRIw918OYdgFlRYEQ11Tx45UOr5ivNsAJRfARPw
KdBf3mo3mOKlxjxPEphlZdL6CJojjz0psToc412t3hPf3u2ttxKo0wSn8hDi47O3
bbdpwoA6vpCW7vLRPI22kZoJe4nbsFz0IS26smzVXjarbyrzt/YNHMPhuFSrXSIn
kQhvZeF/61/ZDbOS/54VmfoVugRlcoUiw1nm4Fpvv1xWeezZw7DteCJ/SuqvjbVo
1Y+6wYomMj91Viw8HqNBxh1nXcLUP8tYKqCT1H7MM5sjgMQFonoIdtKMSWbLO8qQ
zDi4qvJudWyGazxWsjTcy9iRyrVqjbkZ0SiVt6trKHyu7NPWBK2CcO3BoznJXs1M
fFsmBTvAFMZLicqenlniPazMQhGzrdfl2QaixPI0moUhnscYoZfUXFhrZaQ0z83v
GKL/MiQDeImZLsi1hup2C8/ML4lkPIj3TS0fP6BxMQZ1Bk6NB6EJ0yJjLq0aH/Kd
6dyax4kfRbG88
Re: Tomcat sending 411 "Length Required" due to Chunked Transfer Encoding
On 29/01/2015 22:29, Jeff Kohut wrote: > My first post to Tomcat list, pardon me if I make any mistakes, > > Any help you can provide would be greatly appreciated. > > I have a Tomcat Server (V 7.0.54) running under Windows 2008 R2 With > Service Pack 1 (and up to date on Security as well as OS patches). That > server is running a vendor supplied group of applications via .war file as > normal. to receive Soap/XML data from remote computer and process and > return data back to calling application. > > The remote calling application hosted by IBM Websphere Application Server > (running Axis2 jars) that is sending XML Soap data via a Post to the Tomcat > Web server on port 8080/8443. If the amount of data is relatively small > (i.e. 14 K) we have no problem receiving the data as Websphere is using > Length Http 1.1 header and Tomcat sends the data to the application with no > issue. However as the data gets larger, Websphere begins using Chunked > Transfer Encoding and apparently Tomcat does not seem to like this as it > returns Http 411 "Length Required" message. The mistake you have made is assuming that it is Tomcat internal code that is returning the 411. It isn't. Tomcat never sends that response code. It is the application that is processing the data and failing to handle the lack of content-length when chunked encoding is used. For the record, Tomcat handles chunked request bodies quite happily and we have a bunch of unit tests that cover this. You need to complain to the vendor that provides the applications you are running on your Tomcat instance. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat sending 411 "Length Required" due to Chunked Transfer Encoding
2015-01-30 1:29 GMT+03:00 Jeff Kohut : > My first post to Tomcat list, pardon me if I make any mistakes, > > Any help you can provide would be greatly appreciated. > > I have a Tomcat Server (V 7.0.54) running under Windows 2008 R2 With > Service Pack 1 (and up to date on Security as well as OS patches). That > server is running a vendor supplied group of applications via .war file as > normal. to receive Soap/XML data from remote computer and process and > return data back to calling application. > > The remote calling application hosted by IBM Websphere Application Server > (running Axis2 jars) that is sending XML Soap data via a Post to the Tomcat > Web server on port 8080/8443. If the amount of data is relatively small > (i.e. 14 K) we have no problem receiving the data as Websphere is using > Length Http 1.1 header and Tomcat sends the data to the application with no > issue. However as the data gets larger, Websphere begins using Chunked > Transfer Encoding and apparently Tomcat does not seem to like this as it > returns Http 411 "Length Required" message. I have searched Tomcat site, > and Tomcat indicates that is support Chunked encoding (part of the MUST > supported parts of the HTTP 1.1 RFC standard. > > My connector in Tomcat is configured: > > connectionTimeout="2" >redirectPort="8443" /> > > I have tried forcing BIO,NIO, and APR with no luck to see if the > implementations might handle Chunked Encoding differently. > > I also have a more complicated 8443 SSL port that also works, until Chunked > encoding is used, and then it also responds with 411 Length Required error. > > I am able to replicate the problem by using SoapUI to send the same Soap > formatted XML Data. It works fine sending all sizes of data UNTIL I enable > Chunked Encoding Threshold which is smaller than the XML payload size > (threshold means to not Chunk until data is larger than Threshold), When > Chunking starts, Tomcat responds with 411 Length required. > > To finally work around this issue, I have put an Apache 2.4 server in front > of Tomcat, and have enable the mod_proxy_http, and am using an Apache > SetEnv variable setting of : SetEnv proxy-sendcl 1 > The proxy-sendcl tells Apache to send the "Length" , and then Tomcat and > application are happy with the data (i.e. no 411 method sent back). > > As I stated above, Tomcat indicates it supports Chunked Encoding on it's > site, but it acts as if it is not happy with it. > > We have looked at packet traces and it appears that the Chunks are > formatted correctly (we are getting an initial Chunk(s) and then the last > Chunk is zero with Cr Lf following it as it seems to indicate in RFC. > > Has anyone else seen this issue and is there any way to alter the Tomcat > behavior with Chunked encoded data? > > We found an IBM Websphere article that seems to admit to the problem, but > they indicate that they should not have to offer a method to disable > chunked encoding as some who seem to have encountered this problem suggest. > IBM states that since Http 1.1 mandates support of Chunked Encoding, then > HTTP 1.1. servers should support Chunked encoding correctly. FYI, I took > the time to recreate the problem in C# code, and as soon as I turn on > Chunked Encoding, the 411 errors is present from that application also when > sending data to Tomcat Server. Tomcat 7 does not send status code 411 (a constant is declared in HttpServletResponse class but it is never used). That response code is coming from a web application that you are using. You may try debugging. http://wiki.apache.org/tomcat/FAQ/Developing#Debugging with a breakpoint on sendError(int,String), setStatus(int) methods of org.apache.catalina.connector.Response. It should be possible to implement a javax.servlet.Filter to cache a request and feed it to the web application for further processing, but it would be better to fix the web application itself. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat sending 411 "Length Required" due to Chunked Transfer Encoding
My first post to Tomcat list, pardon me if I make any mistakes, Any help you can provide would be greatly appreciated. I have a Tomcat Server (V 7.0.54) running under Windows 2008 R2 With Service Pack 1 (and up to date on Security as well as OS patches). That server is running a vendor supplied group of applications via .war file as normal. to receive Soap/XML data from remote computer and process and return data back to calling application. The remote calling application hosted by IBM Websphere Application Server (running Axis2 jars) that is sending XML Soap data via a Post to the Tomcat Web server on port 8080/8443. If the amount of data is relatively small (i.e. 14 K) we have no problem receiving the data as Websphere is using Length Http 1.1 header and Tomcat sends the data to the application with no issue. However as the data gets larger, Websphere begins using Chunked Transfer Encoding and apparently Tomcat does not seem to like this as it returns Http 411 "Length Required" message. I have searched Tomcat site, and Tomcat indicates that is support Chunked encoding (part of the MUST supported parts of the HTTP 1.1 RFC standard. My connector in Tomcat is configured: I have tried forcing BIO,NIO, and APR with no luck to see if the implementations might handle Chunked Encoding differently. I also have a more complicated 8443 SSL port that also works, until Chunked encoding is used, and then it also responds with 411 Length Required error. I am able to replicate the problem by using SoapUI to send the same Soap formatted XML Data. It works fine sending all sizes of data UNTIL I enable Chunked Encoding Threshold which is smaller than the XML payload size (threshold means to not Chunk until data is larger than Threshold), When Chunking starts, Tomcat responds with 411 Length required. To finally work around this issue, I have put an Apache 2.4 server in front of Tomcat, and have enable the mod_proxy_http, and am using an Apache SetEnv variable setting of : SetEnv proxy-sendcl 1 The proxy-sendcl tells Apache to send the "Length" , and then Tomcat and application are happy with the data (i.e. no 411 method sent back). As I stated above, Tomcat indicates it supports Chunked Encoding on it's site, but it acts as if it is not happy with it. We have looked at packet traces and it appears that the Chunks are formatted correctly (we are getting an initial Chunk(s) and then the last Chunk is zero with Cr Lf following it as it seems to indicate in RFC. Has anyone else seen this issue and is there any way to alter the Tomcat behavior with Chunked encoded data? We found an IBM Websphere article that seems to admit to the problem, but they indicate that they should not have to offer a method to disable chunked encoding as some who seem to have encountered this problem suggest. IBM states that since Http 1.1 mandates support of Chunked Encoding, then HTTP 1.1. servers should support Chunked encoding correctly. FYI, I took the time to recreate the problem in C# code, and as soon as I turn on Chunked Encoding, the 411 errors is present from that application also when sending data to Tomcat Server. Thanks, Jeff
Re: How-to disable SSL V3 on Tomcat 6.0.18.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jammy, On 1/29/15 11:02 AM, Jammy Chen wrote: > Thanks for replying, I understood this is old, our product has > already upgraded to latest version, but somehow, some of our users > are still in such old stage, they do not plan uptake now but they > want disable SSL V3 as everybody know this is big security > vulnerability. > > *so now the important thing is how I can disable SSL V3 on Tomcat > 6.0.18.0? I cannot find the solution* Okay, here's the deal: from your perspective, the documentation on Tomcat's site is all out-of-date (into the future) because you (or your customers) are using an ancient version of Tomcat. The best solution is to tell your customers that you don't support your own product on that version of Tomcat any longer. I love that line of crap when it works to my advantage. Anyhow... The "sslEnabledProtocols" configuration attribute was added in Tomcat 6.0.38, well after your 6.0.18 version. Before that, it was called "sslProtocols" and/or "protocols". Give those a try. (Also, there was a bug in the NIO HTTPS connector specifically that it does not recognize the "sslEnabledProtocols" configuration attribute, but that bug was introduced along with "sslEnabledProtocols" in 6.0.38 and fixed in 6.0.43, so the whole thing is moot as far as you are concerned. The "protocols" attribute should work.) I posted some code to this mailing list a while back that will probe a server to discover that types of connections and ciphers it will accept. When you configure your server, consider trying that to see what kinds of connections are possible. Note that it's limited to what version of Java you are using *for the client* as well as the server. So, with Java 1.6, you will not likely have TLS 1.2 available, and many ciphers that the server may support under a newer JVM might not be available in 1.6. I would recommend running the latest Java version you can for the client in this case, because it will be able to try the most options against the server. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUynVWAAoJEBzwKT+lPKRY2lcP/jLvNreb+aY00YhgzAq+Ipii C9lm3lnewamy7dGUGEWE8vgV4Yu5tyzGeb0j6uRvBnHKdp+XEjRfnAuxh1Mx5bqa byw8Fa5rfQ4TbCg5oTZZ3pGAsrBdLZp11P3O3Pxs/oSuzkWObHAlo9VGXaL0oXFB FGgVwZfush/8lfBcF7hRl9tP/QE8/FlVyulKac6BVKdY2Os0crfrLpWyf0N+N2Xh TEgFkwraCdfjy/La2Cudp899k8s/JYq2kRsgRTQ/apYHtbIzCf2B5I32wC0VudOC 9eI3wPnYiM8aR940W5L37cTgDqls+tiifzcodvhyWfO+SiuEayaAJG6KuyIpYFBn ZdDMLcIiA4om+nZcbn1w2n3Hi8VxaPryxHt75Ak9n8FsqSGuEop29cDanbKYJU6P OuK2sAalT6uZCy2GvV/3xGoD7kkvHWmsngsblGSR19nfLr/Y8eS20jho+3YI+pjy hyprA5uKxJAz07iGklx98jq3d33529+FP8jUYtJuP+8jyQenpFhsWd3k6Oh6DeFB MNHU04x7cqOSvtBN+yBe1ZLZVJlEP9eMMVRFpfZwb97I27bxL13FG9IWiMYmMBVj OVaVbm8FqaMtDCjzj36z2PWPLouDRs2kcaEHNYIzp8rsQ9GD0tJTmkxG6XUFDazi cU/f8sS7how+TLnmKycX =nABr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How-to disable SSL V3 on Tomcat 6.0.18.0
Hello Chuck, Thanks for replying, I understood this is old, our product has already upgraded to latest version, but somehow, some of our users are still in such old stage, they do not plan uptake now but they want disable SSL V3 as everybody know this is big security vulnerability. *so now the important thing is how I can disable SSL V3 on Tomcat 6.0.18.0? I cannot find the solution* Jammy 2015-01-29 22:00 GMT+08:00 Caldarale, Charles R : > > From: Jammy Chen [mailto:jamm...@gmail.com] > > Subject: How-to disable SSL V3 on Tomcat 6.0.18.0 > > > Do everybody knows how-to disable SSL v3 in older tomcat version > > > Server version: Apache Tomcat/6.0.18 > > Server built: Jul 22 2008 02:00:36 > > Yes - move up to a current level and read the docs. > > Seriously, if you're using a Tomcat of that vintage (this one is more than > 6.5 years old), you have a lot more security issues to worry about than > SSLv3. It's irresponsible not to upgrade. > > > OS Name:Windows 2003 > > A few months from end-of-life. > > > JVM Version:1.6.0-b105 > > Two years past end-of-life. > > Is there a pattern here? > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail and > its attachments from all computers. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: AJP connector address vs. IPv4/6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andy, On 1/28/15 3:21 PM, Wang, Andy wrote: > On Fri, 2015-01-23 at 16:05 -0500, Christopher Schultz wrote: > >>> >>> If only one address per Connector can be specified, can you >>> not just use 2 s, one for each ? They should not >>> conflict. >> >> That should definitely work (address="127.0.0.1" and >> address="::") but one connector might be nice. >> >> Maybe Tomcat could detect some magic value that is invalid for >> an address (like "loopback") and then use >> InetAddress.getLoopbackAddress() instead of a traditional >> address lookup/resolution. >> > > Just thought I'd provided a bit more details for completeness > sake. > > Even InetAddress.getLoopbackAddress isn't perfect. What Jess left > out of his original description is that we really ideally wanted to > simply leave mod_jk configured to use localhost instead of an IP > address. We incorrectly assumed localhost = 127.0.0.1. I forgot > that localhost can also resolve to ::1 (for some reason I had it in > my head that localhost6 would be used for ::1) > > So really, without using an IP address on both mod_jk and tomcat > side, there's no good way to synchronize the two configurations. So it seems like configuration that supports "localhost" -> InetAddress.getLoopbackAddress() won't help, because you might still not get what you expect (or want). Better to force the user to be explicit. > The two connectors idea is an interesting one, but that has the > unfortunate aspect of now maintaining 2 separate thread pools > complicating performance tuning a little bit especially if you > can't predict exactly which connector the mod_jk side might be > using if we rely on an "ambiguous" localhost value. See Chuck's response: he's right. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUylLKAAoJEBzwKT+lPKRYghoQAI+/5DoAKRtai4f9W0EXEwGU kWeFbXpWAcONeVvDIExJQxmwf/F9VPcy70VG2xJ480/85Cm596aUA6tl6BmzdstI HkWURVPjBpzTyeZZ8bsAmtJhePcrJ1nVdjV5EiYHOKcxL33GnVwS6AO0Iyszs5QJ CfRHsajHM7AKVG3qO9rZtbBGP9KJ4Yga3X44tdpsZD0lTLdgdimllqF7iSGTLFN2 my3yZisgiQUp3BCO+Cx910NGsGCI5tGhCJPVNhxMCqHA28iKJ+oGhwynXgtvCcKY n01kiFY+a7apTP+OTh6CWYblLDFIfZ6rWD58IByjNAYq0mGE0r5cHUXY1ptoilOn DumnFn3v9gaQxAAplkz761RCBEuZd03IfupCvo6MfQkH+0A+31y9Ni2tEP5W3Rxy wetjWFQifuUYl5r5KrHGbpax0N4PDhJ9n5VU6zmuRoc8YkHQSq7Lvzp/fhPwGbj+ rQbRCedgj8eLNqk3ECCP1cr4gcFtFwkHBjwl5pkhZ24jkUmRgyAnjXlA/mn3t5Xt 44QXuwyf0kLEvAscRmr5Ll4+ZMsFqiypIO9bTOyRAxUnwC8+5PhbVUPXa1IleUsp 0MbG7bjdgxmClxyNmblA/rM1gi47cWMsklcHVwBJpmWIDPcraQHBrQhvom3/O41m sLrSbwKKwrZC2S96kc2U =br0p -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to use Jasper to Parse JSP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Zhang, On 1/29/15 7:22 AM, t-zhang wrote: > I need a JSP codecheck tool (like PMD) But PMD's JSP parser is not > enouth. So I need a better JSPparser and I want to try Jasper as a > parser. What do you want your checker to do? Anything more than make sure that the JSP will compile? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUylL/AAoJEBzwKT+lPKRYyhMP/3tpzTkw6rdvVhjDR6nbi7LK aDjDfpI7fLiIfjf78Bjzxg7Nfkd9hINTI3GDA+iOqNPdyo5i9RN25IW/mYzH4qT5 CGgcf5jgiz0K2a5GqJ3ZRSML+3Dq4RSEZpfwcogmAVHBWy+je4yeD/usAQSyQUxt llcbobvJ/nGsy5TmbUZddEP5z8G+ELuaO5DAvhwDmvzASCtZiGeoEwh1UzOdAsEb g/4IjJA1TjGfiDkm43gja039gI+xjLPAsv+rXFV0SChV3VlqMsoB3l0gWXnfuF57 IiGDo/qaBgXUBb9HjgtDt4vKHFR+xc9Jn5dwnR6xJAxOSKh2NFY/BaY+TsmGLanX YzRL4de497ziJXWduUXSAx36ldyUD6AHodBb+dl5XLvXIJ23y9B8MCrunYUoTDvK kzwuxEYB8YZGN8zxALlp2ImV0n38RwXGpnVmcx+1ePvjw01OTAqsokHT/jt5sYAG cPxKyCmhDzMO/KErgsgkbbBseqwzJ6QCIWcIYmak/2ADrAVv4/npaPNUcyHBjfS5 f4FrTjFBlfjJtBjvisiVWG+dYHGdW5lb7dKloMSEwoPSNQeBj1byeXJToEWz2ymX aG+4si177FdRw3SBjKYwCzhL/M8V3wLKmwyUUg1E0AZQkDaNd8/DU7THaUjCLFlS qjY8EM8HetXHdRsre5nE =7+p8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FIPS Mode enabling on Tomcat 7.00.057
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Geett, On 1/29/15 12:45 AM, Geett Chanddra Singha wrote: > I'm getting the following error when enabling FIPS mode on Apache > Tomcat: > > Jan 28, 2015 5:02:33 PM > org.apache.catalina.core.AprLifecycleListener lifecycleEvent > > SEVERE: Failed to initialize the SSLEngine. > > java.lang.Exception: error:2D06C06E:FIPS > routines:FIPS_mode_set:fingerprint does not match > > at org.apache.tomcat.jni.SSL.fipsModeSet(Native Method) Looks like your fingerprint doesn't match. > *Steps I followed to configure: * > > Added the following in server.xml > > > > > > > className="org.apache.catalina.core.AprLifecycleListener" > SSLEngine="on" FIPSMode="on"/> > -- > > 1.)Installing tomcat apr: > > Download from http://apache.mirror.anlx.net/apr/apr-1.5.1.tar.gz What UNIX are you running? Are you sure you have to build this all yourself? > tar zxvf apr-1.5.1.tar.gz > > rm apr-1.5.1.tar.gz > > cd apr-1.5.1 * > > sudo ./configure > > sudo make > > sudo make install Why did you build this as root? > export LD_LIBRARY_PATH='$LD_LIBRARY_PATH:/usr/local/apr/lib' > > 2.)Installing tomcat tomcat-native: > > Download > > http://apache.bytenet.in/tomcat/tomcat-connectors/native/1.1.32/source/tomcat-native-1.1.32-src.tar.gz > > tar zxvf tomcat-native-1.1.32-src.tar.gz > > rm tomcat-native-1.1.32-src.tar.gz > > cd tomcat-native-1.1.32-src/jni/native > > JAVA_HOME=/usr/lib/jvm/ > > sudo ./configure --with-apr=/usr/local/apr > --with-java-home=$JAVA_HOME > > sudo make > > sudo make install > > > > 3.)Adding the following line > > CATALINA_OPTS="$CATALINA_OPTS > -Djava.library.path=/usr/local/apr/lib" > > 4.) Restarting Tomcat > > Pl > > Please help me resolve this issue and please let me know if i > missed any step. I didn't see the part where your built OpenSSL with FIPS. Did you do that? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUylHjAAoJEBzwKT+lPKRYBacP/2NTeUf4/ozIkSirUPPmDgz+ hbxyoG8HbMwllLqyO4tjD9+7/iX2VxDwALZIOaU3/x1XitXdheXHeaXubFAqVePH TOmG7zoUHZ+wvJwXz5DztpV7GrpK2j3TgaKGPMS8Rjf6hSEgUdNg1Oc7Uqac0TlX OwRjEwb8ARAY3OXqZ2IkQsXqJ20qfEwc+7q0/VY+Y3ll4ixKQkQkqFnRi2WU3C4S ZGSCPwVIczjC9rM3CsPAXtqXVjAOO18ZJ+6fpHXL4hocWrdjpeuUF/1soVgL+rEC 86SwpZ+KNb+BapdbNIkmWCIVqlJGsTlRP0Xi9DGSJ9L9CqS2gCrLr00aAhM+9IaX BUbmB7FZZjs299ByU3LDd/HlUiWlyfvb8mPzsLN4fBfWWICpqV5NoUgV/tgLn4l+ UXBbRiL0pYv2HJTvswNTxBrmNdwiJhf7Iy/F9Dvxp479Tr1UVRV07NsHCSt7MGeg AXcyK0GskJd5BZDq1KUYLhugsuTVj8HJ0YMVrzd4/DJEpgpL0JWdUcedYj6Jw9mU UWrx4wUz2plUd6E1AURnVTIxoxh4Mm40DuhR+Vj10amRClisMe4CuIrRDs0LvGE7 OKE0oQk9NW90b2dl2nF61uZHyX00ramVI+7MVv6/L7EoEJ+Hmyq2mAZEJKO4zuXR lHlurY8fg3E/hsDM6+gI =hB4i -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
I wonder if it's possible in HttpSessionListener implementation get
access to actual Tomcat's StandardSession?
HttpSessionEvent contains reference to StandardSessionFacade.
Otherwise I cannot access Manager, Context etc which should led me to
SingleSignOn.
Should I go through dangerous reflection ways or there are some
'recommended' ways to access the internals?
Thanks.
On Thu, Jan 29, 2015 at 1:25 PM, Leonid Rozenblyum
wrote:
> Thanks for the great advice!
>
> On Thu, Jan 29, 2015 at 12:57 PM, Mark Thomas wrote:
>> On 29/01/2015 10:54, Leonid Rozenblyum wrote:
>>> Hello! I'm trying to extend the SingleSignOn valve and if possible
>>> could you point me how can I create a global session listener
>>> without modifying configurations of web applications?
>>>
>>> The idea is that I should catch all 'session create' events from all
>>> webapps, and if they have the 'custom SSO valve' as parent - add them
>>> to SSO irregardless the fact the have no authentication themselves.
>>>
>>> Thanks for any help!
>>
>> Put your listener in conf/web.xml. That file is applied to all web
>> applications.
>>
>> Mark
>>
>>
>>>
>>> On Thu, Jan 22, 2015 at 9:44 PM, Leonid Rozenblyum
>>> wrote:
Hello Mark!
I'll investigate deeper the SingleSignOn class to understand how to
extend it to allow adding the session always.
To summarize : my understanding of current behaviour is following:
- if a web application uses authentication (has security-constraint?)
-> then SingleSignOn will provide :
a) correct request.getUserPrincipal()
b) correct session invalidation
- if a web application is not using authentication -> SingleSignOn
will just provide
a) correct request.getUserPrincipal()
Probably there were some logical architectural backgrounds to take
this decision
But for us it was counter-intuitive. We expected either a)+b) are both
available or nothing.
Presence of just a) caused unexpected security issues in our app when
after logout and logging in with lower permissions user had access to
data stored for high-privileged user.
Thanks for your help!
On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas wrote:
> On 22/01/2015 16:25, Leonid Rozenblyum wrote:
>> So doesn't "As soon as the user logs out of one web application (for
>> example, by invalidating the corresponding session if form based login
>> is used), the user's sessions in all web applications will be
>> invalidated. " ( this phrase is from official doc) imply that all
>> sessions are invalidated and thus attributes are cleared?
>>
>> (and as I mentioned above : there is some workaround that looks like
>> forces Tomcat to work exactly like this).
>
> A session is only added to SSO if the web application uses
> authentication. You could extend the SSOValve to always add the session
> if you wish.
>
> Mark
>
>
>>
>> On Thu, Jan 22, 2015 at 6:21 PM, Mark Thomas wrote:
>>> On 22/01/2015 16:12, Leonid Rozenblyum wrote:
Probably the attachment will be cut out by the mailing server.
So I send the text of the test.jsp here:
Hello
User Principal: <%= request.getUserPrincipal() %>
<%
if (request.getUserPrincipal() != null ) {
%>
User is authenticated, allow to set session attribute
<%
request.getSession().setAttribute("markerAttribute",
"markerAttributeValue");
}
else {
%>
User is a guest. No setting of any session attributes.
<%
}
%>
>>>
>>> You need to remove the session attribute if the user is not
>>> authentication.
>>>
>>> Tomcat's SSO is working as expected. You are, of course, free to
>>> extend/patch it if you prefer.
>>>
>>> Mark
>>>
Marker Attribute from session: <%=
request.getSession().getAttribute("markerAttribute") %>
On Thu, Jan 22, 2015 at 5:51 PM, Leonid Rozenblyum
wrote:
> I think I could reproduce my problem also on experimenting with your
> examples!
>
> I went exactly by your steps but my JSP is an extended version of
> yours ( I add it to attachment )
>
> In the ROOT/test.jsp I added code to set a session attribute if the
> user principal is not null.
> I expect that after logging out via another application (using SSO) my
> session attribute won't be there (my expectation of SingleSignOff is
> complete session invalidation).
>
> However it's not the case : after logging out in security/protected
> the session attribute is still kept (while UserPrincipal is null).
>
>
> Complete scenario:
>
>>
RE: How-to disable SSL V3 on Tomcat 6.0.18.0
> From: Jammy Chen [mailto:jamm...@gmail.com] > Subject: How-to disable SSL V3 on Tomcat 6.0.18.0 > Do everybody knows how-to disable SSL v3 in older tomcat version > Server version: Apache Tomcat/6.0.18 > Server built: Jul 22 2008 02:00:36 Yes - move up to a current level and read the docs. Seriously, if you're using a Tomcat of that vintage (this one is more than 6.5 years old), you have a lot more security issues to worry about than SSLv3. It's irresponsible not to upgrade. > OS Name:Windows 2003 A few months from end-of-life. > JVM Version:1.6.0-b105 Two years past end-of-life. Is there a pattern here? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to use Jasper to Parse JSP
Thanks for your reply. I need a JSP codecheck tool (like PMD) But PMD's JSP parser is not enouth. So I need a better JSPparser and I want to try Jasper as a parser. Best Regards Tao Zhang On Tue, 27 Jan 2015 11:56:42 + Mark Thomas wrote: > On 27/01/2015 11:36, t-zhang wrote: > > Hi guys > > > > I am looking for a tool which can parse the JSP code(parse and generate > > the AST) > > Why? What problem are you trying to solve? (There may be a better solution). > > Mark > > > > If anyone use Jasper to parse the JSP, > > Could you share your experience to me? > > > > I guess the class "org.apache.jasper.compiler.Parser" in Jasper is able > > to generate the AST. > > But I can't get the Return Value maybe because of I can't import > > org.apache.jasper.compiler.Node to my project. > > > > Best Regards > > > > Tao Zhang > > > > > > > > - > > 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: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Thanks for the great advice!
On Thu, Jan 29, 2015 at 12:57 PM, Mark Thomas wrote:
> On 29/01/2015 10:54, Leonid Rozenblyum wrote:
>> Hello! I'm trying to extend the SingleSignOn valve and if possible
>> could you point me how can I create a global session listener
>> without modifying configurations of web applications?
>>
>> The idea is that I should catch all 'session create' events from all
>> webapps, and if they have the 'custom SSO valve' as parent - add them
>> to SSO irregardless the fact the have no authentication themselves.
>>
>> Thanks for any help!
>
> Put your listener in conf/web.xml. That file is applied to all web
> applications.
>
> Mark
>
>
>>
>> On Thu, Jan 22, 2015 at 9:44 PM, Leonid Rozenblyum
>> wrote:
>>> Hello Mark!
>>>
>>> I'll investigate deeper the SingleSignOn class to understand how to
>>> extend it to allow adding the session always.
>>>
>>>
>>> To summarize : my understanding of current behaviour is following:
>>>
>>> - if a web application uses authentication (has security-constraint?)
>>> -> then SingleSignOn will provide :
>>> a) correct request.getUserPrincipal()
>>> b) correct session invalidation
>>>
>>> - if a web application is not using authentication -> SingleSignOn
>>> will just provide
>>> a) correct request.getUserPrincipal()
>>>
>>> Probably there were some logical architectural backgrounds to take
>>> this decision
>>>
>>> But for us it was counter-intuitive. We expected either a)+b) are both
>>> available or nothing.
>>>
>>> Presence of just a) caused unexpected security issues in our app when
>>> after logout and logging in with lower permissions user had access to
>>> data stored for high-privileged user.
>>>
>>> Thanks for your help!
>>>
>>> On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas wrote:
On 22/01/2015 16:25, Leonid Rozenblyum wrote:
> So doesn't "As soon as the user logs out of one web application (for
> example, by invalidating the corresponding session if form based login
> is used), the user's sessions in all web applications will be
> invalidated. " ( this phrase is from official doc) imply that all
> sessions are invalidated and thus attributes are cleared?
>
> (and as I mentioned above : there is some workaround that looks like
> forces Tomcat to work exactly like this).
A session is only added to SSO if the web application uses
authentication. You could extend the SSOValve to always add the session
if you wish.
Mark
>
> On Thu, Jan 22, 2015 at 6:21 PM, Mark Thomas wrote:
>> On 22/01/2015 16:12, Leonid Rozenblyum wrote:
>>> Probably the attachment will be cut out by the mailing server.
>>> So I send the text of the test.jsp here:
>>>
>>> Hello
>>>
>>> User Principal: <%= request.getUserPrincipal() %>
>>>
>>> <%
>>> if (request.getUserPrincipal() != null ) {
>>> %>
>>> User is authenticated, allow to set session attribute
>>> <%
>>> request.getSession().setAttribute("markerAttribute",
>>> "markerAttributeValue");
>>> }
>>> else {
>>> %>
>>> User is a guest. No setting of any session attributes.
>>> <%
>>> }
>>> %>
>>
>> You need to remove the session attribute if the user is not
>> authentication.
>>
>> Tomcat's SSO is working as expected. You are, of course, free to
>> extend/patch it if you prefer.
>>
>> Mark
>>
>>>
>>>
>>>
>>> Marker Attribute from session: <%=
>>> request.getSession().getAttribute("markerAttribute") %>
>>>
>>> On Thu, Jan 22, 2015 at 5:51 PM, Leonid Rozenblyum
>>> wrote:
I think I could reproduce my problem also on experimenting with your
examples!
I went exactly by your steps but my JSP is an extended version of
yours ( I add it to attachment )
In the ROOT/test.jsp I added code to set a session attribute if the
user principal is not null.
I expect that after logging out via another application (using SSO) my
session attribute won't be there (my expectation of SingleSignOff is
complete session invalidation).
However it's not the case : after logging out in security/protected
the session attribute is still kept (while UserPrincipal is null).
Complete scenario:
- request ROOT/test.jsp
- no authenticated user
- no marker attribute in session
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user authenticated above. SSO cookie has a path of / so gets
returned with all requests. This exposes the UserPrincipal to all
apps
- marker attribute is shown from session.
- request examples/jsp/security/protected
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
On 29/01/2015 10:54, Leonid Rozenblyum wrote:
> Hello! I'm trying to extend the SingleSignOn valve and if possible
> could you point me how can I create a global session listener
> without modifying configurations of web applications?
>
> The idea is that I should catch all 'session create' events from all
> webapps, and if they have the 'custom SSO valve' as parent - add them
> to SSO irregardless the fact the have no authentication themselves.
>
> Thanks for any help!
Put your listener in conf/web.xml. That file is applied to all web
applications.
Mark
>
> On Thu, Jan 22, 2015 at 9:44 PM, Leonid Rozenblyum
> wrote:
>> Hello Mark!
>>
>> I'll investigate deeper the SingleSignOn class to understand how to
>> extend it to allow adding the session always.
>>
>>
>> To summarize : my understanding of current behaviour is following:
>>
>> - if a web application uses authentication (has security-constraint?)
>> -> then SingleSignOn will provide :
>> a) correct request.getUserPrincipal()
>> b) correct session invalidation
>>
>> - if a web application is not using authentication -> SingleSignOn
>> will just provide
>> a) correct request.getUserPrincipal()
>>
>> Probably there were some logical architectural backgrounds to take
>> this decision
>>
>> But for us it was counter-intuitive. We expected either a)+b) are both
>> available or nothing.
>>
>> Presence of just a) caused unexpected security issues in our app when
>> after logout and logging in with lower permissions user had access to
>> data stored for high-privileged user.
>>
>> Thanks for your help!
>>
>> On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas wrote:
>>> On 22/01/2015 16:25, Leonid Rozenblyum wrote:
So doesn't "As soon as the user logs out of one web application (for
example, by invalidating the corresponding session if form based login
is used), the user's sessions in all web applications will be
invalidated. " ( this phrase is from official doc) imply that all
sessions are invalidated and thus attributes are cleared?
(and as I mentioned above : there is some workaround that looks like
forces Tomcat to work exactly like this).
>>>
>>> A session is only added to SSO if the web application uses
>>> authentication. You could extend the SSOValve to always add the session
>>> if you wish.
>>>
>>> Mark
>>>
>>>
On Thu, Jan 22, 2015 at 6:21 PM, Mark Thomas wrote:
> On 22/01/2015 16:12, Leonid Rozenblyum wrote:
>> Probably the attachment will be cut out by the mailing server.
>> So I send the text of the test.jsp here:
>>
>> Hello
>>
>> User Principal: <%= request.getUserPrincipal() %>
>>
>> <%
>> if (request.getUserPrincipal() != null ) {
>> %>
>> User is authenticated, allow to set session attribute
>> <%
>> request.getSession().setAttribute("markerAttribute",
>> "markerAttributeValue");
>> }
>> else {
>> %>
>> User is a guest. No setting of any session attributes.
>> <%
>> }
>> %>
>
> You need to remove the session attribute if the user is not
> authentication.
>
> Tomcat's SSO is working as expected. You are, of course, free to
> extend/patch it if you prefer.
>
> Mark
>
>>
>>
>>
>> Marker Attribute from session: <%=
>> request.getSession().getAttribute("markerAttribute") %>
>>
>> On Thu, Jan 22, 2015 at 5:51 PM, Leonid Rozenblyum
>> wrote:
>>> I think I could reproduce my problem also on experimenting with your
>>> examples!
>>>
>>> I went exactly by your steps but my JSP is an extended version of
>>> yours ( I add it to attachment )
>>>
>>> In the ROOT/test.jsp I added code to set a session attribute if the
>>> user principal is not null.
>>> I expect that after logging out via another application (using SSO) my
>>> session attribute won't be there (my expectation of SingleSignOff is
>>> complete session invalidation).
>>>
>>> However it's not the case : after logging out in security/protected
>>> the session attribute is still kept (while UserPrincipal is null).
>>>
>>>
>>> Complete scenario:
>>>
>>> - request ROOT/test.jsp
>>> - no authenticated user
>>> - no marker attribute in session
>>>
>>> - request examples/jsp/security/protected
>>> - FORM login prompt, login, see index.jsp
>>>
>>> - request ROOT/test.jsp
>>> - shows user authenticated above. SSO cookie has a path of / so gets
>>> returned with all requests. This exposes the UserPrincipal to all
>>> apps
>>> - marker attribute is shown from session.
>>>
>>> - request examples/jsp/security/protected
>>> - see index.jsp
>>> - click logout
>>> - see FORM login page
>>>
>>> - request ROOT/test.jsp
>>> - no authenticated user. As expected. Logout above has destroyed SSO
>>> session and removed SS
Re: [ Tomcat8 ] [ SingleSignOn ] > 2 Webapplications
Hello! I'm trying to extend the SingleSignOn valve and if possible
could you point me how can I create a global session listener
without modifying configurations of web applications?
The idea is that I should catch all 'session create' events from all
webapps, and if they have the 'custom SSO valve' as parent - add them
to SSO irregardless the fact the have no authentication themselves.
Thanks for any help!
On Thu, Jan 22, 2015 at 9:44 PM, Leonid Rozenblyum
wrote:
> Hello Mark!
>
> I'll investigate deeper the SingleSignOn class to understand how to
> extend it to allow adding the session always.
>
>
> To summarize : my understanding of current behaviour is following:
>
> - if a web application uses authentication (has security-constraint?)
> -> then SingleSignOn will provide :
> a) correct request.getUserPrincipal()
> b) correct session invalidation
>
> - if a web application is not using authentication -> SingleSignOn
> will just provide
> a) correct request.getUserPrincipal()
>
> Probably there were some logical architectural backgrounds to take
> this decision
>
> But for us it was counter-intuitive. We expected either a)+b) are both
> available or nothing.
>
> Presence of just a) caused unexpected security issues in our app when
> after logout and logging in with lower permissions user had access to
> data stored for high-privileged user.
>
> Thanks for your help!
>
> On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas wrote:
>> On 22/01/2015 16:25, Leonid Rozenblyum wrote:
>>> So doesn't "As soon as the user logs out of one web application (for
>>> example, by invalidating the corresponding session if form based login
>>> is used), the user's sessions in all web applications will be
>>> invalidated. " ( this phrase is from official doc) imply that all
>>> sessions are invalidated and thus attributes are cleared?
>>>
>>> (and as I mentioned above : there is some workaround that looks like
>>> forces Tomcat to work exactly like this).
>>
>> A session is only added to SSO if the web application uses
>> authentication. You could extend the SSOValve to always add the session
>> if you wish.
>>
>> Mark
>>
>>
>>>
>>> On Thu, Jan 22, 2015 at 6:21 PM, Mark Thomas wrote:
On 22/01/2015 16:12, Leonid Rozenblyum wrote:
> Probably the attachment will be cut out by the mailing server.
> So I send the text of the test.jsp here:
>
> Hello
>
> User Principal: <%= request.getUserPrincipal() %>
>
> <%
> if (request.getUserPrincipal() != null ) {
> %>
> User is authenticated, allow to set session attribute
> <%
> request.getSession().setAttribute("markerAttribute",
> "markerAttributeValue");
> }
> else {
> %>
> User is a guest. No setting of any session attributes.
> <%
> }
> %>
You need to remove the session attribute if the user is not authentication.
Tomcat's SSO is working as expected. You are, of course, free to
extend/patch it if you prefer.
Mark
>
>
>
> Marker Attribute from session: <%=
> request.getSession().getAttribute("markerAttribute") %>
>
> On Thu, Jan 22, 2015 at 5:51 PM, Leonid Rozenblyum
> wrote:
>> I think I could reproduce my problem also on experimenting with your
>> examples!
>>
>> I went exactly by your steps but my JSP is an extended version of
>> yours ( I add it to attachment )
>>
>> In the ROOT/test.jsp I added code to set a session attribute if the
>> user principal is not null.
>> I expect that after logging out via another application (using SSO) my
>> session attribute won't be there (my expectation of SingleSignOff is
>> complete session invalidation).
>>
>> However it's not the case : after logging out in security/protected
>> the session attribute is still kept (while UserPrincipal is null).
>>
>>
>> Complete scenario:
>>
>> - request ROOT/test.jsp
>> - no authenticated user
>> - no marker attribute in session
>>
>> - request examples/jsp/security/protected
>> - FORM login prompt, login, see index.jsp
>>
>> - request ROOT/test.jsp
>> - shows user authenticated above. SSO cookie has a path of / so gets
>> returned with all requests. This exposes the UserPrincipal to all
>> apps
>> - marker attribute is shown from session.
>>
>> - request examples/jsp/security/protected
>> - see index.jsp
>> - click logout
>> - see FORM login page
>>
>> - request ROOT/test.jsp
>> - no authenticated user. As expected. Logout above has destroyed SSO
>> session and removed SSO cookie
>>
>> However - the marker attribute is STILL in session of ROOT
>> webapplication.
>> For us it means that the session is NOT invalidated correctly.
>>
>> Thanks for your feedback and detail scenario you sent, I think it
>> helped discover a probable bug
How-to disable SSL V3 on Tomcat 6.0.18.0
Hello team, Do everybody knows how-to disable SSL v3 in older tomcat version, I have tried to variety solution including sslProtocols or sslEnabledProtocols but it both did not work well, the Firefox I am using to test is only select TLS 1 and result is that I were not able to access the site. Below is the server information: Server version: Apache Tomcat/6.0.18 Server built: Jul 22 2008 02:00:36 Server number: 6.0.18.0 OS Name:Windows 2003 OS Version: 5.2 Architecture: x86 JVM Version:1.6.0-b105 JVM Vendor: Sun Microsystems Inc Thanks
