Re: Container managed authentication
Thanks for the help. According to Scott Dark himself at JBoss it's impossible to apply the wicket filter before the container redirects to the form-login-page so it seems like we have to use a plain jsp for our login page, or create a custom FormAuthenticator for catalina that allows this. Another option is to do a programmatic authentication, but this will lock parts of our application to JBoss since a pure JAAS authentication will not work with the Single Sign On valve or the webcontainer's isUserInRole/getUserPrincipal. -- View this message in context: http://www.nabble.com/Container-managed-authentication-tp21088523p21091030.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Container managed authentication
First, one recommendation is, adding the following lines to your filter-mapping element may cause wicket filter to be used when the container automatically forwards to your login page. REQUEST INCLUDE FORWARD Containers usually keep the original request address and then they automatically redirect to the original address after successful login, so you may not have to keep the original intercepted request. Actually, the normal way of doing container managed authentication is to declare all your wicket urls as protected resources, and using a non-protected login page. Anyway, I have done container managed authentication by using a simple jsp instead of a wicket page, and I've only used tomcat, so I can't help you directly. I think you should keep on experimenting using this information, and you will definitely be able to find a solution. Good luck.. INCLUDE J.AL wrote: Have tried this, and I was probably a bit diffuse in my problem description. If we try to redirect to j_security_check from our login page mounted at /slogin we get the typical "HTTP Status 400 - Invalid direct reference to form login page". Using a dummy page as the sign in page mounted at /login, and protecting this by the security constraint that uses the "real" login page mounted at /slogin as its form-login-page works, but then we need a way to access the servletresponse in WebApplications's newWebRequest(HttpServletRequest requesst) method so we can redirect to the initially requested page. Using this approch a new problem occured: accessing /login should force the container to redirect to /slogin, but then JBoss just gives us a HTTP Status 404 - /app/slogin. Accessing it directly works fine, so now it seems like the wicket filter isn't used when the container redirects to the form-login-page. Since a request might include something like /application/page?hostname=mmi3 we need to redirect to the intercepted page after login, and this could be solved if there is a way to access the HttpServletResponse associated with the HttpServletRequest supplied to the Application's newWebRequest(HttpServletRequest request). We use this method as a hook to check for a existing principal(eg. logged in by another application) and then store it in session for wicket-auth to take over. What we need is to redirect the user to the the initially requested page if the servlet request have a principal and our session don't. The initial requested page and its params are stored in the session when a onUnauthorizedComponentInstantiation() method call is triggered. Serkan Camurcuoglu-3 wrote: If the problem is caused by the fact that your protected resource and login page are the same, why not mount your login page at another url in addition to /login, for example /slogin or something.. J.AL wrote: Hi, we have standardized our web applications on the wicket framework (from a myriad of different frameworks), and are now looking to integrate authentication/authorization with conainter based Single Sign On using a valve in jboss/tomcats pipeline. We use wicket-auth-roles for authorization in wicket, and everything is configured so that the authorization requests end up in servlet requests isUserInRole() method. Everything regarding the SSO and authorization works fine, but we're having trouble to actually authenticate using a wicket based login page. Following the strategy from http://cwiki.apache.org/WICKET/servlet-container-authentication.html our web.xml setup is like this: web.xml setup wicket /* Login page Login page /login GET POST * FORM sso /login /login /login is our wicket login page that dispatches(using requestdispatcher.include()) the input to the j_security_check?j_username&j_password&j_profile check, and then checks the request for a principal and redirect to the originally intercepted page (ignoring response from the dispatched request). The problem is that this setup works as a dream in Jetty, but in JBoss the current web.xml setup do not work, since the protected login page and the form-login-page is the same. In other words, the "solution" on wickets wiki do not seem to work well on JBoss containers. A option is to make the form-login-page a pure jsp, but this would be the last resort, since we rely heavily on wickets ajax support in this page (we use custom JAAS security modules to support more than just username/password authentication). To support the * we have configured true in jboss-web.xml. Any advice or solutions would be appreciated! - To unsubscribe, e-mail: users-unsubscr...@wicket
Re: Container managed authentication
Have tried this, and I was probably a bit diffuse in my problem description. If we try to redirect to j_security_check from our login page mounted at /slogin we get the typical "HTTP Status 400 - Invalid direct reference to form login page". Using a dummy page as the sign in page mounted at /login, and protecting this by the security constraint that uses the "real" login page mounted at /slogin as its form-login-page works, but then we need a way to access the servletresponse in WebApplications's newWebRequest(HttpServletRequest requesst) method so we can redirect to the initially requested page. Using this approch a new problem occured: accessing /login should force the container to redirect to /slogin, but then JBoss just gives us a HTTP Status 404 - /app/slogin. Accessing it directly works fine, so now it seems like the wicket filter isn't used when the container redirects to the form-login-page. Since a request might include something like /application/page?hostname=mmi3 we need to redirect to the intercepted page after login, and this could be solved if there is a way to access the HttpServletResponse associated with the HttpServletRequest supplied to the Application's newWebRequest(HttpServletRequest request). We use this method as a hook to check for a existing principal(eg. logged in by another application) and then store it in session for wicket-auth to take over. What we need is to redirect the user to the the initially requested page if the servlet request have a principal and our session don't. The initial requested page and its params are stored in the session when a onUnauthorizedComponentInstantiation() method call is triggered. Serkan Camurcuoglu-3 wrote: > > If the problem is caused by the fact that your protected resource and > login page are the same, why not mount your login page at another url in > addition to /login, for example /slogin or something.. > > > > J.AL wrote: >> Hi, we have standardized our web applications on the wicket framework >> (from a >> myriad of different frameworks), and are now looking to integrate >> authentication/authorization with conainter based Single Sign On using a >> valve in jboss/tomcats pipeline. >> >> We use wicket-auth-roles for authorization in wicket, and everything is >> configured so that the authorization requests end up in servlet requests >> isUserInRole() method. Everything regarding the SSO and authorization >> works >> fine, but we're having trouble to actually authenticate using a wicket >> based >> login page. >> >> >> Following the strategy from >> http://cwiki.apache.org/WICKET/servlet-container-authentication.html our >> web.xml setup is like this: >> >> web.xml setup >> >> >> wicket >> /* >> >> >> >> Login page >> >> Login page >> /login >> GET >> POST >> >> >> * >> >> >> >> >> FORM >> sso >> >> /login >> /login >> >> >> >> >> /login is our wicket login page that dispatches(using >> requestdispatcher.include()) the input to the >> j_security_check?j_username&j_password&j_profile check, and then checks >> the >> request for a principal and redirect to the originally intercepted page >> (ignoring response from the dispatched request). >> >> The problem is that this setup works as a dream in Jetty, but in JBoss >> the >> current web.xml setup do not work, since the protected login page and the >> form-login-page is the same. In other words, the "solution" on wickets >> wiki >> do not seem to work well on JBoss containers. >> >> A option is to make the form-login-page a pure jsp, but this would be the >> last resort, since we rely heavily on wickets ajax support in this page >> (we >> use custom JAAS security modules to support more than just >> username/password >> authentication). >> >> To support the * we have configured >> true in jboss-web.xml. >> >> Any advice or solutions would be appreciated! >> >> >> >> >> >> >> >> >> > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/Container-managed-authentication-tp21088523p21090370.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Container managed authentication
If the problem is caused by the fact that your protected resource and login page are the same, why not mount your login page at another url in addition to /login, for example /slogin or something.. J.AL wrote: Hi, we have standardized our web applications on the wicket framework (from a myriad of different frameworks), and are now looking to integrate authentication/authorization with conainter based Single Sign On using a valve in jboss/tomcats pipeline. We use wicket-auth-roles for authorization in wicket, and everything is configured so that the authorization requests end up in servlet requests isUserInRole() method. Everything regarding the SSO and authorization works fine, but we're having trouble to actually authenticate using a wicket based login page. Following the strategy from http://cwiki.apache.org/WICKET/servlet-container-authentication.html our web.xml setup is like this: web.xml setup wicket /* Login page Login page /login GET POST * FORM sso /login /login /login is our wicket login page that dispatches(using requestdispatcher.include()) the input to the j_security_check?j_username&j_password&j_profile check, and then checks the request for a principal and redirect to the originally intercepted page (ignoring response from the dispatched request). The problem is that this setup works as a dream in Jetty, but in JBoss the current web.xml setup do not work, since the protected login page and the form-login-page is the same. In other words, the "solution" on wickets wiki do not seem to work well on JBoss containers. A option is to make the form-login-page a pure jsp, but this would be the last resort, since we rely heavily on wickets ajax support in this page (we use custom JAAS security modules to support more than just username/password authentication). To support the * we have configured true in jboss-web.xml. Any advice or solutions would be appreciated! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Container managed authentication
Hi, we have standardized our web applications on the wicket framework (from a myriad of different frameworks), and are now looking to integrate authentication/authorization with conainter based Single Sign On using a valve in jboss/tomcats pipeline. We use wicket-auth-roles for authorization in wicket, and everything is configured so that the authorization requests end up in servlet requests isUserInRole() method. Everything regarding the SSO and authorization works fine, but we're having trouble to actually authenticate using a wicket based login page. Following the strategy from http://cwiki.apache.org/WICKET/servlet-container-authentication.html our web.xml setup is like this: web.xml setup wicket /* Login page Login page /login GET POST * FORM sso /login /login /login is our wicket login page that dispatches(using requestdispatcher.include()) the input to the j_security_check?j_username&j_password&j_profile check, and then checks the request for a principal and redirect to the originally intercepted page (ignoring response from the dispatched request). The problem is that this setup works as a dream in Jetty, but in JBoss the current web.xml setup do not work, since the protected login page and the form-login-page is the same. In other words, the "solution" on wickets wiki do not seem to work well on JBoss containers. A option is to make the form-login-page a pure jsp, but this would be the last resort, since we rely heavily on wickets ajax support in this page (we use custom JAAS security modules to support more than just username/password authentication). To support the * we have configured true in jboss-web.xml. Any advice or solutions would be appreciated! -- View this message in context: http://www.nabble.com/Container-managed-authentication-tp21088523p21088523.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org