You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by "J.AL" <jo...@statnett.no> on 2008/12/19 10:49:29 UTC
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
<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!
--
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Container managed authentication
Posted by "J.AL" <jo...@statnett.no>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Container managed authentication
Posted by Serkan Camurcuoglu <Se...@telenity.com>.
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.
<dispatcher>REQUEST</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>FORWARD</dispatcher>
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
>>>
>>> <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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Container managed authentication
Posted by "J.AL" <jo...@statnett.no>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Container managed authentication
Posted by Serkan Camurcuoglu <Se...@telenity.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org