[Book Information] Apache TomEE Cookbook
Hi Tomcat users, I have written a small cook book about Apache TomEE (Apache Tomcat + Web Profile Stack). My book Apache TomEE Cookbook published by Amazon Create Space. This is the first book in the market related to Apache TomEE. I thought that you can also interest with this book. You can get e-book format of the book from https://www.e-junkie.com/ecom/gb.php?c=carti=1271538cl=256523ejc=2 Here is the book details: This cookbook is written for learning TomEE internals by server administrators and Java EE developers. Administrators will learn how to configure TomEE for using it in a production environment. Developers will learn how to create web applications using the Java™Platform, Enterprise Edition 6 (Java EE 6) technologies provided by TomEE runtime and to deploy these enterprise applications into TomEE. Paperback: 196 pages Publisher: CreateSpace Independent Publishing Platform; 1 edition (August 21, 2013) Language: English ISBN-10: 1492201448 ISBN-13: 978-1492201441 Product Dimensions: 11 x 8.5 x 0.4 inches Amazon Page: Amazon book page Best Regards. Gurkan
OT: Re: what if I lost the keystore which generate the CSR
Well, the original cert will be revoked and you can create new CSR and reapply new cert. With Thawte we did this one year ago without a problem. Contact Thawte support. Jan. Sorry I am a beginner about ssl cert. according to http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Create_a_local_Certificate_Signing_Request_(CSR) it will gen a keystore and CSR. we generate the CSR and send to Certificate Authority. What if I lost the keystore ? should I regen the CSR again to reapply the ssl cert? Refer to https://search.thawte.com/support/ssl-digital-certificates/index?page=contentid=SO832 It will generate a new keystore file. is it the file store the private key? which stated in https://search.thawte.com/support/ssl-digital-certificates/index?page=contentid=SO750 , which say 1. Private Key file loss. 2. Private Key pass phrase loss. 3. Private Key file has been compromised due to the server being hacked. .. .. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms
It seems incorrect to me because RFC 5246 in 1.2 Major Differences from TLS 1.1 says this : .. All cipher suites in this document use P_SHA256. .. Added HMAC-SHA256 cipher suites I can't read anywhere that SHA384 and others SHOULD or MUST be implemented. Other RFCs updating this 5246 (5746, 5878, 6176 and Errata) don't talk about this either. However, in 5246 5. HMAC and the Pseudorandom Function we can read : In this section, we define one PRF, based on HMAC. This PRF with the SHA-256 hash function is used for all cipher suites defined in this document and in TLS documents published prior to this document when TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function. This allows future usage of SHA384 and others, if defined correctly. regards A.T. 2013/8/22 Martin Gainty mgai...@hotmail.com: point of confusion Eric Rescorla specifically cites SHA384 in his cipher examples for TLS 1.2 Update http://www.ietf.org/rfc/rfc5246.txt http://www.ietf.org/proceedings/70/slides/tls-0.pdf Kuat Eshengazin used bltest as a test harness for SHA384 bltest -R -m prf_sha384 -k tests/prf_sha384/key0 -t tests/prf_sha384/seed0 -h -g 148 -x https://bugzilla.mozilla.org/show_bug.cgi?id=480514 Is this incorrect? Martin __ Please do not alter or disrupt this transmission..Thank You Date: Thu, 22 Aug 2013 14:53:55 +0100 Subject: Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms From: aterrest...@gmail.com To: users@tomcat.apache.org According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See : http://www.ietf.org/rfc/rfc5246.txt The JSSE Reference Guide also doesn't talk about this SHA384 as an implementation requirement. See : http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl This means you have a problem with SHA256 only. Maybe it's easier to test on client-side, with one of the following ciphers (that you find on the same Reference Guide ) for example : TLS_DH_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Let me know if this works, or I will try to test by myself with my own client. 2013/8/22 Dennis Sosnoski d...@sosnoski.com: I've already done that, though as far as I can see that doesn't effect the digest algorithms (only the encryption options). - Dennis On 08/23/2013 12:24 AM, Aurélien Terrestris wrote: Hello I suppose you need to run your JVM with the unrestricted policy files (on b= oth client and server sides). You have to download them from Oracle website= for your java version, and replace the old. These files are : local_policy.jar US_export_policy.jar Regards 2013/8/22 d...@sosnoski.com: Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I haven't been able to make it work with any of the SHA256/384 algorithms - they always show up in the Ignoring unsupported cipher suite list. I get the same thing happening when I try to use them from client code, so I know it's not a Tomcat issue, but I'm hoping someone knows a workaround. Any suggestions? Thanks, - Dennis - 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 - 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
how to log unauthorized https access attempts (secure=true clientAuth=true)
Hallo I use https with client cert authentication Connector protocol=...Http11NioProtocol SSLEnabled=true scheme=https secure=true clientAuth=true sslProtocol=TLS keystoreFile=...jks key..Pass=... keystoreType=JKS truststoreFile=...jks trust..Pass=.. / AccessLogValve cannot be placed inservice, only in engine (host, context), but if client has bad/untrusted cert or no cert at all, possibly connector doesn't pass him to engine and to AccessLogValve. How can I log such access attempts with tomcat ? Regards Jakub
Re: Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms
Hi
the JSSE Reference Guide defines which possibilities for anyone
implementing a JSSE provider (let's call it an API if you want).
Oracle's provider only implements a part of this API, misleading you
to believe SHA384 is available when it's unfortunately not.
About Bouncy Castle, I believe they only implement a JCE provider and
not any JSSE provider. Adding their jar to your providers in the
security file is not enough.. you would have to implement a full JSSE
provider using their JCE classes. A lot of work.
If you're looking for the best security, I would tell you to use the
available DHE and ECDHE ciphersuites which make things complicated to
decrypt. Have a look here for more information :
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
RFC 5288 is interesting, we probably have to wait some more years
before we can use all these new ciphers.
best regards
A.T.
2013/8/23 Dennis Sosnoski d...@sosnoski.com:
Thanks, Aurélien. I'd seen the SHA384 versions listed in the JSSE Cipher
Suite Names and thought they were available:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites
I was really hoping to use one of the GCM suites, but I gather those are not
officially approved yet either: http://tools.ietf.org/html/rfc5288 It
appears there is growing support for these in the world, even if they're not
yet an official part of TLS 1.2.
On the client side, this:
SSLContext context = SSLContext.getInstance(TLS);
context.init(null, new TrustManager[] { tm }, null);
SSLParameters params = context.getSupportedSSLParameters();
String[] suites = params.getCipherSuites();
System.out.println(Connecting with + suites.length + cipher
suites supported:);
for (int i = 0; i suites.length; i++) {
System.out.print(' ');
System.out.println(suites[i]);
}
gives me a list of supported cipher suites including:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
...
but when I try to connect using the socket factory from the context I get
the ssl debug information:
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
...
where all the variations using SHA256 or SHA384 are in this second list. But
explicitly setting a suite like:
System.setProperty(https.cipherSuites,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256);
works, while the SHA384 version fails with Unsupported ciphersuite (as
does any version I've tried using GCM in place of CBC).
I thought JSSE would use the JCE algorithms from BouncyCastle, but it looks
like this doesn't work. I'll have to dig into the JSSE code to see what's
going wrong on that part.
- Dennis
On 08/23/2013 03:48 AM, Aurélien Terrestris wrote:
According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
http://www.ietf.org/rfc/rfc5246.txt
The JSSE Reference Guide also doesn't talk about this SHA384 as an
implementation requirement. See :
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl
This means you have a problem with SHA256 only. Maybe it's easier to
test on client-side, with one of the following ciphers (that you find
on the same Reference Guide ) for example :
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Let me know if this works, or I will try to test by myself with my own
client.
2013/8/22 Dennis Sosnoski d...@sosnoski.com:
I've already done that, though as far as I can see that doesn't effect
the
digest algorithms (only the encryption options).
- Dennis
On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:
Hello
I suppose you need to run your JVM with the unrestricted policy files
(on
b=
oth client and server sides). You have to download them from Oracle
website=
for your java version, and replace the old.
These files are :
local_policy.jar
US_export_policy.jar
Regards
2013/8/22 d...@sosnoski.com:
Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a
sslEnabledProtocols=TLSv1.2 attribute on the Connector. But I
haven't
been able to make it work with any of the SHA256/384 algorithms - they
always show up in the Ignoring unsupported cipher suite list. I get
the
same thing happening when I try to use them from client code, so I know
it's
not a Tomcat issue, but I'm hoping someone knows a workaround.
Any suggestions?
Re: how to log unauthorized https access attempts (secure=true clientAuth=true)
On 23/08/2013 11:02, Ja kub wrote: Hallo I use https with client cert authentication Connector protocol=...Http11NioProtocol SSLEnabled=true scheme=https secure=true clientAuth=true sslProtocol=TLS keystoreFile=...jks key..Pass=... keystoreType=JKS truststoreFile=...jks trust..Pass=.. / AccessLogValve cannot be placed inservice, only in engine (host, context), but if client has bad/untrusted cert or no cert at all, possibly connector doesn't pass him to engine and to AccessLogValve. How can I log such access attempts with tomcat ? Out of the box there is no way to do this. There are a couple of ways you might do this with some custom code. You could implement a custom trust manager that logged failures although even then, the trust manager doesn't have access to the connection so you can't log IP address and the like. You could also modify the Tomcat connector code. All the endpoints trigger the handshake and then immediately disconnect of the handshake fails. It should be possible to log those failures although getting those entries into the access log would be a little trickier but not too bad looking at the source. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how to log unauthorized https access attempts (secure=true clientAuth=true)
Thx for response, Will it be developed in next releases of tomcat 7? Or it won't because there is no such need, and such issues should be handled some other way? If some other way is recommended, than how should such functionality be handled? Regards Jakub On Fri, Aug 23, 2013 at 1:09 PM, Mark Thomas ma...@apache.org wrote: On 23/08/2013 11:02, Ja kub wrote: Hallo I use https with client cert authentication Connector protocol=...Http11NioProtocol SSLEnabled=true scheme=https secure=true clientAuth=true sslProtocol=TLS keystoreFile=...jks key..Pass=... keystoreType=JKS truststoreFile=...jks trust..Pass=.. / AccessLogValve cannot be placed inservice, only in engine (host, context), but if client has bad/untrusted cert or no cert at all, possibly connector doesn't pass him to engine and to AccessLogValve. How can I log such access attempts with tomcat ? Out of the box there is no way to do this. There are a couple of ways you might do this with some custom code. You could implement a custom trust manager that logged failures although even then, the trust manager doesn't have access to the connection so you can't log IP address and the like. You could also modify the Tomcat connector code. All the endpoints trigger the handshake and then immediately disconnect of the handshake fails. It should be possible to log those failures although getting those entries into the access log would be a little trickier but not too bad looking at the source. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how to log unauthorized https access attempts (secure=true clientAuth=true)
On 23/08/2013 12:28, Ja kub wrote: Thx for response, Will it be developed in next releases of tomcat 7? There are currently no plans to do so. Or it won't because there is no such need, and such issues should be handled some other way? It is simply a case that, to date, no one has wanted to solve this problem. Enhancement requests may be added to Bugzilla. As always, enhancement requests with patches tend to get implemented a lot faster than those without. Mark If some other way is recommended, than how should such functionality be handled? Regards Jakub On Fri, Aug 23, 2013 at 1:09 PM, Mark Thomas ma...@apache.org wrote: On 23/08/2013 11:02, Ja kub wrote: Hallo I use https with client cert authentication Connector protocol=...Http11NioProtocol SSLEnabled=true scheme=https secure=true clientAuth=true sslProtocol=TLS keystoreFile=...jks key..Pass=... keystoreType=JKS truststoreFile=...jks trust..Pass=.. / AccessLogValve cannot be placed inservice, only in engine (host, context), but if client has bad/untrusted cert or no cert at all, possibly connector doesn't pass him to engine and to AccessLogValve. How can I log such access attempts with tomcat ? Out of the box there is no way to do this. There are a couple of ways you might do this with some custom code. You could implement a custom trust manager that logged failures although even then, the trust manager doesn't have access to the connection so you can't log IP address and the like. You could also modify the Tomcat connector code. All the endpoints trigger the handshake and then immediately disconnect of the handshake fails. It should be possible to log those failures although getting those entries into the access log would be a little trickier but not too bad looking at the source. 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: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings?
On 22/08/2013 19:32, Bob DeRemer wrote: I’m in the process of developing a configurable server application which must handle various protocols, but the respective endpoints must be configurable. Specifically, I would like to programmatically add both HTTP servlet(s) as well as WebSocket Servlets/Endpoints during the contextInitialized call [based on our own configuration settings], as opposed to having all servlets in web.xml or annotated classes loaded automatically. Is this possible in Tomcat 7; and, if yes, are there any examples? I know the Endpoint aspect of the question depends on JSR-356 being back-ported. Yes, it is possible. There are some examples in the unit tests: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/TestStandardContext.java?view=annotate Look for calls to addServlet(...) Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings?
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, August 23, 2013 8:14 AM To: Tomcat Users List Subject: Re: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings? On 22/08/2013 19:32, Bob DeRemer wrote: I'm in the process of developing a configurable server application which must handle various protocols, but the respective endpoints must be configurable. Specifically, I would like to programmatically add both HTTP servlet(s) as well as WebSocket Servlets/Endpoints during the contextInitialized call [based on our own configuration settings], as opposed to having all servlets in web.xml or annotated classes loaded automatically. Is this possible in Tomcat 7; and, if yes, are there any examples? I know the Endpoint aspect of the question depends on JSR-356 being back-ported. Yes, it is possible. There are some examples in the unit tests: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/Test StandardContext.java?view=annotate Look for calls to addServlet(...) Great! So, how do I tell Tomcat NOT to load anything in the first place? Can I still use Annotation on my servlets, or will I have to use an interface-based approach? Also, how about for the JSR-356 Endpoints? Is there an addEndpoint(...) call? -thx again 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: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings?
On 23/08/2013 13:28, Bob DeRemer wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, August 23, 2013 8:14 AM To: Tomcat Users List Subject: Re: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings? On 22/08/2013 19:32, Bob DeRemer wrote: I'm in the process of developing a configurable server application which must handle various protocols, but the respective endpoints must be configurable. Specifically, I would like to programmatically add both HTTP servlet(s) as well as WebSocket Servlets/Endpoints during the contextInitialized call [based on our own configuration settings], as opposed to having all servlets in web.xml or annotated classes loaded automatically. Is this possible in Tomcat 7; and, if yes, are there any examples? I know the Endpoint aspect of the question depends on JSR-356 being back-ported. Yes, it is possible. There are some examples in the unit tests: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/Test StandardContext.java?view=annotate Look for calls to addServlet(...) Great! So, how do I tell Tomcat NOT to load anything in the first place? Exclude the JARs containing the Servlets with an absolute-ordering in web.xml Can I still use Annotation on my servlets, or will I have to use an interface-based approach? I don't believe @WebServlet has any effect when adding Servlets via addServlet() Also, how about for the JSR-356 Endpoints? Is there an addEndpoint(...) call? Yes on ServerContainer, as long as you do it before any of them are used. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 Websocket API - Cookies Headers
Thanks very much for the quick response Niki! I went down the configurator path too, but then I could not find a way to pass the cookie values into the ServerEndPoint.onOpen where I need to use it. I tried passing it via session.getRequestParameterMap() but that is a Collections.unmodifiableMap(). In my scenario the session.getHttpSession() is NULL so I can't put it in there. I didn't like the idea of putting it in ThreadLocal (unless I am guaranteed by the spec that ServerEndPoint.onOpen is always called on the same thread that processes the handshake). That was when I started thinking I must be missing something simple. Any suggestions? Thanks, Todd On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com wrote: On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote: I'm trying to figure out how to get access to the cookies and headers passed up in the Websocket handshake request on Tomcat 8. In Tomcat 7 the whole HttpServletRequest was passed into the WebSocketServlet. createWebSocketInbound method so it was easy to grab from the request headers. In Tomcat 8 the querystring and URI are both exposed by the javax.websocket.Session passed to ServerEndPoint.onOpen, but I don't see a mechanism for getting the cookies or headers. You can supply an extension of http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html and get http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html through modifyHandshake invoked by the container during processing of client 'GET' handshake message. Handshake request containes methods for inspecting the http request parameters and headers. We are integrating Websocket connections into an existing web app and want to use the cookies set by our web app in the Websocket connection process. Thanks for any insight. Todd - 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: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings?
http://www.gizmag.com/helmmate-bicycle-helmet-seat-cover/28798/ LaMont Spencer - ITCC - Contractor McCallie Assoc. J646 Mid - Tier Support Comm:232-1733 | DSN:272-1733 -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, August 23, 2013 7:40 AM To: Tomcat Users List Subject: Re: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings? On 23/08/2013 13:28, Bob DeRemer wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, August 23, 2013 8:14 AM To: Tomcat Users List Subject: Re: is it possible to dynamically add servlets and websocket endpoints during startup based on our own configuration settings? On 22/08/2013 19:32, Bob DeRemer wrote: I'm in the process of developing a configurable server application which must handle various protocols, but the respective endpoints must be configurable. Specifically, I would like to programmatically add both HTTP servlet(s) as well as WebSocket Servlets/Endpoints during the contextInitialized call [based on our own configuration settings], as opposed to having all servlets in web.xml or annotated classes loaded automatically. Is this possible in Tomcat 7; and, if yes, are there any examples? I know the Endpoint aspect of the question depends on JSR-356 being back-ported. Yes, it is possible. There are some examples in the unit tests: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/co re/Test StandardContext.java?view=annotate Look for calls to addServlet(...) Great! So, how do I tell Tomcat NOT to load anything in the first place? Exclude the JARs containing the Servlets with an absolute-ordering in web.xml Can I still use Annotation on my servlets, or will I have to use an interface-based approach? I don't believe @WebServlet has any effect when adding Servlets via addServlet() Also, how about for the JSR-356 Endpoints? Is there an addEndpoint(...) call? Yes on ServerContainer, as long as you do it before any of them are used. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org smime.p7s Description: S/MIME cryptographic signature
Re: Tomcat 8 Websocket API - Cookies Headers
On Fri, Aug 23, 2013 at 7:03 PM, toddfas todd...@gmail.com wrote: Thanks very much for the quick response Niki! I went down the configurator path too, but then I could not find a way to pass the cookie values into the ServerEndPoint.onOpen where I need to use it. I tried passing it via session.getRequestParameterMap() but that is a Collections.unmodifiableMap(). In my scenario the session.getHttpSession() is NULL so I can't put it in there. I didn't like the idea of putting it in ThreadLocal (unless I am guaranteed by the spec that ServerEndPoint.onOpen is always called on the same thread that processes the handshake). That was when I started thinking I must be missing something simple. Any suggestions? Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It designates an established connection and that means you are already in the websocket world. I don;t see an easy way for doing this. Can you describe the use case in greater details. What problem do you solve by having access to the handshale request headers (incl cookies) in that phase? Thanks, Todd On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com wrote: On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote: I'm trying to figure out how to get access to the cookies and headers passed up in the Websocket handshake request on Tomcat 8. In Tomcat 7 the whole HttpServletRequest was passed into the WebSocketServlet. createWebSocketInbound method so it was easy to grab from the request headers. In Tomcat 8 the querystring and URI are both exposed by the javax.websocket.Session passed to ServerEndPoint.onOpen, but I don't see a mechanism for getting the cookies or headers. You can supply an extension of http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html and get http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html through modifyHandshake invoked by the container during processing of client 'GET' handshake message. Handshake request containes methods for inspecting the http request parameters and headers. We are integrating Websocket connections into an existing web app and want to use the cookies set by our web app in the Websocket connection process. Thanks for any insight. Todd - 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: Tomcat 8 Websocket API - Cookies Headers
Our existing web app has custom session management (does not use JSESSIONID) and stores the session identifier in a cookie. The cookie is marked httpOnly (and secure) so the client side Javascript opening the websocket does not have access to it. I want to use this session identifier in ServerEndPoint.onOpen to verify the user attempting to open the Websocket connection and then be able to keep track of the user's context as messages are received and sent over websocket. Thanks for any additional ideas on how to accomplish this. Todd On Fri, Aug 23, 2013 at 10:08 AM, Niki Dokovski nick...@gmail.com wrote: On Fri, Aug 23, 2013 at 7:03 PM, toddfas todd...@gmail.com wrote: Thanks very much for the quick response Niki! I went down the configurator path too, but then I could not find a way to pass the cookie values into the ServerEndPoint.onOpen where I need to use it. I tried passing it via session.getRequestParameterMap() but that is a Collections.unmodifiableMap(). In my scenario the session.getHttpSession() is NULL so I can't put it in there. I didn't like the idea of putting it in ThreadLocal (unless I am guaranteed by the spec that ServerEndPoint.onOpen is always called on the same thread that processes the handshake). That was when I started thinking I must be missing something simple. Any suggestions? Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It designates an established connection and that means you are already in the websocket world. I don;t see an easy way for doing this. Can you describe the use case in greater details. What problem do you solve by having access to the handshale request headers (incl cookies) in that phase? Thanks, Todd On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com wrote: On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote: I'm trying to figure out how to get access to the cookies and headers passed up in the Websocket handshake request on Tomcat 8. In Tomcat 7 the whole HttpServletRequest was passed into the WebSocketServlet. createWebSocketInbound method so it was easy to grab from the request headers. In Tomcat 8 the querystring and URI are both exposed by the javax.websocket.Session passed to ServerEndPoint.onOpen, but I don't see a mechanism for getting the cookies or headers. You can supply an extension of http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html and get http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html through modifyHandshake invoked by the container during processing of client 'GET' handshake message. Handshake request containes methods for inspecting the http request parameters and headers. We are integrating Websocket connections into an existing web app and want to use the cookies set by our web app in the Websocket connection process. Thanks for any insight. Todd - 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: Mapping security role outside of servlet specification
Am 11.06.2013 19:42, schrieb Felix Schumacher:
Am 05.06.2013 13:42, schrieb Ilya Kazakevich:
Hello,
I use probe app for several tomcats.
It's security model is based on servlet API security: security roles and
constraints are provided in web.xml and mapped for each servlet it has.
I use JNDIRealm to authenticate users via LDAP (actually AD is used).
I want to grant access to Probe on Tomcat1' installation for people from
Group1 and to Tomcat2 to people from Group2.
But manager group is hard-coded in web.xml inside of probe!
I want to map group Group1 from LDAP realm to role manager in tomcat.
How can I do that?
I can't use security-role-ref because I should put in servlet tag,
so I
can't
do that on tomcat level.
There is security-role-mapping tag in some servers but it is
proprietary
and not supported by tomcat.
So the only way for me to extract .war file and patch web.xml.
That is the way, we do it at work. For probe, that is.
For other applications we are using different Attributes in the ldap
group objects to map to different names for the role.
Greetings
Felix
What is the best way to solve it?
Ilya.
What would be the best way to do this on the tomcat level? I would like
to add a simple mapping.properties to our tomcat installations
containing the individual mappings in the form of security-role=jndi-role.
I see multiple options:
1. create a nestable realm to wrap around the JNDIRealm (Tomcat7)
2. create an own realm extending JNDIRealm
3. provide a patch to JNDIRealm
pseudo-code for overriding hasRole could be like this
public boolean hasRole(..) {
String mappedRole = mapping.getProperty(role);
if((mappedRole != null) super.hasRole(..,mappedRole)) {
return true;
} else {
return false;
}
}
I'm not sure wether it is also required to override the authenticate
methods which return the principal object.
Any recommendations?
Stefan
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 Websocket API - Cookies Headers
In the modifyHandshake method of your Configurator, you can call
getUserProperties on the EndpointConfig argument. This returns a modifiable
MapString, Object that you can add values to. After modifyHandshake returns
and before onOpen is called, the values from that map are copied to the
Session, and you can retrieve them by calling Session#getUserProperties().
That's how I'm passing Cookie and HttpSession objects into my endpoints' onOpen
methods. For example:
public class MyConfigurator extends ServerEndpointConfig.Configurator {
public void modifyHandshake(ServerEndpointConfig config, HandshakeRequest
request, HandshakeResponse response) {
super.modifyHandshake(config, request, response);
config.getUserProperties.put(httpSessionObject,
request.getHttpSession());
}
}
Then later:
@OnOpen
public void onOpen(Session session) {
HttpSession httpSession = (HttpSession)
session.getUserProperties().get(httpSessionObject);
}
It ain't pretty. IMO, it was a serious design flaw in the spec not to provide
ways to get the HttpSession and Cookies from the Session object. Maybe I'll try
to get on the EG for the next version. :-)
N
On Aug 23, 2013, at 1:01 PM, toddfas wrote:
Our existing web app has custom session management (does not use
JSESSIONID) and stores the session identifier in a cookie. The cookie is
marked httpOnly (and secure) so the client side Javascript opening the
websocket does not have access to it. I want to use this session identifier
in ServerEndPoint.onOpen to verify the user attempting to open the
Websocket connection and then be able to keep track of the user's context
as messages are received and sent over websocket.
Thanks for any additional ideas on how to accomplish this.
Todd
On Fri, Aug 23, 2013 at 10:08 AM, Niki Dokovski nick...@gmail.com wrote:
On Fri, Aug 23, 2013 at 7:03 PM, toddfas todd...@gmail.com wrote:
Thanks very much for the quick response Niki!
I went down the configurator path too, but then I could not find a way
to pass the cookie values into the ServerEndPoint.onOpen where I need
to use it. I tried passing it via session.getRequestParameterMap() but
that is a Collections.unmodifiableMap(). In my scenario the
session.getHttpSession() is NULL so I can't put it in there. I didn't
like the idea of putting it in ThreadLocal (unless I am guaranteed by
the spec that ServerEndPoint.onOpen is always called on the same
thread that processes the handshake).
That was when I started thinking I must be missing something simple.
Any suggestions?
Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It
designates an established connection and that means you are already in the
websocket world. I don;t see an easy way for doing this. Can you describe
the use case in greater details. What problem do you solve by having access
to the handshale request headers (incl cookies) in that phase?
Thanks,
Todd
On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com
wrote:
On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote:
I'm trying to figure out how to get access to the cookies and headers
passed up in the Websocket handshake request on Tomcat 8.
In Tomcat 7 the whole HttpServletRequest was passed into the
WebSocketServlet. createWebSocketInbound method so it was easy to grab
from the request headers. In Tomcat 8 the querystring and URI are both
exposed by the javax.websocket.Session passed to
ServerEndPoint.onOpen, but I don't see a mechanism for getting the
cookies or headers.
You can supply an extension of
http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
and get
http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
through
modifyHandshake invoked by the container during processing of client
'GET'
handshake message. Handshake request containes methods for inspecting
the
http request parameters and headers.
We are integrating Websocket connections into an existing web app and
want to use the cookies set by our web app in the Websocket connection
process.
Thanks for any insight.
Todd
-
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: Tomcat 8 Websocket API - Cookies Headers
On Aug 23, 2013, at 1:25 PM, Nick Williams wrote:
In the modifyHandshake method of your Configurator, you can call
getUserProperties on the EndpointConfig argument. This returns a modifiable
MapString, Object that you can add values to. After modifyHandshake returns
and before onOpen is called, the values from that map are copied to the
Session, and you can retrieve them by calling Session#getUserProperties().
That's how I'm passing Cookie and HttpSession objects into my endpoints'
onOpen methods. For example:
public class MyConfigurator extends ServerEndpointConfig.Configurator {
public void modifyHandshake(ServerEndpointConfig config, HandshakeRequest
request, HandshakeResponse response) {
super.modifyHandshake(config, request, response);
config.getUserProperties.put(httpSessionObject,
request.getHttpSession());
}
}
Then later:
@OnOpen
public void onOpen(Session session) {
HttpSession httpSession = (HttpSession)
session.getUserProperties().get(httpSessionObject);
}
It ain't pretty. IMO, it was a serious design flaw in the spec not to provide
ways to get the HttpSession and Cookies from the Session object. Maybe I'll
try to get on the EG for the next version. :-)
N
On Aug 23, 2013, at 1:01 PM, toddfas wrote:
Our existing web app has custom session management (does not use
JSESSIONID) and stores the session identifier in a cookie. The cookie is
marked httpOnly (and secure) so the client side Javascript opening the
websocket does not have access to it. I want to use this session identifier
in ServerEndPoint.onOpen to verify the user attempting to open the
Websocket connection and then be able to keep track of the user's context
as messages are received and sent over websocket.
Thanks for any additional ideas on how to accomplish this.
Todd
On Fri, Aug 23, 2013 at 10:08 AM, Niki Dokovski nick...@gmail.com wrote:
On Fri, Aug 23, 2013 at 7:03 PM, toddfas todd...@gmail.com wrote:
Thanks very much for the quick response Niki!
I went down the configurator path too, but then I could not find a way
to pass the cookie values into the ServerEndPoint.onOpen where I need
to use it. I tried passing it via session.getRequestParameterMap() but
that is a Collections.unmodifiableMap(). In my scenario the
session.getHttpSession() is NULL so I can't put it in there. I didn't
like the idea of putting it in ThreadLocal (unless I am guaranteed by
the spec that ServerEndPoint.onOpen is always called on the same
thread that processes the handshake).
That was when I started thinking I must be missing something simple.
Any suggestions?
Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It
designates an established connection and that means you are already in the
websocket world. I don;t see an easy way for doing this. Can you describe
the use case in greater details. What problem do you solve by having access
to the handshale request headers (incl cookies) in that phase?
Thanks,
Todd
On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com
wrote:
On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote:
I'm trying to figure out how to get access to the cookies and headers
passed up in the Websocket handshake request on Tomcat 8.
In Tomcat 7 the whole HttpServletRequest was passed into the
WebSocketServlet. createWebSocketInbound method so it was easy to grab
from the request headers. In Tomcat 8 the querystring and URI are both
exposed by the javax.websocket.Session passed to
ServerEndPoint.onOpen, but I don't see a mechanism for getting the
cookies or headers.
You can supply an extension of
http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
and get
http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
through
modifyHandshake invoked by the container during processing of client
'GET'
handshake message. Handshake request containes methods for inspecting
the
http request parameters and headers.
We are integrating Websocket connections into an existing web app and
want to use the cookies set by our web app in the Websocket connection
process.
Thanks for any insight.
Todd
I'm sorry I top-posted! Didn't mean to. :-)
Nick
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Having trouble with common.loader
On Thu, Aug 22, 2013 at 2:51 PM, Konstantin Kolinko
knst.koli...@gmail.comwrote:
2013/8/22 D C dc12...@gmail.com:
On Thu, Aug 22, 2013 at 11:48 AM, Konstantin Kolinko
knst.koli...@gmail.com
wrote:
2013/8/22 Daniel Mikusa dmik...@gopivotal.com:
On Aug 21, 2013, at 4:09 PM, David kerber dcker...@verizon.net
wrote:
Basically you're trying to defeat the way the system is designed to
work. Don't do that…
+1 Don't do what you've described unless you have a very good reason.
It will cause you many headaches.
Keep all of your JAR files in WEB-INF/lib, with the exception of
JDBC
drivers. Put those in $CATALINA_BASE/lib.
Dan
1.
+1.
Adding webapp libraries to the common classloader (by placing them
into ${catalina.base}/lib or by modifying the definition of
common.loader) is a bad idea.
(as documented and as discussed many times on this mailing list)
IF you want to decouple libraries from your war, add them to your
webapp's classpath, by configuring a VirtualWebappLoader ,
http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#VirtualWebappLoader_Implementation
Interesting. I just tried this out, but I'm not having luck.
We load the context of the app from
$catalina_home/conf/Catalina/localhost/myApp.xml
I tried adding the Loader to my context so it looks like this. Am I
doing
something wrong.
?xml version='1.0' encoding='utf-8'?
Context
Loader className=org.apache.catalina.loader.VirtualWebappLoader
virtualClasspath=/web/lib;/web/lib/*.jar/
Looks OK, if those paths are correct.
You can enable debug logging for that class and it will list whatever
jars it finds.
Is the following shell command able to list your jar files?
ls /web/lib/
# su - tomcat -s /bin/bash
-bash-4.1$ ls /web/lib/
adcenter_live_base-20070831.jar c3p0-0.9.1.jar
commons-httpclient-3.0.1.jar jakarta-oro-2.0.8.jar
spring-beans-3.1.0.RELEASE.jar wsdl4j-1.5.1.jar
amqp-client-2.8.0.jarcommons-beanutils-1.7.0.jar
commons-lang-2.4.jar jaxrpc-api-1.1.jar
spring-context-3.1.0.RELEASE.jar xml-apis-1.0.b2.jar
aopalliance-1.0.jar commons-codec-1.3.jar
commons-logging-1.0.4.jar log4j-1.2.16.jar
spring-core-3.1.0.RELEASE.jar
Ask-3.0.jar commons-collections-2.1.jar
commons-math3-3.0.jar memcached-client-20120227.jar
spring-expression-3.1.0.RELEASE.jar
axis-1.3.jar commons-dbcp-1.2.2.jar
commons-pool-1.3.jar mysql-connector-java-5.1.10.jar
spring-jdbc-3.1.0.RELEASE.jar
axis-jaxrpc-1.3.jar commons-digester-1.6.jar
commons-validator-1.3.1.jar spring-aop-3.1.0.RELEASE.jar
spring-tx-3.1.0.RELEASE.jar
axis-saaj-1.3.jarcommons-discovery-0.2.jar
geoApi-20080422.jar spring-asm-3.1.0.RELEASE.jar
spring-web-3.1.0.RELEASE.jar
/opt/tomcat-6.0.35
/opt/tomcat-7.0.39
/opt/tomcat-7.0.40
/tomcat symlinks to which ever /opt/tomcat-7.0.40
You are using 7.0.40, 7.0.42, or some ancient version?
7.0.40 and 7.0.42
For the sake of testing, i'll stick to 7.0.42.
Do you know how configure Tomcat with separate $CATALINA_BASE and
$CATALINA_HOME?
I didn't specifically do that. This is what i did:
server.xml:
Host name=localhost appBase=/web/webapps
logging.properties:
replaced all instances of ${catalina.base}/logs with /web/logs.
- this actually didn't work. but im not dwelling on it right now.
Do they have the same value for you, or different ones? (As printed by
catalina.sh just before Tomcat starts).
Using CATALINA_BASE: /tomcat
Using CATALINA_HOME: /tomcat
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0 logging on different platforms
I've deleted any reference in logging.properties to the console. However
the file rm'd catalina.out file still coming back on restarts. Any ideas?
catalina,out is now also reporting java.util.logging.ErrorManager: 4:
Unable to create [logs]
Below is my altered logging.properties file:
__
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4host-manager.org.apache.juli.FileHandler
.handlers = 1catalina.org.apache.juli.FileHandler
# Handler specific properties.
# Describes specific configuration info for Handlers.
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.
# Facility specific properties.
# Provides extra control for each logger.
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
2localhost.org.apache.juli.FileHandler
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers
= 3manager.org.apache.juli.FileHandler
# For example, set the org.apache.catalina.util.LifecycleBase logger to log
# each component that extends LifecycleBase changing state:
#org.apache.catalina.util.LifecycleBase.level = FINE
# To see debug messages in TldLocationsCache, uncomment the following line:
#org.apache.jasper.compiler.TldLocationsCache.level = FINE
# For memcached session manager
de.javakaffee.web.msm.level = WARNING
On Thu, Aug 22, 2013 at 11:52 AM, Konstantin Kolinko knst.koli...@gmail.com
wrote:
2013/8/22 Tomcat Random tomcat.ran...@gmail.com:
My development setup is Win7 while my production is RHEL6. Both of the
environments have the same settings in conf/logging.properties but the
files in logs/ are slightly different.
The access logs are named the same way. but on RHEL there's no
tomcat7-stdout or tomcat7-stderr log files. Just
'catalina.out.YEAR.MO.DY'
and the cumulative catalina.out with no date.
What accounts for the differences?
catalina.sh redirects stderr to stdout with 21 and logs them to the same
file
Windows service wrapper (Apache Commons Daemon procrun) logs them to
separate files.
Also, how would you stop logging to the 'catalina.out' file. It gets
unusably gigantic within a few days.
Just do not write to the console.
http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Considerations_for_productive_usage
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms
Thanks for clarifying the JSSE issue. It's a shame that JSSE can't make
use of available JCE algorithms. I've just been trying to establish the
limits of the Java 7 implementation, and I think I understand that now.
Yes, the ECDHE ciphersuites are definitely the choice for strongest
secrecy with good performance, and the
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 that works on Oracle Java 7 using
TLS 1.2 should be a reasonable choice for now (or
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256, for those who want really big keys).
- Dennis
On 08/23/2013 10:06 PM, Aurélien Terrestris wrote:
Hi
the JSSE Reference Guide defines which possibilities for anyone
implementing a JSSE provider (let's call it an API if you want).
Oracle's provider only implements a part of this API, misleading you
to believe SHA384 is available when it's unfortunately not.
About Bouncy Castle, I believe they only implement a JCE provider and
not any JSSE provider. Adding their jar to your providers in the
security file is not enough.. you would have to implement a full JSSE
provider using their JCE classes. A lot of work.
If you're looking for the best security, I would tell you to use the
available DHE and ECDHE ciphersuites which make things complicated to
decrypt. Have a look here for more information :
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
RFC 5288 is interesting, we probably have to wait some more years
before we can use all these new ciphers.
best regards
A.T.
2013/8/23 Dennis Sosnoski d...@sosnoski.com:
Thanks, Aurélien. I'd seen the SHA384 versions listed in the JSSE Cipher
Suite Names and thought they were available:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites
I was really hoping to use one of the GCM suites, but I gather those are not
officially approved yet either: http://tools.ietf.org/html/rfc5288 It
appears there is growing support for these in the world, even if they're not
yet an official part of TLS 1.2.
On the client side, this:
SSLContext context = SSLContext.getInstance(TLS);
context.init(null, new TrustManager[] { tm }, null);
SSLParameters params = context.getSupportedSSLParameters();
String[] suites = params.getCipherSuites();
System.out.println(Connecting with + suites.length + cipher
suites supported:);
for (int i = 0; i suites.length; i++) {
System.out.print(' ');
System.out.println(suites[i]);
}
gives me a list of supported cipher suites including:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
...
but when I try to connect using the socket factory from the context I get
the ssl debug information:
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
...
where all the variations using SHA256 or SHA384 are in this second list. But
explicitly setting a suite like:
System.setProperty(https.cipherSuites,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256);
works, while the SHA384 version fails with Unsupported ciphersuite (as
does any version I've tried using GCM in place of CBC).
I thought JSSE would use the JCE algorithms from BouncyCastle, but it looks
like this doesn't work. I'll have to dig into the JSSE code to see what's
going wrong on that part.
- Dennis
On 08/23/2013 03:48 AM, Aurélien Terrestris wrote:
According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
http://www.ietf.org/rfc/rfc5246.txt
The JSSE Reference Guide also doesn't talk about this SHA384 as an
implementation requirement. See :
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl
This means you have a problem with SHA256 only. Maybe it's easier to
test on client-side, with one of the following ciphers (that you find
on the same Reference Guide ) for example :
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Let me know if this works, or I will try to test by myself with my own
client.
2013/8/22 Dennis Sosnoski d...@sosnoski.com:
I've already done that, though as far as I can see that doesn't effect
the
digest algorithms (only the encryption options).
- Dennis
On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:
Hello
I suppose you need to run your JVM with the unrestricted policy files
(on
b=
oth client and server sides). You have to download them from Oracle
website=
for your java version, and replace the old.
Re: Tomcat 8 EL 3.0 Issue
On 20/08/2013 16:46, Daniel Mikusa wrote:
Hello,
I'm seeing some perplexing errors with a couple simple EL test.
Dan,
These look like bugs.
I've taken a quick look at the first and it is fixable if we copy the
smarter method finding code from ReflectionUtil in the implementation to
the Util class in the API. I'd like to avoid that much copying if I can
but I don't see an immediate way around it without creating unwanted
dependencies.
The second issue will require a little more work as there isn't an
equivalent constructor finding method that can just be copied.
It will probably be possible to share rather than duplicate code for the
method and the constructor matching.
To add to the fun, I recall some sensitivities in the EL TCK around the
method matching. We are going to have to tread carefully.
Please can you create a Bugzilla issue for these.
Thanks,
Mark
1.) Here's the first test.
@Test
public void test01() {
ELProcessor processor = new ELProcessor();
processor.defineBean(sb, new StringBuilder());
Assert.assertEquals(a, processor.eval(sb.append('a');
sb.toString()));
}
This fails with the following stack trace.
javax.el.ELException: Cannot convert a of type class java.lang.String to long
at org.apache.el.lang.ELSupport.coerceToNumber(ELSupport.java:349)
at org.apache.el.lang.ELSupport.coerceToNumber(ELSupport.java:328)
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:450)
at
org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:48)
at javax.el.Util.buildParameters(Util.java:351)
at javax.el.BeanELResolver.invoke(BeanELResolver.java:173)
at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:84)
at org.apache.el.parser.AstValue.getValue(AstValue.java:157)
at org.apache.el.parser.AstSemicolon.getValue(AstSemicolon.java:35)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
at javax.el.ELProcessor.getValue(ELProcessor.java:45)
at javax.el.ELProcessor.eval(ELProcessor.java:38)
at
org.apache.el.parser.TestAstMethodCalls.test01(TestAstMethodCalls.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Looking into this, it appears that the EL is having trouble because
StringBuilder's append method is overloaded. It is instructed to call append
with the character 'c', but instead is trying to coerce the character 'c' to
a long and call append with the long.
This chain of events seems to be kicked off in AstValue.getValue() line #157,
where it's calling resolver.invoke(..). The call to resolver.invoke() is
passing null as the paramTypes argument. This trickles down to
BeanELResolver.invoke(), which calls Util.findMethod(). Because paramTypes
is null, Util.findMethod() selects the first method it finds with the
expected number of arguments. In the case above, it selects
StringBuilder.append(long), which causes the problem above.
2.) Here's
Re: Mapping security role outside of servlet specification
Am 23.08.2013 20:10, schrieb Stefan Mayr:
Am 11.06.2013 19:42, schrieb Felix Schumacher:
Am 05.06.2013 13:42, schrieb Ilya Kazakevich:
Hello,
I use probe app for several tomcats.
It's security model is based on servlet API security: security roles and
constraints are provided in web.xml and mapped for each servlet it has.
I use JNDIRealm to authenticate users via LDAP (actually AD is used).
I want to grant access to Probe on Tomcat1' installation for people
from
Group1 and to Tomcat2 to people from Group2.
But manager group is hard-coded in web.xml inside of probe!
I want to map group Group1 from LDAP realm to role manager in
tomcat.
How can I do that?
I can't use security-role-ref because I should put in servlet tag,
so I
can't
do that on tomcat level.
There is security-role-mapping tag in some servers but it is
proprietary
and not supported by tomcat.
So the only way for me to extract .war file and patch web.xml.
That is the way, we do it at work. For probe, that is.
For other applications we are using different Attributes in the ldap
group objects to map to different names for the role.
Greetings
Felix
What is the best way to solve it?
Ilya.
What would be the best way to do this on the tomcat level? I would like
to add a simple mapping.properties to our tomcat installations
containing the individual mappings in the form of
security-role=jndi-role.
I see multiple options:
1. create a nestable realm to wrap around the JNDIRealm (Tomcat7)
2. create an own realm extending JNDIRealm
3. provide a patch to JNDIRealm
pseudo-code for overriding hasRole could be like this
public boolean hasRole(..) {
String mappedRole = mapping.getProperty(role);
if((mappedRole != null) super.hasRole(..,mappedRole)) {
return true;
} else {
return false;
}
}
I'm not sure wether it is also required to override the authenticate
methods which return the principal object.
Any recommendations?
Stefan
I've created a bugzilla entry and attached a prototype for option 1:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55477
I only tested with a UserDatabaseRealm so far. I hope to find some time
at work to test it with a JNDIRealm.
Stefan
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 Websocket API - Cookies Headers
On Fri, Aug 23, 2013 at 11:25 AM, Nick Williams
nicho...@nicholaswilliams.net wrote:
In the modifyHandshake method of your Configurator, you can call
getUserProperties on the EndpointConfig argument. This returns a modifiable
MapString, Object that you can add values to. After modifyHandshake
returns and before onOpen is called, the values from that map are copied to
the Session, and you can retrieve them by calling
Session#getUserProperties(). That's how I'm passing Cookie and HttpSession
objects into my endpoints' onOpen methods. For example:
public class MyConfigurator extends ServerEndpointConfig.Configurator {
public void modifyHandshake(ServerEndpointConfig config,
HandshakeRequest request, HandshakeResponse response) {
super.modifyHandshake(config, request, response);
config.getUserProperties.put(httpSessionObject,
request.getHttpSession());
}
}
Then later:
@OnOpen
public void onOpen(Session session) {
HttpSession httpSession = (HttpSession)
session.getUserProperties().get(httpSessionObject);
}
It ain't pretty. IMO, it was a serious design flaw in the spec not to
provide ways to get the HttpSession and Cookies from the Session object.
Maybe I'll try to get on the EG for the next version. :-)
N
On Aug 23, 2013, at 1:01 PM, toddfas wrote:
Our existing web app has custom session management (does not use
JSESSIONID) and stores the session identifier in a cookie. The cookie is
marked httpOnly (and secure) so the client side Javascript opening the
websocket does not have access to it. I want to use this session
identifier
in ServerEndPoint.onOpen to verify the user attempting to open the
Websocket connection and then be able to keep track of the user's context
as messages are received and sent over websocket.
Thanks for any additional ideas on how to accomplish this.
Todd
On Fri, Aug 23, 2013 at 10:08 AM, Niki Dokovski nick...@gmail.com
wrote:
On Fri, Aug 23, 2013 at 7:03 PM, toddfas todd...@gmail.com wrote:
Thanks very much for the quick response Niki!
I went down the configurator path too, but then I could not find a way
to pass the cookie values into the ServerEndPoint.onOpen where I need
to use it. I tried passing it via session.getRequestParameterMap() but
that is a Collections.unmodifiableMap(). In my scenario the
session.getHttpSession() is NULL so I can't put it in there. I didn't
like the idea of putting it in ThreadLocal (unless I am guaranteed by
the spec that ServerEndPoint.onOpen is always called on the same
thread that processes the handshake).
That was when I started thinking I must be missing something simple.
Any suggestions?
Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It
designates an established connection and that means you are already in
the
websocket world. I don;t see an easy way for doing this. Can you
describe
the use case in greater details. What problem do you solve by having
access
to the handshale request headers (incl cookies) in that phase?
Thanks,
Todd
On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski nick...@gmail.com
wrote:
On Fri, Aug 23, 2013 at 2:58 AM, toddfas todd...@gmail.com wrote:
I'm trying to figure out how to get access to the cookies and headers
passed up in the Websocket handshake request on Tomcat 8.
In Tomcat 7 the whole HttpServletRequest was passed into the
WebSocketServlet. createWebSocketInbound method so it was easy to
grab
from the request headers. In Tomcat 8 the querystring and URI are
both
exposed by the javax.websocket.Session passed to
ServerEndPoint.onOpen, but I don't see a mechanism for getting the
cookies or headers.
You can supply an extension of
http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
and get
http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
through
modifyHandshake invoked by the container during processing of client
'GET'
handshake message. Handshake request containes methods for inspecting
the
http request parameters and headers.
We are integrating Websocket connections into an existing web app and
want to use the cookies set by our web app in the Websocket
connection
process.
Thanks for any insight.
Todd
-
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:
