You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Duong BaTien <du...@gmail.com> on 2005/06/05 05:16:54 UTC
Re: Force Non-SSL
On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote:
> From a config point of view no. The "simple workaround"
> - Ditch the web.xml config for requiring SSL
> - Create a filter which checks the scheme and URL - if the do not match what
> you desire - you can issue a redirect in the filter to https (or http) as desired
>
>
> -Tim
Hello Tim and other tomcat 5.5.9 experts:
If i understand you correctly, you propose:
1) set security constraint pages you want to run under ssl, such as:
<security-constraint>
<web-resource-collection>
<url-pattern>/WEB-INF/secure/*</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
2) Write a servlet filter to direct any url NOT under the
pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do
you have this code handy and want to share with others?
The result will be:
1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the
container will force the user with its logon FORM, if the user is not
authenticated. If username/password is authenticated the page
logonSuccess.jsp wil be served.
2) If you create a user session (e.g. a guestTag for collecting user
activities) while user is NOT authenticated, and the container now
authenticated the user after the request of logonSuccess.jsp, the
servlet spec will guarantee that the session visible to developer code
after login be the same session object that was created prior to SSL
login so there is no loss of session information.
3) Since the security model does not apply to RequestDispatcher
according to serlet spec, the container will serve other requests under
standard http and NOT https as reported after the user was served the
logonSuccess.jsp.
4) Only after the user is authenticated by the server, we can use
getUserPrincipal(), isUserInRole() to integrate container authentication
with programmatic authorization. Before that, only a generic guestTag
for recording user activities.
Do i miss something?
Thanks
BaTien
DBGROUPS
>
> August Detlefsen wrote:
>
> > Is there no way to do it? SSL creates a lot of overhead for a site that
> > is serving up 100MB image files.
> >
> >
> >
> >
> > --- Tim Funk <fu...@joedog.org> wrote:
> >
> >>no
> >>
> >>-Tim
> >>
> >>August Detlefsen wrote:
> >>
> >>>In my webapp I force clients to use SSL encryption for logins with
> >>
> >>a
> >>
> >>>security constraint and transport-guarantee elements like this:
> >>>
> >>> <security-constraint>
> >>> <web-resource-collection>
> >>> <web-resource-name>Login</web-resource-name>
> >>> <url-pattern>/login/*</url-pattern>
> >>> </web-resource-collection>
> >>>
> >>> <user-data-constraint>
> >>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> >>> </user-data-constraint>
> >>> </security-constraint>
> >>>
> >>>However, once a user hits the login page, every subsequent page
> >>
> >>also
> >>
> >>>uses https. Is there a way to force them back to regular http once
> >>
> >>they
> >>
> >>>leave the login section?
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Force Non-SSL
Posted by Duong BaTien <du...@gmail.com>.
Greetings:
As promised, i report back my solutions and hope this may help others.
On Mon, 2005-06-06 at 07:42 -0600, Duong BaTien wrote:
>
> On Mon, 2005-06-06 at 07:04 -0400, Tim Funk wrote:
> > Almost. (I think)
> >
> Thanks. I will try the workaround and report to the list for the
> benefits of others.
>
> BaTien
> DBGROUPS
>
> > You can't request any pages under /WEB-INF. Security constraints are only for
> > the incoming URL - not urls obtained by getRequestDispatcher()
> >
> > -Tim
> >
> I know. These are my protected pages and i want to make sure that they
> must go through my presentation engine (Jsf + Tiles).
>
> BaTien
>
> > Duong BaTien wrote:
> > > On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote:
> > >
> > >> From a config point of view no. The "simple workaround"
> > >>- Ditch the web.xml config for requiring SSL
> > >>- Create a filter which checks the scheme and URL - if the do not match what
> > >>you desire - you can issue a redirect in the filter to https (or http) as desired
> > >>
> > >>
> > >>-Tim
> > >
> > >
> > > Hello Tim and other tomcat 5.5.9 experts:
> > >
> > > If i understand you correctly, you propose:
> > > 1) set security constraint pages you want to run under ssl, such as:
> > > <security-constraint>
> > > <web-resource-collection>
> > > <url-pattern>/WEB-INF/secure/*</url-pattern>
> > > <http-method>POST</http-method>
> > > <http-method>GET</http-method>
> > > </web-resource-collection>
> > > <user-data-constraint>
> > > <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> > > </user-data-constraint>
> > > </security-constraint>
> > >
> > > 2) Write a servlet filter to direct any url NOT under the
> > > pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do
> > > you have this code handy and want to share with others?
> > >
The re direct must include both desired protocol and service port as
explained in a proposed solution by Steve Ditlinger in his JavaWorld
paper (Feb 2002) and later evolved into sslext for Struts. The approach
is quite easy to implement for any framework. This is what we do under
Jsf.
> > > The result will be:
> > > 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the
> > > container will force the user with its logon FORM, if the user is not
> > > authenticated. If username/password is authenticated the page
> > > logonSuccess.jsp wil be served.
> > > 2) If you create a user session (e.g. a guestTag for collecting user
> > > activities) while user is NOT authenticated, and the container now
> > > authenticated the user after the request of logonSuccess.jsp, the
> > > servlet spec will guarantee that the session visible to developer code
> > > after login be the same session object that was created prior to SSL
> > > login so there is no loss of session information.
> > > 3) Since the security model does not apply to RequestDispatcher
> > > according to serlet spec, the container will serve other requests under
> > > standard http and NOT https as reported after the user was served the
> > > logonSuccess.jsp.
The desired protocol and service port must be explicitly specified for
the requested page.
Hope this may help and/or save others some time.
BaTien
DBGROUPS
> > > 4) Only after the user is authenticated by the server, we can use
> > > getUserPrincipal(), isUserInRole() to integrate container authentication
> > > with programmatic authorization. Before that, only a generic guestTag
> > > for recording user activities.
> > >
> > > Do i miss something?
> > >
> > > Thanks
> > >
> > > BaTien
> > > DBGROUPS
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Force Non-SSL
Posted by Duong BaTien <du...@gmail.com>.
On Mon, 2005-06-06 at 07:04 -0400, Tim Funk wrote:
> Almost. (I think)
>
Thanks. I will try the workaround and report to the list for the
benefits of others.
BaTien
DBGROUPS
> You can't request any pages under /WEB-INF. Security constraints are only for
> the incoming URL - not urls obtained by getRequestDispatcher()
>
> -Tim
>
I know. These are my protected pages and i want to make sure that they
must go through my presentation engine (Jsf + Tiles).
BaTien
> Duong BaTien wrote:
> > On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote:
> >
> >> From a config point of view no. The "simple workaround"
> >>- Ditch the web.xml config for requiring SSL
> >>- Create a filter which checks the scheme and URL - if the do not match what
> >>you desire - you can issue a redirect in the filter to https (or http) as desired
> >>
> >>
> >>-Tim
> >
> >
> > Hello Tim and other tomcat 5.5.9 experts:
> >
> > If i understand you correctly, you propose:
> > 1) set security constraint pages you want to run under ssl, such as:
> > <security-constraint>
> > <web-resource-collection>
> > <url-pattern>/WEB-INF/secure/*</url-pattern>
> > <http-method>POST</http-method>
> > <http-method>GET</http-method>
> > </web-resource-collection>
> > <user-data-constraint>
> > <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> > </user-data-constraint>
> > </security-constraint>
> >
> > 2) Write a servlet filter to direct any url NOT under the
> > pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do
> > you have this code handy and want to share with others?
> >
> > The result will be:
> > 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the
> > container will force the user with its logon FORM, if the user is not
> > authenticated. If username/password is authenticated the page
> > logonSuccess.jsp wil be served.
> > 2) If you create a user session (e.g. a guestTag for collecting user
> > activities) while user is NOT authenticated, and the container now
> > authenticated the user after the request of logonSuccess.jsp, the
> > servlet spec will guarantee that the session visible to developer code
> > after login be the same session object that was created prior to SSL
> > login so there is no loss of session information.
> > 3) Since the security model does not apply to RequestDispatcher
> > according to serlet spec, the container will serve other requests under
> > standard http and NOT https as reported after the user was served the
> > logonSuccess.jsp.
> > 4) Only after the user is authenticated by the server, we can use
> > getUserPrincipal(), isUserInRole() to integrate container authentication
> > with programmatic authorization. Before that, only a generic guestTag
> > for recording user activities.
> >
> > Do i miss something?
> >
> > Thanks
> >
> > BaTien
> > DBGROUPS
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Force Non-SSL
Posted by Tim Funk <fu...@joedog.org>.
Almost. (I think)
You can't request any pages under /WEB-INF. Security constraints are only for
the incoming URL - not urls obtained by getRequestDispatcher()
-Tim
Duong BaTien wrote:
> On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote:
>
>> From a config point of view no. The "simple workaround"
>>- Ditch the web.xml config for requiring SSL
>>- Create a filter which checks the scheme and URL - if the do not match what
>>you desire - you can issue a redirect in the filter to https (or http) as desired
>>
>>
>>-Tim
>
>
> Hello Tim and other tomcat 5.5.9 experts:
>
> If i understand you correctly, you propose:
> 1) set security constraint pages you want to run under ssl, such as:
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/WEB-INF/secure/*</url-pattern>
> <http-method>POST</http-method>
> <http-method>GET</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
> 2) Write a servlet filter to direct any url NOT under the
> pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do
> you have this code handy and want to share with others?
>
> The result will be:
> 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the
> container will force the user with its logon FORM, if the user is not
> authenticated. If username/password is authenticated the page
> logonSuccess.jsp wil be served.
> 2) If you create a user session (e.g. a guestTag for collecting user
> activities) while user is NOT authenticated, and the container now
> authenticated the user after the request of logonSuccess.jsp, the
> servlet spec will guarantee that the session visible to developer code
> after login be the same session object that was created prior to SSL
> login so there is no loss of session information.
> 3) Since the security model does not apply to RequestDispatcher
> according to serlet spec, the container will serve other requests under
> standard http and NOT https as reported after the user was served the
> logonSuccess.jsp.
> 4) Only after the user is authenticated by the server, we can use
> getUserPrincipal(), isUserInRole() to integrate container authentication
> with programmatic authorization. Before that, only a generic guestTag
> for recording user activities.
>
> Do i miss something?
>
> Thanks
>
> BaTien
> DBGROUPS
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org