|
»
« Return to Thread: Security Constraints problem
Re: Re: Security Constraints problem
by janb
::
Rate this Message:
For those following along, Greg has added a new junit test for urls
like "/j_security_check" in org.eclipse.jetty.security.Constrain2tTest.java.
Greg,
The new junit test is correct for the urls, but does not mirror the situation
with the Authenticators that is setup for a WebAppContext.
Your test has:
_securityHandler.setAuthenticator(new SessionCachingAuthenticator(
new FormAuthenticator("/testLoginPage","/testErrorPage")));
But the WebAppContext has:
_securityHandler.setAuthenticator(new DeferredAuthenticator(
new SessionCachingAuthenticator(
new FormAuthenticator("/testLoginPage","/testErrorPage"))));
If you replace with the setup above, then the test will also fail, with a 200 OK
instead of the 302 redirect.
This is a different failure to my webapp, and caused because you have a RequestHandler
at the bottom of the handler chain, and when the SecurityHandler.handle() chains through
to this handler, it will explicitly cause any DeferredAuthenticators to be called:
if (request.getAuthType()==null || "user".equals(request.getRemoteUser()) || request.isUserInRole("user"))
My webapp, however, will chain through to the ServletHandler, and thus doesn't trigger any
authenticators, so tries to serve /j_security_check as static content.
The basic cause of failure in both cases, however, remains the fact that there are
no constraints considered to match "/j_security_check", causing isMandatory to be
false, and thus causing the DeferredAuthenticators to defer authentication.
regards,
Jan
Jan Bartel wrote:
> Putting in a constraint for j_security_check wound up with a loop back
> to the login page:
>
>
> Security constraint:
>
> Handling the j_security_check request:
> --------------------------------------
> SecurityHandler.handle with
> Request.getRequestURI=/test-jaas/j_security_check
> Preparing Constraint Info for pathIncontext: /j_security_check
> There are mappings: httpMethod= POST RoleInfo=null
> RoleInfo now: {RoleInfo,C[roleA]}
> isAuthMandatory=true for Request.getRequestURI= /test-jaas/j_security_check
> FormAuthenticator.validateRequest with Request.getRequestURI =
> /test-jaas/j_security_check
> FormAuthenticator.validateRequest with Request.getPathInfo = null
> FormAuthenticator.validateRequest with Request.getContextPath = /test-jaas
> FormAuthenticator.validateRequest with Request.getServletPath =
> /j_security_check
> FormAuthenticator.validateRequest with Request.getQueryString = null
> FormAuthenticator.validateRequest, dispatching request
> /test-jaas/j_security_check with forward to /login.html
>
> The decision to do the authentication is triggered off the
> pathInfo, but it seems in this case that the /j_security_check is
> considered the servletPath rather than the pathInfo?!
>
>
> Jan
>
>
>
>
>
> Greg Wilkins wrote:
>> It looks like it does not handle j_security_check being outside of the
>> constraints.
>> It is deferring handling of it!!!
>>
>> So a simple hacky fix would be to always insert a constraint for
>> j_security_check,
>> but I'm wondering if there is something more elegant ???
>>
>> cheers
>>
>>
>>
>> Jan Bartel wrote:
>>> Using jetty-7 trunk, there appears to be either a problem with the
>>> way the
>>> applicable constraints are calculated by the
>>> ConstraintSecurityHandler, or
>>> a problem with my understanding of security constraints. As the
>>> latter is
>>> just as likely as the former, I'll explain what's happening :)
>>>
>>> I have a webapp with a single security constraint and login-config:
>>>
>>> <security-constraint>
>>> <web-resource-collection>
>>> <web-resource-name>JAAS Role</web-resource-name>
>>> <url-pattern>/auth.html</url-pattern>
>>> </web-resource-collection>
>>> <auth-constraint>
>>> <role-name>roleA</role-name>
>>> </auth-constraint>
>>> </security-constraint>
>>>
>>> <login-config>
>>> <auth-method>FORM</auth-method>
>>> <realm-name>Test JAAS Realm</realm-name>
>>> <form-login-config>
>>> <form-login-page>
>>> /login.html
>>> </form-login-page>
>>> <form-error-page>
>>> /authfail.html
>>> </form-error-page>
>>> </form-login-config>
>>> </login-config>
>>>
>>> So, hitting a url of /auth.html, I expect to see the login form from
>>> /login.html. When I click submit and the credentials
>>> and role are ok, I expect to be redirected back to /auth.html.
>>>
>>> At least, that's what used to happen in jetty-6.
>>>
>>> What I see with jetty-7 is:
>>>
>>> Hitting /auth.html gives me the form from login.html. So far
>>> so good. However, submitting that produces the error:
>>>
>>> HTTP ERROR 404
>>> Problem accessing /test-jaas/j_security_check. Reason:
>>> Not Found
>>>
>>> What is happening is that when the form is submitted,
>>> the ConstraintSecurityHandler tries to find some
>>> matching constraints for the url /j_security_check and
>>> naturally doesn't find any - the security constraint is
>>> only on /auth.hml.
>>>
>>>
>>> Here's the annotated trace of what goes wrong:
>>>
>>>
>>> Handling the request for the protected page:
>>> ------------------------------------------
>>> SecurityHandler.handle with Request.getRequestURI=/test-jaas/auth.html
>>> Preparing Constraint Info for pathIncontext: /auth.html
>>> There are mappings: httpMethod= GET RoleInfo=null
>>> RoleInfo now: {RoleInfo,C[roleA]}
>>> isAuthMandatory=true for Request.getRequestURI= /test-jaas/auth.html
>>> FormAuthenticator.validateRequest with Request.getRequestURI =
>>> /test-jaas/auth.html
>>> FormAuthenticator.validateRequest with Request.getPathInfo = null
>>> FormAuthenticator.validateRequest, dispatching request
>>> /test-jaas/auth.html with forward to /login.html
>>>
>>> Handling the form submission:
>>> -----------------------------
>>> SecurityHandler.handle with
>>> Request.getRequestURI=/test-jaas/j_security_check
>>> Preparing Constraint Info for pathIncontext: /j_security_check
>>> There are mappings: httpMethod= POST RoleInfo=null ******
>>> RoleInfo now: null ******
>>> SecurityHandler.checkUserDataPermissions: No constraint info
>>> isAuthMandatory=false for Request.getRequestURI=
>>> /test-jaas/j_security_check
>>> authentication =
>>> org.eclipse.jetty.security.authentication.DeferredAuthenticator$DeferredAuthentication
>>>
>>>
>>>
>>>
>>> Note that there are no constraints matching /j_security_check at the
>>> line marked with "*******".
>>>
>>> Now, compare and contrast to the test-jetty-webapp, which has a
>>> wild-card set of resources protected by this security constraint:
>>>
>>> <security-constraint>
>>> <web-resource-collection>
>>> <web-resource-name>Admin Role</web-resource-name>
>>> <url-pattern>/dump/auth/admin/*</url-pattern>
>>> </web-resource-collection>
>>> <auth-constraint>
>>> <role-name>admin</role-name>
>>> </auth-constraint>
>>> </security-constraint>
>>>
>>> <login-config>
>>> <auth-method>FORM</auth-method>
>>> <realm-name>Test Realm</realm-name>
>>> <form-login-config>
>>> <form-login-page>/logon.html?param=test</form-login-page>
>>> <form-error-page>/logonError.html?param=test</form-error-page>
>>> </form-login-config>
>>> </login-config>
>>>
>>> The annotated trace of this is:
>>>
>>> Handling the request for the protected page:
>>> ------------------------------------------
>>> SecurityHandler.handle with Request.getRequestURI=/dump/auth/admin/
>>> Preparing Constraint Info for pathIncontext: /dump/auth/admin/
>>> There are mappings: httpMethod= GET RoleInfo=null
>>> RoleInfo now: {RoleInfo,C[admin]}
>>> SecurityHandler.checkUserDataPermissions: No dataconstraint or is none
>>> isAuthMandatory=true for Request.getRequestURI= /dump/auth/admin/
>>> FormAuthenticator.validateRequest with Request.getRequestURI =
>>> /dump/auth/admin/
>>> FormAuthenticator.validateRequest with Request.getPathInfo =
>>> /auth/admin/
>>> FormAuthenticator.validateRequest, dispatching request /dump/auth/admin/
>>> with forward to /logon.html?param=test
>>>
>>> Handling the form submission:
>>> -----------------------------
>>> SecurityHandler.handle with
>>> Request.getRequestURI=/dump/auth/admin/j_security_check
>>> Preparing Constraint Info for pathIncontext:
>>> /dump/auth/admin/j_security_check
>>> There are mappings: httpMethod= POST RoleInfo=null
>>> ****** RoleInfo now: {RoleInfo,C[admin]} *************
>>> SecurityHandler.checkUserDataPermissions: No dataconstraint or is none
>>> isAuthMandatory=true for Request.getRequestURI=
>>> /dump/auth/admin/j_security_check
>>> FormAuthenticator.validateRequest with Request.getRequestURI =
>>> /dump/auth/admin/j_security_check
>>> FormAuthenticator.validateRequest with Request.getPathInfo =
>>> /auth/admin/j_security_check
>>> Is a j_security_check: /auth/admin/j_security_check
>>> Logging in
>>>
>>> The line marked with "******" shows that because the constraint is on
>>> the directory /admin/*
>>> it matches security constraints, whereas my constraint is on a single
>>> file, and therefore
>>> the /j_security_check url does not match any constraints.
>>>
>>> Have I created a stupid and unrealistic situation by protecting a single
>>> file like this? Or do we need to take a closer look at the way the
>>> constraint matching is done?
>>>
>>> cheers
>>> Jan
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
--
Jan Bartel, Webtide LLC | janb@... | http://www.webtide.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
like "/j_security_check" in org.eclipse.jetty.security.Constrain2tTest.java.
Greg,
The new junit test is correct for the urls, but does not mirror the situation
with the Authenticators that is setup for a WebAppContext.
Your test has:
_securityHandler.setAuthenticator(new SessionCachingAuthenticator(
new FormAuthenticator("/testLoginPage","/testErrorPage")));
But the WebAppContext has:
_securityHandler.setAuthenticator(new DeferredAuthenticator(
new SessionCachingAuthenticator(
new FormAuthenticator("/testLoginPage","/testErrorPage"))));
If you replace with the setup above, then the test will also fail, with a 200 OK
instead of the 302 redirect.
This is a different failure to my webapp, and caused because you have a RequestHandler
at the bottom of the handler chain, and when the SecurityHandler.handle() chains through
to this handler, it will explicitly cause any DeferredAuthenticators to be called:
if (request.getAuthType()==null || "user".equals(request.getRemoteUser()) || request.isUserInRole("user"))
My webapp, however, will chain through to the ServletHandler, and thus doesn't trigger any
authenticators, so tries to serve /j_security_check as static content.
The basic cause of failure in both cases, however, remains the fact that there are
no constraints considered to match "/j_security_check", causing isMandatory to be
false, and thus causing the DeferredAuthenticators to defer authentication.
regards,
Jan
Jan Bartel wrote:
> Putting in a constraint for j_security_check wound up with a loop back
> to the login page:
>
>
> Security constraint:
>
> Handling the j_security_check request:
> --------------------------------------
> SecurityHandler.handle with
> Request.getRequestURI=/test-jaas/j_security_check
> Preparing Constraint Info for pathIncontext: /j_security_check
> There are mappings: httpMethod= POST RoleInfo=null
> RoleInfo now: {RoleInfo,C[roleA]}
> isAuthMandatory=true for Request.getRequestURI= /test-jaas/j_security_check
> FormAuthenticator.validateRequest with Request.getRequestURI =
> /test-jaas/j_security_check
> FormAuthenticator.validateRequest with Request.getPathInfo = null
> FormAuthenticator.validateRequest with Request.getContextPath = /test-jaas
> FormAuthenticator.validateRequest with Request.getServletPath =
> /j_security_check
> FormAuthenticator.validateRequest with Request.getQueryString = null
> FormAuthenticator.validateRequest, dispatching request
> /test-jaas/j_security_check with forward to /login.html
>
> The decision to do the authentication is triggered off the
> pathInfo, but it seems in this case that the /j_security_check is
> considered the servletPath rather than the pathInfo?!
>
>
> Jan
>
>
>
>
>
> Greg Wilkins wrote:
>> It looks like it does not handle j_security_check being outside of the
>> constraints.
>> It is deferring handling of it!!!
>>
>> So a simple hacky fix would be to always insert a constraint for
>> j_security_check,
>> but I'm wondering if there is something more elegant ???
>>
>> cheers
>>
>>
>>
>> Jan Bartel wrote:
>>> Using jetty-7 trunk, there appears to be either a problem with the
>>> way the
>>> applicable constraints are calculated by the
>>> ConstraintSecurityHandler, or
>>> a problem with my understanding of security constraints. As the
>>> latter is
>>> just as likely as the former, I'll explain what's happening :)
>>>
>>> I have a webapp with a single security constraint and login-config:
>>>
>>> <security-constraint>
>>> <web-resource-collection>
>>> <web-resource-name>JAAS Role</web-resource-name>
>>> <url-pattern>/auth.html</url-pattern>
>>> </web-resource-collection>
>>> <auth-constraint>
>>> <role-name>roleA</role-name>
>>> </auth-constraint>
>>> </security-constraint>
>>>
>>> <login-config>
>>> <auth-method>FORM</auth-method>
>>> <realm-name>Test JAAS Realm</realm-name>
>>> <form-login-config>
>>> <form-login-page>
>>> /login.html
>>> </form-login-page>
>>> <form-error-page>
>>> /authfail.html
>>> </form-error-page>
>>> </form-login-config>
>>> </login-config>
>>>
>>> So, hitting a url of /auth.html, I expect to see the login form from
>>> /login.html. When I click submit and the credentials
>>> and role are ok, I expect to be redirected back to /auth.html.
>>>
>>> At least, that's what used to happen in jetty-6.
>>>
>>> What I see with jetty-7 is:
>>>
>>> Hitting /auth.html gives me the form from login.html. So far
>>> so good. However, submitting that produces the error:
>>>
>>> HTTP ERROR 404
>>> Problem accessing /test-jaas/j_security_check. Reason:
>>> Not Found
>>>
>>> What is happening is that when the form is submitted,
>>> the ConstraintSecurityHandler tries to find some
>>> matching constraints for the url /j_security_check and
>>> naturally doesn't find any - the security constraint is
>>> only on /auth.hml.
>>>
>>>
>>> Here's the annotated trace of what goes wrong:
>>>
>>>
>>> Handling the request for the protected page:
>>> ------------------------------------------
>>> SecurityHandler.handle with Request.getRequestURI=/test-jaas/auth.html
>>> Preparing Constraint Info for pathIncontext: /auth.html
>>> There are mappings: httpMethod= GET RoleInfo=null
>>> RoleInfo now: {RoleInfo,C[roleA]}
>>> isAuthMandatory=true for Request.getRequestURI= /test-jaas/auth.html
>>> FormAuthenticator.validateRequest with Request.getRequestURI =
>>> /test-jaas/auth.html
>>> FormAuthenticator.validateRequest with Request.getPathInfo = null
>>> FormAuthenticator.validateRequest, dispatching request
>>> /test-jaas/auth.html with forward to /login.html
>>>
>>> Handling the form submission:
>>> -----------------------------
>>> SecurityHandler.handle with
>>> Request.getRequestURI=/test-jaas/j_security_check
>>> Preparing Constraint Info for pathIncontext: /j_security_check
>>> There are mappings: httpMethod= POST RoleInfo=null ******
>>> RoleInfo now: null ******
>>> SecurityHandler.checkUserDataPermissions: No constraint info
>>> isAuthMandatory=false for Request.getRequestURI=
>>> /test-jaas/j_security_check
>>> authentication =
>>> org.eclipse.jetty.security.authentication.DeferredAuthenticator$DeferredAuthentication
>>>
>>>
>>>
>>>
>>> Note that there are no constraints matching /j_security_check at the
>>> line marked with "*******".
>>>
>>> Now, compare and contrast to the test-jetty-webapp, which has a
>>> wild-card set of resources protected by this security constraint:
>>>
>>> <security-constraint>
>>> <web-resource-collection>
>>> <web-resource-name>Admin Role</web-resource-name>
>>> <url-pattern>/dump/auth/admin/*</url-pattern>
>>> </web-resource-collection>
>>> <auth-constraint>
>>> <role-name>admin</role-name>
>>> </auth-constraint>
>>> </security-constraint>
>>>
>>> <login-config>
>>> <auth-method>FORM</auth-method>
>>> <realm-name>Test Realm</realm-name>
>>> <form-login-config>
>>> <form-login-page>/logon.html?param=test</form-login-page>
>>> <form-error-page>/logonError.html?param=test</form-error-page>
>>> </form-login-config>
>>> </login-config>
>>>
>>> The annotated trace of this is:
>>>
>>> Handling the request for the protected page:
>>> ------------------------------------------
>>> SecurityHandler.handle with Request.getRequestURI=/dump/auth/admin/
>>> Preparing Constraint Info for pathIncontext: /dump/auth/admin/
>>> There are mappings: httpMethod= GET RoleInfo=null
>>> RoleInfo now: {RoleInfo,C[admin]}
>>> SecurityHandler.checkUserDataPermissions: No dataconstraint or is none
>>> isAuthMandatory=true for Request.getRequestURI= /dump/auth/admin/
>>> FormAuthenticator.validateRequest with Request.getRequestURI =
>>> /dump/auth/admin/
>>> FormAuthenticator.validateRequest with Request.getPathInfo =
>>> /auth/admin/
>>> FormAuthenticator.validateRequest, dispatching request /dump/auth/admin/
>>> with forward to /logon.html?param=test
>>>
>>> Handling the form submission:
>>> -----------------------------
>>> SecurityHandler.handle with
>>> Request.getRequestURI=/dump/auth/admin/j_security_check
>>> Preparing Constraint Info for pathIncontext:
>>> /dump/auth/admin/j_security_check
>>> There are mappings: httpMethod= POST RoleInfo=null
>>> ****** RoleInfo now: {RoleInfo,C[admin]} *************
>>> SecurityHandler.checkUserDataPermissions: No dataconstraint or is none
>>> isAuthMandatory=true for Request.getRequestURI=
>>> /dump/auth/admin/j_security_check
>>> FormAuthenticator.validateRequest with Request.getRequestURI =
>>> /dump/auth/admin/j_security_check
>>> FormAuthenticator.validateRequest with Request.getPathInfo =
>>> /auth/admin/j_security_check
>>> Is a j_security_check: /auth/admin/j_security_check
>>> Logging in
>>>
>>> The line marked with "******" shows that because the constraint is on
>>> the directory /admin/*
>>> it matches security constraints, whereas my constraint is on a single
>>> file, and therefore
>>> the /j_security_check url does not match any constraints.
>>>
>>> Have I created a stupid and unrealistic situation by protecting a single
>>> file like this? Or do we need to take a closer look at the way the
>>> constraint matching is done?
>>>
>>> cheers
>>> Jan
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
--
Jan Bartel, Webtide LLC | janb@... | http://www.webtide.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: Security Constraints problem
| Free embeddable forum powered by Nabble | Forum Help |
