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/12 18:46:56 UTC
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
--
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: container managed security
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
I searched for some time in various archives, bug databases, mailing
lists etc trying to find this information but my searching basically
always brings me back to here.
All I want to do is set up container managed security to allow
unencrypted sessions on protected resources, along with an SSL-based
non-clear text form-based login.
I discussed this partly with different people at different times but was
not involved (or paying attention would be a better way to put it) when
the servlet spec gurus and followers discussed the issue, and
subsequently I have unanswered questions about the implementation of
changes (in tomcat) that leave my requirement unattainable (almost).
I have scoured the mailing list archives, google and sun for relevant
info, but haven't found anything, even though that is the place to which
people constantly refer me.
I know this is old ground but I need to get the low-down on it. Thanks
in advance for any tips, links, pointers or explanations!
Adam
On 03/12/2004 06:46 PM Adam Hardy wrote:
> 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
>
--
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org