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 >> >> <filter-mapping> >> <filter-name>wicket</filter-name> >> <url-pattern>/*</url-pattern> >> </filter-mapping> >> >> <security-constraint> >> <display-name>Login page</display-name> >> <web-resource-collection> >> <web-resource-name>Login page</web-resource-name> >> <url-pattern>/login</url-pattern> >> <http-method>GET</http-method> >> <http-method>POST</http-method> >> </web-resource-collection> >> <auth-constraint> >> <role-name>*</role-name> >> </auth-constraint> >> </security-constraint> >> >> <login-config> >> <auth-method>FORM</auth-method> >> <realm-name>sso</realm-name> >> <form-login-config> >> <form-login-page>/login</form-login-page> >> <form-error-page>/login</form-error-page> >> </form-login-config> >> </login-config> >> >> >> /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 <role-name>*</role-name> we have configured >> <jacc-star-role-allow>true</jacc-star-role-allow> in jboss-web.xml. >> >> Any advice or solutions would be appreciated! >> >> >> >> >> >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- 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: [email protected] For additional commands, e-mail: [email protected]
