Re: container managed security
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: container managed security]
Is there any way of seeing how the servlet spec team reached their decisions, apart from sending an email to the address mentioned in the spec? (I've done that before without any result). Is there a mailing list for it? Looking around at java.sun.com doesn't bring much to light. Thanks Adam On 03/18/2004 09:38 PM Mark Thomas wrote: 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:[EMAIL PROTECTED] Sent: Thursday, March 18, 2004 10:46 AM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Fwd: container managed security]
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:[EMAIL PROTECTED] > Sent: Thursday, March 18, 2004 10:46 AM > To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
