Hi P,
Thanks very much for your reasoned helpful response.
I fancied securing only login because I only want logged in users to see the
service and I want the login to be secure (passwords are safe) but the data
itself is irrelevant so I figure why spend cpu cycles encrypting/decrypting
normal data communication? :)
To be honest I'm happy to just encrypt the whole thing if that's just going to
save me a lot of hassle.
My last stab at this is maybe I could use a scenario of filtering all requests
and essentially do:
if (logged in) {
if (https) goto http
} else {
if (http) goto https
}
And then rely on the security constraint only for requiring login and the Valve
only for forwarding the request to the login page?
R.
On 9 Nov 2009, at 23:05, Pid wrote:
> On 09/11/2009 22:33, Robert Denison wrote:
>> Hi all,
>>
>> I am trying to have setup my tomcat webapp to be secure for login only.
>> It works as you'd expect if the security-constraint for /* is unsecure
>> and if I make it secure (using CONFIDENTIAL) for /*.
>>
>> However if I try to make it secure only for the login page and unsecure
>> elsewhere any attempt to go to a page redirects to the login page but
>> unsecure - not using the https and higher port. I've seen comments about
>> filters to redirect up to the https port but my thoughts are:
>>
>> 1) From what I understand it should be possible with multiple
>> constraints for different URLs, and
>> 2) as I only want to do this if the user is not logged in I'm not sure
>> how the filter would work.
>>
>> I have a working https Connector because I can use the service
>> configured for /* to be secure.
>
> So, to summarise, you want *only* the login page to be sent over SSL?
>
>
> The login page isn't ever requested directly, it's forwarded to by the
> AuthenticationValve. This means that you can place it out of the way, in,
> say:
>
> WEB-INF/login/form.jsp
> WEB-INF/login/error.jsp
>
> but it also means that you shouldn't directly request the login page.
>
> When you're using Container managed security, you request a secured resource
> and the Valve forwards to the form. Once you authenticate the original
> request is restored.
>
> Your config won't enforce SSL for the login page because the container
> forwards the request to the page after it recognises the /* rule requires a
> login.
>
>
> If you want the whole app to require a login, you can either choose to use
> SSL, or not, but you can't easily send the login page only over SSL.
>
> If only one part of the app required a login, you could employ a Filter to
> downgrade to non-SSL when the URL didn't match that path.
>
> Is there a particular reason why you want to downgrade after login?
>
>
> You might look into the Tomcat compatible SecurityFilter project, as it
> provides very similar functionality to container managed security, but more
> flexibility.
>
> http://securityfilter.sourceforge.net/
>
>
> p
>
>
>> Any offered help appreciated.
>>
>> The relevant (I think) web.xml snippet is:
>>
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name>Application Login</web-resource-name>
>> <url-pattern>/login.jsp</url-pattern>
>> <http-method>GET</http-method>
>> <http-method>POST</http-method>
>> </web-resource-collection>
>> <auth-constraint>
>> <role-name>player</role-name>
>> </auth-constraint>
>> <user-data-constraint>
>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>> </user-data-constraint>
>> </security-constraint>
>>
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name>Application</web-resource-name>
>> <url-pattern>/*</url-pattern>
>> </web-resource-collection>
>> <auth-constraint>
>> <role-name>player</role-name>
>> </auth-constraint>
>> </security-constraint>
>>
>> <!-- Define the Login Configuration for this Application -->
>> <login-config>
>> <auth-method>FORM</auth-method>
>> <realm-name>Application</realm-name>
>> <form-login-config>
>> <form-login-page>/jsp/login.jsp</form-login-page>
>> <form-error-page>/jsp/error.jsp</form-error-page>
>> </form-login-config>
>> </login-config>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
