I used interfaces to get this to work. So every Security Assert defines also
an interface that should be implemented by the Actions. It took a while, but
it's working now. Thanks for the advices.
2010/12/14 Chris Pratt <thechrispr...@gmail.com>
> If you just need access to the parameters from the action, you can use:
>
> String resource =
>
> invocation.getProxy().getConfig().getParams().get("AuthoritationInterceptor.resource");
>
> I've used this several times to get parameters from the configuration, but
> I
> usually put the parameters on the action instead of on the interceptor
> since
> I consider them resources of the action invocation. I don't know if this
> would also access the interceptor params or not. I would go with something
> more like:
>
>
> [...]
> <action name="Dashboard" class="com.test.action.
> >
> > Dashboard">
> > <interceptor-ref name="mvcStack"/>
> > <param name="AuthoritationInterceptor.resource">Eco</param>
> > <result name="MenuGestor" type="tiles">MenuGestor</result>
> > <result name="MenuBanquero" type="tiles">MenuBanquero</result>
> > <result name="MenuCliente" type="tiles" >MenuCliente</result>
> > </action>
> > [...]
> >
> (*Chris*)
>
> On Mon, Dec 13, 2010 at 9:05 PM, JOSE L MARTINEZ-AVIAL <jlm...@gmail.com
> >wrote:
>
> > I know that the inteceptor knows which action is invoked. I just don't
> want
> > it to need to be aware of that. That's why I assigned a resource for each
> > action, using a parameter in the definition of the action:
> >
> > [...]
> > <action name="Dashboard" class="com.test.action.Dashboard">
> > <interceptor-ref name="mvcStack">
> > <param
> name="AuthoritationInterceptor.resource">Eco</param>
> > </interceptor-ref>
> > <result name="MenuGestor" type="tiles">MenuGestor</result>
> > <result name="MenuBanquero" type="tiles">MenuBanquero</result>
> > <result name="MenuCliente" type="tiles" >MenuCliente</result>
> > </action>
> > [...]
> >
> > I could implement an interface for the action, but that would require
> > defining an interface for each rule(since each rule needs different
> > parameters). The second options is valid, but I like the idea of just
> > declaring the getXXX method in the rule, and having the framework do the
> > work for me(mostly, the type-conversion). What do you think?
> >
> >
> > 2010/12/13 Maurizio Cucchiara <maurizio.cucchi...@gmail.com>
> >
> > > Ok, now it's definitively clear.
> > > First every interceptor knows exactly which action is invoked through
> > > action
> > > invocation.
> > > With that said your action could implement (1) your custom interface or
> > (2)
> > > a generic Request Aware interface in order to retrieve request
> > parameters.
> > > Does this answer your question?
> > >
> > > Maurizio Cucchiara
> > >
> > > Il giorno 14/dic/2010 03.27, "JOSE L MARTINEZ-AVIAL" <jlm...@gmail.com
> >
> > ha
> > > scritto:
> > > Hi Maurizio, Li,
> > > Thanks for your suggestion, but the problem with the approaches you
> > > suggested is that they link the security rules too much to the actions.
> > We
> > > want to be as abstract as possible. For that, we have developed the
> > > following implementation:
> > >
> > > We created some entities called SecurityResource which represent a set
> > of
> > > possible user actions. For example, we can have a SecurityResource
> called
> > > SeeCustomer, that would be applied to any request related with seeing a
> > > customer, or a SecurityResource called ModifyOwnProfile, used to filter
> > any
> > > action related to the modification of the profile. Every Action (unless
> > it
> > > is public) in the system is associated to a resource.
> > >
> > > We have also define some entities called SecurityAssert. A
> > SecurityAssert
> > > is a rule that checks some conditions, and returns true or false. They
> > are
> > > implemented through classes that implement a specific interface. For
> each
> > > SecurityResource we have a list of SecurityAsserts that need to be
> > > validated. So our security definition look as follows:
> > >
> > > <security-assert-definition name="SecurityAssertHasRole"
> > > class="com.test.rules.SecurityAssertHasRole">
> > > <description>Regla de seguridad para comprobar si un usuario
> > > tiene un rol</description>
> > > </security-assert-definition>
> > >
> > > <security-assert-definition name="SecurityAssertDistributionList"
> > > class="com.test.rules.SecurityAssertDistributionList">
> > > <description>Regla de seguridad para comprobar si un usuario
> > > puede acceder a las listas de distribucion</description>
> > > </security-assert-definition>
> > >
> > > <security-resource name="Eco">
> > > <security-assert-ref name="SecurityAssertHasRole"
> > > character="mandatory">
> > > <parameter name="allowedRoles">
> > > <value>Role1</value>
> > > <value>Role2</value>
> > > <value>Role3</value>
> > > </parameter>
> > > </security-assert-ref>
> > > </security-resource>
> > >
> > > Some of the rules need information from the request(customer number,
> for
> > > example). In an ideal world the interceptor should not know anything
> > about
> > > the action it is trying to check. It should only invoke the rules, and
> > > check
> > > their results. So I(the interceptor) should to be able to pass
> parameters
> > > from the request to the rule without actually having to know anything
> > about
> > > the request or the rules. Maybe the approach is complex, but we are
> > > planning
> > > to have some hundredths of actions, and be able to be as granular and
> > > modular as possible with respect to security. Any ideas?
> > >
> > > thanks
> > >
> > > JL
> > >
> > > 2010/12/12 Li Ying <liying.cn.2...@gmail.com>
> > >
> > >
> > > > I think you don't need this bothering job.
> > > >
> > > > You can:
> > > >
> > > > (1)Define some properties in your bas...
> > >
> >
>
