|
»
Security Constraints problem
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
Security Constraints problem
by jan_bartel
::
Rate this Message:
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 |
|
|
Re: Security Constraints problem
by Greg Wilkins
::
Rate this Message:
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 |
|
|
Re: Re: Security Constraints problem
by janb
::
Rate this Message:
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 |
|
|
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 |
|
|
Re: Security Constraints problem
by djencks
::
Rate this Message:
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 |
|
|
|
|
|
Re: Re: Security Constraints problem
by djencks
::
Rate this Message:
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 |
|
|
Re: Re: Security Constraints problem
by janb
::
Rate this Message:
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 | janb@... | http://www.webtide.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Free embeddable forum powered by Nabble | Forum Help |
