You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ken McWilliams <ke...@gmail.com> on 2012/10/03 02:25:09 UTC

Struts2 authentication, validation, and roles

Asking for the consideration of a struts2 feature enhancement.

The roles interceptor depends on container based security, it is a bit
of a pain to set up and portability is complicated by needing to cover
more documentation steps (how to secure your application on Glassfish,
Weblogic, Tomcat...). This is container security and of course not
Struts2s issue but it would be nice it we could use the roles
interceptor by defining a
org.apache.struts2.interceptor.PrincipalProxy implementation and
specifying it with a struts2 constant:

<constant name="struts.security.principalProxy"
value="com.example.MyPrincipalProxyImpl"/> //default would be
org.apache.struts2.servlet.interceptor.ServletPrincipalProxy

There is only a few place (that I know of) where the PrincipalProxy
interface aught to be used where currently the request is being used
(aught to be used if implementing this feature). That is in the
"servletConfig" interceptor when setting the PrincipalAware interface
of an action and in the roles interceptor.

It is not too much work to implement our own interceptors to
facilitate role based access but I think this would be helpful to many
and does not seem to require a radical change to S2 internals, so I
thought I would bring this up in the user forum to see what others
think.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: Struts2 authentication, validation, and roles

Posted by Lukasz Lenart <lu...@apache.org>.
2012/10/3 Ken McWilliams <ke...@gmail.com>:
> Asking for the consideration of a struts2 feature enhancement.
>
> The roles interceptor depends on container based security, it is a bit
> of a pain to set up and portability is complicated by needing to cover
> more documentation steps (how to secure your application on Glassfish,
> Weblogic, Tomcat...). This is container security and of course not
> Struts2s issue but it would be nice it we could use the roles
> interceptor by defining a
> org.apache.struts2.interceptor.PrincipalProxy implementation and
> specifying it with a struts2 constant:
>
> <constant name="struts.security.principalProxy"
> value="com.example.MyPrincipalProxyImpl"/> //default would be
> org.apache.struts2.servlet.interceptor.ServletPrincipalProxy
>
> There is only a few place (that I know of) where the PrincipalProxy
> interface aught to be used where currently the request is being used
> (aught to be used if implementing this feature). That is in the
> "servletConfig" interceptor when setting the PrincipalAware interface
> of an action and in the roles interceptor.
>
> It is not too much work to implement our own interceptors to
> facilitate role based access but I think this would be helpful to many
> and does not seem to require a radical change to S2 internals, so I
> thought I would bring this up in the user forum to see what others
> think.

Nice idea, any better modularisation and higher user satisfaction is
always welcome (with patch as well ;-)


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: Struts2 authentication, validation, and roles

Posted by Łukasz Lenart <lu...@gmail.com>.
2012/10/3 Ken McWilliams <ke...@gmail.com>:
> Asking for the consideration of a struts2 feature enhancement.
>
> The roles interceptor depends on container based security, it is a bit
> of a pain to set up and portability is complicated by needing to cover
> more documentation steps (how to secure your application on Glassfish,
> Weblogic, Tomcat...). This is container security and of course not
> Struts2s issue but it would be nice it we could use the roles
> interceptor by defining a
> org.apache.struts2.interceptor.PrincipalProxy implementation and
> specifying it with a struts2 constant:
>
> <constant name="struts.security.principalProxy"
> value="com.example.MyPrincipalProxyImpl"/> //default would be
> org.apache.struts2.servlet.interceptor.ServletPrincipalProxy
>
> There is only a few place (that I know of) where the PrincipalProxy
> interface aught to be used where currently the request is being used
> (aught to be used if implementing this feature). That is in the
> "servletConfig" interceptor when setting the PrincipalAware interface
> of an action and in the roles interceptor.
>
> It is not too much work to implement our own interceptors to
> facilitate role based access but I think this would be helpful to many
> and does not seem to require a radical change to S2 internals, so I
> thought I would bring this up in the user forum to see what others
> think.

I thought a bit more about that and this can be achieved by a
PrincipalProvider (as TextProvider) which can be injected onto
interceptors or any other place. It will produce PrincipialProxy base
on HttpServletRequest, eg.
PrincipialProvider#getPrincipialProxy(HttpServletRequest)


Regards
-- 
Łukasz
mobile +48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: Struts2 authentication, validation, and roles

Posted by Gabriel Belingueres <be...@gmail.com>.
Hi:

I took a look at the ServletPrincipalProxy class, and it just
delegates to the current request object to resolve authorization
queries. There is not much more to do, since it is how the servlet
standard is defined (the HttpServletRequest interface is the only one
to query).

So implementing a _custom_ PrincipalProxy implies you get those roles
from *another object*, which means you are deviating from the standard
and then, from any other framework which may integrate security with
S2.

If what you really want is to avoid configure container managed
security for your app one vendor at a time, then you may give a try to
Spring Security.

HTH,
Gabriel

2012/10/2 Ken McWilliams <ke...@gmail.com>:
> Asking for the consideration of a struts2 feature enhancement.
>
> The roles interceptor depends on container based security, it is a bit
> of a pain to set up and portability is complicated by needing to cover
> more documentation steps (how to secure your application on Glassfish,
> Weblogic, Tomcat...). This is container security and of course not
> Struts2s issue but it would be nice it we could use the roles
> interceptor by defining a
> org.apache.struts2.interceptor.PrincipalProxy implementation and
> specifying it with a struts2 constant:
>
> <constant name="struts.security.principalProxy"
> value="com.example.MyPrincipalProxyImpl"/> //default would be
> org.apache.struts2.servlet.interceptor.ServletPrincipalProxy
>
> There is only a few place (that I know of) where the PrincipalProxy
> interface aught to be used where currently the request is being used
> (aught to be used if implementing this feature). That is in the
> "servletConfig" interceptor when setting the PrincipalAware interface
> of an action and in the roles interceptor.
>
> It is not too much work to implement our own interceptors to
> facilitate role based access but I think this would be helpful to many
> and does not seem to require a radical change to S2 internals, so I
> thought I would bring this up in the user forum to see what others
> think.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org