Security Constraints problem

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Security Constraints problem

jan_bartel
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


Reply | Threaded
Open this post in threaded view
|

Re: Security Constraints problem

Greg Wilkins

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


Reply | Threaded
Open this post in threaded view
|

Re: Re: Security Constraints problem

Jan Bartel
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 | [hidden email] | http://www.webtide.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Re: Security Constraints problem

Jan Bartel
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 | [hidden email] | http://www.webtide.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Security Constraints problem

djencks
In reply to this post by jan_bartel
I won't be able to look into this until late today or tomorrow (on a  
plane) but there's something wrong and so far I think we shouldn't  
need special handling for this.

thanks
david jencks


On Jun 1, 2009, at 1:11 AM, 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
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Re: Security Constraints problem

Greg Wilkins
In reply to this post by Jan Bartel
Jeff McAffer wrote:
> FYI, the Eclipse webmaster has enabled the security feature on bugzilla
> that limits the visibility of security related discussions in an effort
> to reduce exploits.  Bugs can be marked as security related (on the bug
> itself).  From that point on only committers (I believe) can read the
> bug.  Use as your discretion.

Cool! Good feature!

but in this case it is a problem of a new feature in development, and is
not so much an exploit as a failure to login.   So it good for this to
be open.

Jan - any luck reproducing with the test harness?

I'm pretty sure this is something to do with the fact that we now scope
for servlets before calling the security handler, so the path is
now split into servletPath and pathInfo depending on the mappings.

I think the security stuff was only looking at pathInfo because it used to
only be called before servlet scoping.

cheers



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Re: Security Constraints problem

djencks

On Jun 1, 2009, at 8:47 AM, Greg Wilkins wrote:

> Jeff McAffer wrote:
>> FYI, the Eclipse webmaster has enabled the security feature on  
>> bugzilla
>> that limits the visibility of security related discussions in an  
>> effort
>> to reduce exploits.  Bugs can be marked as security related (on the  
>> bug
>> itself).  From that point on only committers (I believe) can read the
>> bug.  Use as your discretion.
>
> Cool! Good feature!
>
> but in this case it is a problem of a new feature in development,  
> and is
> not so much an exploit as a failure to login.   So it good for this to
> be open.
>
> Jan - any luck reproducing with the test harness?
>
> I'm pretty sure this is something to do with the fact that we now  
> scope
> for servlets before calling the security handler, so the path is
> now split into servletPath and pathInfo depending on the mappings.
>
> I think the security stuff was only looking at pathInfo because it  
> used to
> only be called before servlet scoping.

Right, that's the problem.  I opened bug 278887 and patched  
FormAuthenticator like this:

-        String uri = request.getPathInfo();
+        String uri = request.getRequestURL().toString();


Is there a string already computed that would work as well as  
getRequestURL() and be quicker than constructing a StringBuffer and  
then a String?

thanks
david jencks

>
>
> cheers
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Re: Security Constraints problem

Jan Bartel
Request.getRequestURI() ?


Jan

David Jencks wrote:

>
> On Jun 1, 2009, at 8:47 AM, Greg Wilkins wrote:
>
>> Jeff McAffer wrote:
>>> FYI, the Eclipse webmaster has enabled the security feature on bugzilla
>>> that limits the visibility of security related discussions in an effort
>>> to reduce exploits.  Bugs can be marked as security related (on the bug
>>> itself).  From that point on only committers (I believe) can read the
>>> bug.  Use as your discretion.
>>
>> Cool! Good feature!
>>
>> but in this case it is a problem of a new feature in development, and is
>> not so much an exploit as a failure to login.   So it good for this to
>> be open.
>>
>> Jan - any luck reproducing with the test harness?
>>
>> I'm pretty sure this is something to do with the fact that we now scope
>> for servlets before calling the security handler, so the path is
>> now split into servletPath and pathInfo depending on the mappings.
>>
>> I think the security stuff was only looking at pathInfo because it
>> used to
>> only be called before servlet scoping.
>
> Right, that's the problem.  I opened bug 278887 and patched
> FormAuthenticator like this:
>
> -        String uri = request.getPathInfo();
> +        String uri = request.getRequestURL().toString();
>
>
> Is there a string already computed that would work as well as
> getRequestURL() and be quicker than constructing a StringBuffer and then
> a String?
>
> thanks
> david jencks
>
>>
>>
>> cheers
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>

--
Jan Bartel, Webtide LLC | [hidden email] | http://www.webtide.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email