SingleSignOn valve in combination with SPNego
Hello all, We are encountering an issue with the use of the SingleSignOn valve and SPNego and are looking for a best practice on this. Let me describe our situation; Our suite consists of multiple end-user webapplications but also a few webapplications that accept interaction from other systems. Authentication from other systems is always done on a BASIC authentication basis, using username/password. For the end-user webapplications the method of authentication and authorization (Valve and Realm) is configurable in the application specific realms. The end-user applications are closely related so we use the SingleSignOn valve at global (server.xml) level to share end-user 'logins'. To make sure that users who succesfully authenticated by an end-user webapplication cannot access the webapplications for external systems, the SingleSignOn valve has requireReauthentication set to true. This way a user can only access the applications for which the username/credential matches. Now, when we configure SPNego, we have to have a realm for that web application that always grants the user access, as the authentication for SPNego is performed completely in the valve. But when a user who authenticated in a non-SPNego web application tries to access the SPNego web application, the realm will also allow that user. This is a problematic situation. Maybe we could prevent this with the role mechanism, but in some cases we like to use the tomcatAuthentication=false on the AJP connector, and in those cases a role would complicate things. Any ideas? Regards, Maarten
Re: Regarding i think an intrusion - Solved =)
Hello all.
We internally had closed the issue. So i can tell you thanks a lot you rock
=)
Thank for all your effort and time.
Kindly yours,
Leonardo
Saludos.-
Leonardo Santagostini
http://ar.linkedin.com/in/santagostini
2014-05-26 15:32 GMT-03:00 Leonardo Santagostini lsantagost...@gmail.com:
Well well well. Thank you all so much !!!
Since Struts upgrade i got not intrussion on my servers =) =)
Thank you list for the support, for the time and for helpme with this
issue.
Yours,
Leonardo
Saludos.-
Leonardo Santagostini
http://ar.linkedin.com/in/santagostini
2014-05-20 12:45 GMT-03:00 Leonardo Santagostini lsantagost...@gmail.com
:
Hello all, again its me =)
Just for you that today we deployed our apps using struts 2.3.16.2
So since today i will monitor those server very closely =)
Thanks all people. I will tell you how things go.
Regards,
Leonardo
Saludos.-
Leonardo Santagostini
http://ar.linkedin.com/in/santagostini
2014-05-07 12:28 GMT-03:00 Leonardo Santagostini lsantagost...@gmail.com
:
Hello all !
Developers are still estimating the effort for upgrading struts i
will let you know how things are going.
Thanks all for replying me.
Regards,
Leonardo
Saludos.-
Leonardo Santagostini
http://ar.linkedin.com/in/santagostini
2014-05-05 15:39 GMT-03:00 Martin Gainty mgai...@hotmail.com:
Subject: Re: Regarding i think an intrusion
From: lsantagost...@gmail.com
To: users@tomcat.apache.org
Hello Chris, but this logfile was only one day.
MGAy Caramba!
Maybe i had a concept mismatch trying to capture the exact moment
when the
execution begins.
My command was
while [ true ]; do CUENTO=$(ps -fea | grep wget | grep -v grep | grep
-v
127.0.0.1 | wc -l); if [ $CUENTO -gt 0 ] ; then PIDJAVA=$(ps -fea |
grep
java | grep -v grep | awk '{ print $2 }'); echo -e Se encontro wget
corriendo, sacando dump de JVM... ; kill -3 $PIDJAVA; fi; sleep 3;
done
Maybe too many dumps all togheter, now im trying to get a live
capture
without luck =(
If you know a better method, please letme know it.
Thanks for your effort, knid regards,
Leonardo
Saludos.-
Leonardo Santagostini
MGTomcat APR no puede utilizar WebSockets con JDK 1.6 ...necesita
utilizar JDK @ 1.7 (ahora)
MGesto
ContainerBackgroundProcessor[StandardEngine[Catalina]] daemon prio=10
tid=0x52867800 nid=0x2550 waiting on condition [0x4105e000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1508)
at java.lang.Thread.run(Thread.java:662)
MGEstos registros informativos producen MUCHO ruido
MGlog4j.properties
MGlog4j.logger.org.quartz=OFF //(Callate Quartz)
MGeso
ajp-bio-8009-exec-37 daemon prio=10 tid=0x2aaac07fd800 nid=0x2656
runnable [0x46f34000]
java.lang.Thread.State: RUNNABLE
at java.util.regex.Pattern$6.isSatisfiedBy(Pattern.java:4763)
at java.util.regex.Pattern$CharProperty.match(Pattern.java:3345)
at java.util.regex.Pattern$Curly.match0(Pattern.java:3770)
at java.util.regex.Pattern$Curly.match(Pattern.java:3744)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168)
at java.util.regex.Pattern$Loop.match(Pattern.java:4295)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227)
at java.util.regex.Pattern$Curly.match0(Pattern.java:3782)
at java.util.regex.Pattern$Curly.match(Pattern.java:3744)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168)
at java.util.regex.Pattern$Loop.match(Pattern.java:4295)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227)
at java.util.regex.Pattern$Curly.match0(Pattern.java:3782)
at java.util.regex.Pattern$Curly.match(Pattern.java:3744)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168)
at java.util.regex.Pattern$Loop.match(Pattern.java:4295)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227)
at java.util.regex.Pattern$Curly.match0(Pattern.java:3782)
at java.util.regex.Pattern$Curly.match(Pattern.java:3744)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168)
at java.util.regex.Pattern$Loop.match(Pattern.java:4295)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227)
at java.util.regex.Pattern$Curly.match0(Pattern.java:3782)
at java.util.regex.Pattern$Curly.match(Pattern.java:3744)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168)
at java.util.regex.Pattern$Loop.match(Pattern.java:4295)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227)
at java.util.regex.Pattern$Curly.match0(Pattern.java:3782)
at java.util.regex.Pattern$Curly.match(Pattern.java:3744)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4168)
at java.util.regex.Pattern$Loop.match(Pattern.java:4295)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4227)
at
[Bug][Tomcat 5.5.x] Tomcat loses request parameters
Hi,
I think I found a problem in the way Tomcat parses the POST Http Request. It
might be related to issues n°40860, 31523 and 42347 submitted to bugzilla
https://issues.apache.org/bugzilla.
I am running on a JBoss 4.0.4 GA server on a windows platform. I know it uses a
5.5.x tomcat, but I don't know exactly which version.
Symptoms :
When I submit a POST request, sometimes one parameter get lost. I can tell
using Eclipse's TCP/IP proxy that the value was submitted in the request.
Analysis:
The POST request looks like that and is 15kB long:
-7de35e1c190e9e
Content-Disposition: form-data; name=autoScroll
0,0
-7de35e1c190e9e
Content-Disposition: form-data; name=principal:arbre::focused
false
-7de35e1c190e9e
Content-Disposition: form-data; name=principal:arbre::expandedNodes
Using remote debugging, I found that a MultipartStream object analyses the
request using a 4KB buffer; this buffer is fed by a 8kB buffer used by a
ByteChunk object.
The pattern -7de35e1c190e9e is called 'boundary'.
and is repeated for each field. I noted that the hex part of the boundary may
not be the same length from one POST to another, I think that is why the
problem does not always occur.
when MultipartStream arrives at the end of its buffer and there is not enough
bytes left to read the next boundary, it moves the few unread bytes to the
beginning of the buffer, then loads the next chunk of data from the ByteChunk
object (see MultipartStream$ItemInputStream.makeAvailable())
ex : the buffer ends with false\n\r. These bytes are moved to the start
of the buffer, so that the buffer now starts with
false\n\r-7de35e1c190e9e[...] and the code can
now read the boundary.
In this example, after parsing the first 4096 bytes, we now parse the
(4096-11)=4085 next bytes (because we still have the 11 last bytes from the
first chunk.
At the end of the second chunk : the buffer now ends with something like
0,0\n\r-- (7 bytes) and we need the next chunk of data to read the next
boundary. Tomcats asks the ByteChunk object for the next (4096-7) bytes, but
there are only 11 available (8kB-4kB-4085 bytes). So MultipartStream only sees
a 18 bytes-long data, which is not enough to read the boundary. As a
consequence, the field is skipped and is value is lost.
So the problem, I think, relies in the ByteChunk.substract method, when the
available bytes in the buffer are not enough to fill the MultipartStream need.
This method should attempt to read the next chunk of data if available.
Solution :
Here is the modification I suggest in the code:
public int substract( byte src[], int off, int len )
throws IOException {
if ((end - start) == 0) {
if (in == null)
return -1;
int n = in.realReadBytes( buff, 0, buff.length );
if (n 0)
return -1;
}
int n = len;
if (len getLength()) {
n = getLength();
}
System.arraycopy(buff, start, src, off, n);
start += n;
// Start of modification - add
if (nlen) {
// not enough data in the buffer. We want more!
int n2 = substract(src, off+n, len-n);
if (n20) {
return n+n2;
}
}
// End of modification
return n;
}
below is a part of the stack trace to the point where I located the problem:
Daemon Thread [http-0.0.0.0-8080-5] (Suspended (breakpoint at line 404 in
ByteChunk))
ByteChunk.substract(byte[], int, int) line: 404
InputBuffer.read(byte[], int, int) line: 299
CoyoteInputStream.read(byte[], int, int) line: 192
MultipartStream$ItemInputStream.makeAvailable() line: 959
MultipartStream$ItemInputStream.read(byte[], int, int) line: 887
MultipartStream$ItemInputStream(InputStream).read(byte[]) line: 89
Streams.copy(InputStream, OutputStream, boolean, byte[]) line: 94
Streams.copy(InputStream, OutputStream, boolean) line: 64
MultipartStream.readBodyData(OutputStream) line: 593
MultipartStream.discardBodyData() line: 619
MultipartStream.skipPreamble() line: 638
FileUploadBase$FileItemIteratorImpl.findNextItem() line: 844
FileUploadBase$FileItemIteratorImpl.init(FileUploadBase,
RequestContext) line: 825
DiskFileUpload(FileUploadBase).getItemIterator(RequestContext) line:
323
DiskFileUpload(FileUploadBase).parseRequest(RequestContext) line: 341
DiskFileUpload(FileUploadBase).parseRequest(HttpServletRequest) line:
302
MultipartRequestWrapper.parseRequest() line: 85
MultipartRequestWrapper.getParameter(String) line: 181
Using custom classloader
Hi: I want my web apps running on Tomcat 7.0.35 to use a custom classloader. The reason is that I want each web app classloader instance to do some processing to set up the classpath for the web app it belongs to. I have the following questions: 1) Is org.apache.catalina.loader.WebappClassLoader a good class to derive my custom classloader from? Is it a good choice going forward for later versions of Tomcat? 2) Is there a recommended way for my custom classloader to identify which web app it belongs to? It needs to identify which web app it is for so that it will know what jars to put on its classpath. Thanks!
Re: [Bug][Tomcat 5.5.x] Tomcat loses request parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Didier, On 6/4/14, 11:30 AM, DDU DUQUENNOY Didier wrote: I think I found a problem in the way Tomcat parses the POST Http Request. It might be related to issues n°40860, 31523 and 42347 submitted to bugzilla https://issues.apache.org/bugzilla. I am running on a JBoss 4.0.4 GA server on a windows platform. I know it uses a 5.5.x tomcat, but I don't know exactly which version. Tomcat 5.5.x is no longer supported. We don't support JBoss, here, either. You'll have to get support from Red Hat at this point, or upgrade to a version of Tomcat that is supported. Symptoms : When I submit a POST request, sometimes one parameter get lost. I can tell using Eclipse's TCP/IP proxy that the value was submitted in the request. Without knowing what version of 5.5.x you are using, nobody is going to be able to tell you if a) there is a bug and b) if it was fixed in a version of Tomcat later than the one you are running. I can tell you pretty confidently that Tomcat does not lose request parameters, even old unsupported versions. ;) Analysis: The POST request looks like that and is 15kB long: -7de35e1c190e9e Content-Disposition: form-data; name=autoScroll 0,0 -7de35e1c190e9e Content-Disposition: form-data; name=principal:arbre::focused false -7de35e1c190e9e Content-Disposition: form-data; name=principal:arbre::expandedNodes It's worth pointing-out that Tomcat did not directly handle multipart requests until version 7.0.x. If you are having problems with multipart requests, the problem is likely with either /your/ (of JBoss's) multipart library or your own code. (Oddly, Tomcat does have the package-renamed classes from commons-http-upload available in the Tomcat 6 source...) Using remote debugging, I found that a MultipartStream object analyses the request using a 4KB buffer; this buffer is fed by a 8kB buffer used by a ByteChunk object. The pattern -7de35e1c190e9e is called 'boundary'. and is repeated for each field. I noted that the hex part of the boundary may not be the same length from one POST to another, I think that is why the problem does not always occur. when MultipartStream arrives at the end of its buffer and there is not enough bytes left to read the next boundary, it moves the few unread bytes to the beginning of the buffer, then loads the next chunk of data from the ByteChunk object (see MultipartStream$ItemInputStream.makeAvailable()) That class does not exist in Tomcat prior to Tomcat 6, and in Tomcat 6 does not have the makeAvailable method. In Tomcat 7, makeAvailable appears. I suspect you are using commons-http-upload, and probably a fairly old version. If this ever was a problem with commons-http-upload, I'm sure it's been fixed. In any case, you are going to have to upgrade at least commons-http-upload. I would recommend upgrading just about every component you currently have, as you are likely to be very out of date. Security patches, performance improvements, bug fixes, etc. are all available between your version and the current. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTj7StAAoJEBzwKT+lPKRYrmQP/iDgbuW2j0UxCn6IM2Skra4z PUIj1O4tBMz4Q668sjxboJHpMHYDPsW8uUtChIFH2UbyxQ8yonqjhugybPE3jBf3 jwmw+tk+x8FbW+tiGeQl/KxPdvgo5l7i51Hb7/SA8Wzhu82gGm9J3zjo5g7FhMje 8H8T9qMpSijUJO1QLfnNiGuXeLlDVOAL35lTihW+rTiuFjn+hy/rqwM01lGMyw0n hrh8d9ZHFZGorDBoIFnPc+Jbo+qhI+wZB/tgPgYFQrk1MTBgmvbiJ0Zd4wmV7mGj fOMCQF3Xbf8iJvkQBVq8C+17Yr/AHFH96t6zDCWfPLdwWIUtRVOA86EYvmxqd4cb lWBdPvf5o3+MCYHp4nX/JSMgD7oAKwZYsi0rTSj9MadWUHSgkZT31zD8VCQET5WQ M7BuAI8P3rsMvopCEF+eLLgjc5wOvqoW/egrldkenxeNA1EN7g8mqiFWIkDXcoh4 +mNciaag3fk0XmkmLfl9MGrGc+/81aQBoa2R1ge0QIZFGEhUnrLrVESCPwyZGfvB Wwpdy86KUTIJD1nwW5v4ghmDhVdYs3r3NYbcBsGv927UXSnsaFsoWpAzz7xYJNn7 JUG23HcPgG7Ff8jO1osE9AjLyua9hJKgxVM9vzwj1ctCS1TlZ4EAlEoufnJY5OOF 7AEjGq+cRV57F04cdGw2 =vxm6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using custom classloader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Don, On 6/4/14, 11:46 AM, Don Asper wrote: Hi: I want my web apps running on Tomcat 7.0.35 to use a custom classloader. The reason is that I want each web app classloader instance to do some processing to set up the classpath for the web app it belongs to. Can you be more specific? Perhaps you don't actually need to write a new ClassLoader... you may be able to configure the existing ClassLoader to behave the way you want, or possibly use a non-ClassLoader-related solution. I have the following questions: 1) Is org.apache.catalina.loader.WebappClassLoader a good class to derive my custom classloader from? Yes. Is it a good choice going forward for later versions of Tomcat? Probably. I don't think that class (name) has changed significantly in a very long time. If you hook-into the constructor or lifecycle methods you should be good. Remember: always test with new versions :) 2) Is there a recommended way for my custom classloader to identify which web app it belongs to? It needs to identify which web app it is for so that it will know what jars to put on its classpath. If you are using WebapClassLoader as your parent, you can call super.getContextName(), but that will just get you the name of the context, not the location of the deployment artifact. What information do you actually need? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTj7f0AAoJEBzwKT+lPKRYG3AP/3gJCphgLXN8hZvojSz760CO JRzw+YR3qubhFPH+K2diwveA4tLwIpmL7rMiCljXIVZz+q5illbYtrMR6Ou9nCmt k7L9R2rjX5Fyr+Eew4qevXQHL+0V0MbVsuRd9Gs9D4LVvMgNpOb1ArhIkweZEi2A 67GTPKENU+o29yJrxXU/19EMbyItu6O/w26boPeX6+7MQXfvSycSeJZdytNA3Sws psiEf+5/5th2jppDB2aoS/lpZbAoODLUPkeOryGZPjAL5KFCqVAUvhtV/CmfHqKw VSbaa6XCvhFlijXETArWiSgjdaWm5dBEWK+XdKhAV9PWt10zBHeL4+vXdsan3K6Z 3tXy9ceMTeHC9oXAJDOcdXIjiL8wIJlPOH0P05/cbnMaGL2ItKu1H+V6y9NqvKXw hr07SypVdWzjez+1s3u0Uv7hzyoRXVtfbA5vpCAOgo0jL04bLLfzlJ/JE+yZwdk1 Y37XBxRWvRpUfeax0+U/q5X+8Io3bBHwBzUW9JPJnQE1iLxej/H4Db1Fp+kXnVaz GtwLYEAechGXgAnZF+0msocTdLb7OjecCcKmVDmwHayUqHPAQNrh0Bn2vaw4EWef HkV6XH3Rt3bcvgw+CUQoiDa+k02BTtBOCLRlCCYc6L8MTL9wh2uVUWIrijBNMTjn jETFSqYlIC2H6O5mGiJ2 =Lc35 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat autodeploy doesn't return actual files via HTTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Арсений, On 6/3/14, 11:56 AM, Арсений Зинченко wrote: Hi. Faced with little bit odd behavior of Tomcat 7 Java 1.6. Old file is: $ curl http://localhost:8084First file I mean - *war-file* contains only one index.jsp page with text First page: $ jar tf ../app-application/APP.war META-INF/ META-INF/MANIFEST.MF index.jsp Tomcat's server.xml has next components config: Host name=localhost appBase=/home/user/APP/app-application/ unpackWARs=false autoDeploy=true deployOnStartup=false Context path= docBase=APP.war reloadable=true / Then - I copied new *war-file*: $ cat ../tmp/1/index.jspSecond file $ cd ../tmp/1/ jar cf APP.war index.jsp $ cp APP.war ../../app-application/ cp: overwrite `../../app-application/APP.war'? y And see in log: INFO: Undeploying context [/APP] Jun 3, 2014 1:16:40 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive /home/user/APP/app-application/APP.war Buit - when I'm trying open it with browser - I got old file again: $ curl http://localhost:8084/First file And only after full Tomcat's reboot - I see new file; $ curl http://localhost:8084Second file Why? Am I missed something? Tomcat keep it in some cache? This is why nobody should define Context elements in server.xml: they always mess them up. In addition to what Konstantin has said, note that Tomcat is restarting the context with path [/APP] and not [/]. You have double-deployed APP.war: once as /APP and once (maybe?) as ROOT. If you can't stomach calling your WAR file ROOT.war like everybody else, then use descriptor-file-based deployment with a CATALINA_BASE/conf/[engine]/localhost/ROOT.xml descriptor. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTj7mvAAoJEBzwKT+lPKRYciAP/RxLZmt9NGIrR6+YcGS5j83p fH0rz/5VwCK8xU5i0y+UhHWf1BhaJ1JK0Fi7bcw4hvTi/h11wI7aEMCeQztyp9R9 5oDvfCTARBplNbkUS0J9eqAJvGIRxJJaI3OQfQlhOFvrQI5n5xjBHGh3FF7oX70c 5fKCgCR2YHgtzg0P9zFygP27XDi1ynhna3OG4VHLJ0LmRu/r2N+Kl+JRsgkr7NUX QYUxOlzN1sq5ROJYwZcv/7pJ8Aq1fvoRYrwj+Hdvp97h3yCql6b9EPEVVnM/mMg2 Rh5U5kbKytYXdndoy8BKDWHAaqbQ45Rs/OTsG5Qcqr3pVlaNOU1nkFioDPys809g HHa4zwWHCS5hITiQ7sgcYUxaMi6rPKw8U8DkdsJ0dFYPO2/O34qj/AJ4ryEo6RnJ Nz9rw6ZjrQPEXFxWFI5W5djIaXy+Q5m6uFIziL8NdB4XLkpe11rbiQ45lSJYeWHR crioW7VF8snLcUoja8nJtgNRbtLcZPBOAvS4ApLYAZS9rBlO09PPamvbfPJEjWV+ oZftgY//oQ6m3n/3r3CLyri/7pZ6CTclgJpQUw8vGHYMxf00YPSLAJXgRUpKTcXE DbdMdwJpsUvwPbNBUnIP4xQtnzFIk2tvxxE6uyC/NJbqOEs2dVwQMF0IVU2Uxi+t ukEh/DscpVPgumtKnifk =Hedg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
