You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Adam Hardy <ah...@cyberspaceroad.com> on 2004/03/18 11:45:54 UTC

[Fwd: container managed security]

Nobody responded to my previous message, but I am still searching for 
information on the subject. Any references to docs would be welcome. I 
have searched for threads on this list in the archives but had no joy 
either.

Thanks
Adam

-------- Original Message --------
From: - Fri Mar 12 18:50:10 2004
To: tomcat-dev@jakarta.apache.org
Subject: container managed security

In tomcat 4 I was able to to protect my app with non-SSL
security-constraints while using SSL form-based authentication so that
the passwords were not sent in clear text. This has been a specification
of the last 3 projects I have worked on.

In tomcat 5 this is impossible without coding a work-around.

I logged this as a bug in tomcat but it was closed as 'invalid'.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23970

I remember 6 months ago someone saying that the tomcat developers had
decided that due to the danger of session-hijacking, if it was worth
encrypting the login, it was worth encrypting the whole session traffic.

Due to the charges that the extra hardware brings when doing all
logged-in sessions in SSL, amongst other reasons, I disagreed and
developed a work-around to let me carry on using the Struts & Tomcat
security features.

This took me a few days back then, and then this week something else
cropped up which caused me to revisit the work-around code and spend 2
days adding to it (and documenting it - it's pretty arcane).

It occurred to me that this will always happen. The work-around is
vulnerable to any changes in the servlet spec of course, but also in
tomcat and in struts.

I would appreciate finding out the whole story on this - last time I
just let it go through lack of time. If I'm in the wrong place - perhaps
the JCP Servlet working group would be better - can someone point me in
the right direction?

Adam



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


RE: [Fwd: container managed security]

Posted by Mark Thomas <ma...@apache.org>.
Adam,

I thought that this was a spec issue and a quick review of the bugzilla postings
confirms this. The best place to follow this up is with the servlet spec team.

Mark 

> -----Original Message-----
> From: Adam Hardy [mailto:ahardy.struts@cyberspaceroad.com] 
> Sent: Thursday, March 18, 2004 10:46 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: [Fwd: container managed security]
> 
> Nobody responded to my previous message, but I am still searching for 
> information on the subject. Any references to docs would be 
> welcome. I 
> have searched for threads on this list in the archives but had no joy 
> either.
> 
> Thanks
> Adam
> 
> -------- Original Message --------
> From: - Fri Mar 12 18:50:10 2004
> To: tomcat-dev@jakarta.apache.org
> Subject: container managed security
> 
> In tomcat 4 I was able to to protect my app with non-SSL
> security-constraints while using SSL form-based authentication so that
> the passwords were not sent in clear text. This has been a 
> specification
> of the last 3 projects I have worked on.
> 
> In tomcat 5 this is impossible without coding a work-around.
> 
> I logged this as a bug in tomcat but it was closed as 'invalid'.
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=23970
> 
> I remember 6 months ago someone saying that the tomcat developers had
> decided that due to the danger of session-hijacking, if it was worth
> encrypting the login, it was worth encrypting the whole 
> session traffic.
> 
> Due to the charges that the extra hardware brings when doing all
> logged-in sessions in SSL, amongst other reasons, I disagreed and
> developed a work-around to let me carry on using the Struts & Tomcat
> security features.
> 
> This took me a few days back then, and then this week something else
> cropped up which caused me to revisit the work-around code and spend 2
> days adding to it (and documenting it - it's pretty arcane).
> 
> It occurred to me that this will always happen. The work-around is
> vulnerable to any changes in the servlet spec of course, but also in
> tomcat and in struts.
> 
> I would appreciate finding out the whole story on this - last time I
> just let it go through lack of time. If I'm in the wrong 
> place - perhaps
> the JCP Servlet working group would be better - can someone 
> point me in
> the right direction?
> 
> Adam
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org