[shale] component level render permissions

[Ryan Wynn <bi...@gmail.com>]

I was doing some work on enabling declarative component level render
permissions alongside shale-clay.  What I came up with was to use the
postProcessCreateComponent pluggable command in clay's chain.  In this
command I check the current component for an attribute called
'renderIfRoleIn'.  This attribute is designed to be a comma delimited
list of user roles.  I then check if the user's role is in this list
using request.isUserInRole(nextRole); if not I set the rendered
property of the component to false.

I was thinking this might be something that could be useful at a shale
or clay level.  If not at that level then maybe a shale-xxx.jar
plugin.  Any thoughts?

Ryan

Re: [shale] component level render permissions

[Ryan Wynn <bi...@gmail.com>]

On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> On 11/25/05, Ryan Wynn <bi...@gmail.com> wrote:
> >
> > On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> > > On 11/25/05, Ryan Wynn <bi...@gmail.com> wrote:
> > > >
> > > > I was doing some work on enabling declarative component level render
> > > > permissions alongside shale-clay.  What I came up with was to use the
> > > > postProcessCreateComponent pluggable command in clay's chain.  In this
> > > > command I check the current component for an attribute called
> > > > 'renderIfRoleIn'.  This attribute is designed to be a comma delimited
> > > > list of user roles.  I then check if the user's role is in this list
> > > > using request.isUserInRole(nextRole); if not I set the rendered
> > > > property of the component to false.
> > > >
> > > > I was thinking this might be something that could be useful at a shale
> > > > or clay level.  If not at that level then maybe a shale-xxx.jar
> > > > plugin.  Any thoughts?
> > > >
> > > > Ryan
> > >
> > >
> > > Interesting idea ... but I wonder if we are trying to bury too much
> > logic in
> > > the view tier with this approach?
> > >
> > > I'm just thinking that the next person who comes along will say "it's
> > not
> > > just user roles that matter for me, it's whether the user is the manager
> > of
> > > a particular department whose detailed information I'm about to display"
> > --
> > > a concept that I would not assume is represented as an explicit role (in
> > > terms of container managed security constraints).
> > >
> > > Wouldn't it be more general to just bind the rendered property of the
> > > component to a boolean function in your backing bean, which did the
> > > appropriate calculations?  One could certainly write some simple utility
> > > functions that did lookups based on arbitrary sets of roles (which would
> > > have to be encoded into the component somehow), or perhaps better would
> > be a
> > > set of predefined methods for all the interesting combinations
> > (isManager(),
> > > isUser(), isLoggedOn(), ...).  The implementations of these methods can
> > > implement whatever state checking is relevant, which may include roles
> > but
> > > may also include checking other information -- and these sorts of nitty
> > > gritty details are not something the page author should have to be
> > worried
> > > about.
> > >
> > > Craig
> > >
> > >
> >
> > Yeah, I agree with you Craig, it will invevitably become more complex.
> > I just thought that a good percentage of the cases with be based
> > simply on explicit roles.
> >
> > For these more complex cases it might be nice to be able to plug into
> > an existing chain that is designated for this rendering purpose.  For
> > example the default behavior of the chain is to keep the rendered
> > property as-is.  But if the user plugs in a chain at a specific entry
> > point then rendered could be overriden.
> >
> > For example in your scenario, it might be nice to be able to
> > 'chainize' in commands the isManager, isManagerOfDepartmentX,
> > isViewingDataX requirments.  Only to benefit from the separation of
> > concerns that chain offers.
> >
> > I guess from the framework point of view I would be asking to consider
> > an entry point.
>
>
> I guess here is where I'm wondering why we need a framework to accomplish
> this at all, given what JSF already provides?  Consider something like this,
> using JSP syntax:
>
>    <h:panelGrid ... rendered="#{
> securityChecks.managerOfAppropriateDepartment}">
>        ... components to conditionally display ...
>    </h:panelGrid>
>
> Of course, if you were using Clay, you'd use some defined equivalent of
> <h:panelGrid>.  But the key point is that you don't *have* to resolve all
> the attributes to literal values as part of the "configure the rendered
> components" process that Clay does when it parses the template ... simply
> pass on the value binding expression on, so that it gets evaluated by the
> component itself when the time is right.  The
> isManagerOfAppropriateDepartnement() method would check the departmentId
> field of the Manager bean against the department id of the department you're
> trying to display info for (so the method itself takes no parameters).
>
> This way, you can localize your security checks into a managed bean (or make
> it the page bean that corresponds to the page, if the issues are unique to
> that page), with the full capability to configure the security bean's
> behavior through managed bean property settings.
>
> This strategy also works well for both JSP and Clay presentation
> technologies, so you can use either (or both) in your application, as you
> choose.
>
> Thanks,
> > Ryan
> >
>
> Craig
>
>

I see what you mean.  No sense in reinventing the wheel.  I can always
have my managed bean properties be proxies to chains if I wanted to
use the design features that chain offers.

so my isManagerOfAppropriateDepartment() would lookup the
isManagerOfAppropriateDepartment catalog and that would execute
isManager and isAppropriateDepartment commands passing a suitable
Context.

Thanks.

Re: [shale] component level render permissions

[Sean Schofield <se...@gmail.com>]

> I guess here is where I'm wondering why we need a framework to accomplish
> this at all, given what JSF already provides?  Consider something like this,
> using JSP syntax:
>
>     <h:panelGrid ... rendered="#{
> securityChecks.managerOfAppropriateDepartment}">
>         ... components to conditionally display ...
>     </h:panelGrid>
>

I agree that it wouldn't be a good idea to have a comma delimited list
of roles.  The approach that Craig listed is better but I have a
problem with that approach.  There is still an implicit piece of
business logic in your binding expression that implies only "managers
of the appropriate department" can see/edit this field.  While this is
a hundred times better then hard-coding the roles I'm still not wild
about hard coding the manager aspect into the view.

Here is an alternative approach:

     <h:panelGrid ... rendered="#{fieldChecker['someFieldName']">
         ... components to conditionally display ...
     </h:panelGrid>

I have something like this in my app.  The fieldChecker bean
implements Map interface but it's basically a hack around the
limitation of not being able to pass in a parameter into a value
binding expression.  IMO this is a classic case of where you need to.

I have a field-restrictions.xml file which contains the mapping of all
the restrictions.  In my case, fields can be restricted by role or by
workflow state.  So if you add more restrictions (or new types of
restrictions), then you can just plug them in without disturbing your
view jsp.

I know its a bit of a hack, but again, I think its justified.  We have
100+ fields in our app that need restrictions.  I'm not going to add
100+ unecessary methods to delegate to my field checker when a simple
EL expression will suffice.

I'm interested in people's thoughts on this solution.  If there is a
better way, I'd like to know.

> Craig

sean

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

Re: [shale] component level render permissions

[Craig McClanahan <cr...@apache.org>]

On 11/25/05, Ryan Wynn <bi...@gmail.com> wrote:
>
> On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> > On 11/25/05, Ryan Wynn <bi...@gmail.com> wrote:
> > >
> > > I was doing some work on enabling declarative component level render
> > > permissions alongside shale-clay.  What I came up with was to use the
> > > postProcessCreateComponent pluggable command in clay's chain.  In this
> > > command I check the current component for an attribute called
> > > 'renderIfRoleIn'.  This attribute is designed to be a comma delimited
> > > list of user roles.  I then check if the user's role is in this list
> > > using request.isUserInRole(nextRole); if not I set the rendered
> > > property of the component to false.
> > >
> > > I was thinking this might be something that could be useful at a shale
> > > or clay level.  If not at that level then maybe a shale-xxx.jar
> > > plugin.  Any thoughts?
> > >
> > > Ryan
> >
> >
> > Interesting idea ... but I wonder if we are trying to bury too much
> logic in
> > the view tier with this approach?
> >
> > I'm just thinking that the next person who comes along will say "it's
> not
> > just user roles that matter for me, it's whether the user is the manager
> of
> > a particular department whose detailed information I'm about to display"
> --
> > a concept that I would not assume is represented as an explicit role (in
> > terms of container managed security constraints).
> >
> > Wouldn't it be more general to just bind the rendered property of the
> > component to a boolean function in your backing bean, which did the
> > appropriate calculations?  One could certainly write some simple utility
> > functions that did lookups based on arbitrary sets of roles (which would
> > have to be encoded into the component somehow), or perhaps better would
> be a
> > set of predefined methods for all the interesting combinations
> (isManager(),
> > isUser(), isLoggedOn(), ...).  The implementations of these methods can
> > implement whatever state checking is relevant, which may include roles
> but
> > may also include checking other information -- and these sorts of nitty
> > gritty details are not something the page author should have to be
> worried
> > about.
> >
> > Craig
> >
> >
>
> Yeah, I agree with you Craig, it will invevitably become more complex.
> I just thought that a good percentage of the cases with be based
> simply on explicit roles.
>
> For these more complex cases it might be nice to be able to plug into
> an existing chain that is designated for this rendering purpose.  For
> example the default behavior of the chain is to keep the rendered
> property as-is.  But if the user plugs in a chain at a specific entry
> point then rendered could be overriden.
>
> For example in your scenario, it might be nice to be able to
> 'chainize' in commands the isManager, isManagerOfDepartmentX,
> isViewingDataX requirments.  Only to benefit from the separation of
> concerns that chain offers.
>
> I guess from the framework point of view I would be asking to consider
> an entry point.


I guess here is where I'm wondering why we need a framework to accomplish
this at all, given what JSF already provides?  Consider something like this,
using JSP syntax:

    <h:panelGrid ... rendered="#{
securityChecks.managerOfAppropriateDepartment}">
        ... components to conditionally display ...
    </h:panelGrid>

Of course, if you were using Clay, you'd use some defined equivalent of
<h:panelGrid>.  But the key point is that you don't *have* to resolve all
the attributes to literal values as part of the "configure the rendered
components" process that Clay does when it parses the template ... simply
pass on the value binding expression on, so that it gets evaluated by the
component itself when the time is right.  The
isManagerOfAppropriateDepartnement() method would check the departmentId
field of the Manager bean against the department id of the department you're
trying to display info for (so the method itself takes no parameters).

This way, you can localize your security checks into a managed bean (or make
it the page bean that corresponds to the page, if the issues are unique to
that page), with the full capability to configure the security bean's
behavior through managed bean property settings.

This strategy also works well for both JSP and Clay presentation
technologies, so you can use either (or both) in your application, as you
choose.

Thanks,
> Ryan
>

Craig

Re: [shale] component level render permissions

[Ryan Wynn <bi...@gmail.com>]

On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> On 11/25/05, Ryan Wynn <bi...@gmail.com> wrote:
> >
> > I was doing some work on enabling declarative component level render
> > permissions alongside shale-clay.  What I came up with was to use the
> > postProcessCreateComponent pluggable command in clay's chain.  In this
> > command I check the current component for an attribute called
> > 'renderIfRoleIn'.  This attribute is designed to be a comma delimited
> > list of user roles.  I then check if the user's role is in this list
> > using request.isUserInRole(nextRole); if not I set the rendered
> > property of the component to false.
> >
> > I was thinking this might be something that could be useful at a shale
> > or clay level.  If not at that level then maybe a shale-xxx.jar
> > plugin.  Any thoughts?
> >
> > Ryan
>
>
> Interesting idea ... but I wonder if we are trying to bury too much logic in
> the view tier with this approach?
>
> I'm just thinking that the next person who comes along will say "it's not
> just user roles that matter for me, it's whether the user is the manager of
> a particular department whose detailed information I'm about to display" --
> a concept that I would not assume is represented as an explicit role (in
> terms of container managed security constraints).
>
> Wouldn't it be more general to just bind the rendered property of the
> component to a boolean function in your backing bean, which did the
> appropriate calculations?  One could certainly write some simple utility
> functions that did lookups based on arbitrary sets of roles (which would
> have to be encoded into the component somehow), or perhaps better would be a
> set of predefined methods for all the interesting combinations (isManager(),
> isUser(), isLoggedOn(), ...).  The implementations of these methods can
> implement whatever state checking is relevant, which may include roles but
> may also include checking other information -- and these sorts of nitty
> gritty details are not something the page author should have to be worried
> about.
>
> Craig
>
>

Yeah, I agree with you Craig, it will invevitably become more complex.
 I just thought that a good percentage of the cases with be based
simply on explicit roles.

For these more complex cases it might be nice to be able to plug into
an existing chain that is designated for this rendering purpose.  For
example the default behavior of the chain is to keep the rendered
property as-is.  But if the user plugs in a chain at a specific entry
point then rendered could be overriden.

For example in your scenario, it might be nice to be able to
'chainize' in commands the isManager, isManagerOfDepartmentX,
isViewingDataX requirments.  Only to benefit from the separation of
concerns that chain offers.

I guess from the framework point of view I would be asking to consider
an entry point.

Thanks,
Ryan

Re: [shale] component level render permissions

[Craig McClanahan <cr...@apache.org>]

On 11/25/05, Ryan Wynn <bi...@gmail.com> wrote:
>
> I was doing some work on enabling declarative component level render
> permissions alongside shale-clay.  What I came up with was to use the
> postProcessCreateComponent pluggable command in clay's chain.  In this
> command I check the current component for an attribute called
> 'renderIfRoleIn'.  This attribute is designed to be a comma delimited
> list of user roles.  I then check if the user's role is in this list
> using request.isUserInRole(nextRole); if not I set the rendered
> property of the component to false.
>
> I was thinking this might be something that could be useful at a shale
> or clay level.  If not at that level then maybe a shale-xxx.jar
> plugin.  Any thoughts?
>
> Ryan


Interesting idea ... but I wonder if we are trying to bury too much logic in
the view tier with this approach?

I'm just thinking that the next person who comes along will say "it's not
just user roles that matter for me, it's whether the user is the manager of
a particular department whose detailed information I'm about to display" --
a concept that I would not assume is represented as an explicit role (in
terms of container managed security constraints).

Wouldn't it be more general to just bind the rendered property of the
component to a boolean function in your backing bean, which did the
appropriate calculations?  One could certainly write some simple utility
functions that did lookups based on arbitrary sets of roles (which would
have to be encoded into the component somehow), or perhaps better would be a
set of predefined methods for all the interesting combinations (isManager(),
isUser(), isLoggedOn(), ...).  The implementations of these methods can
implement whatever state checking is relevant, which may include roles but
may also include checking other information -- and these sorts of nitty
gritty details are not something the page author should have to be worried
about.

Craig

Re: [shale] component level render permissions

[Alexandre Poitras <al...@gmail.com>]

I would be interested as I need to enable security in my application.

On 11/25/05, Ryan Wynn <bi...@gmail.com> wrote:
> I was doing some work on enabling declarative component level render
> permissions alongside shale-clay.  What I came up with was to use the
> postProcessCreateComponent pluggable command in clay's chain.  In this
> command I check the current component for an attribute called
> 'renderIfRoleIn'.  This attribute is designed to be a comma delimited
> list of user roles.  I then check if the user's role is in this list
> using request.isUserInRole(nextRole); if not I set the rendered
> property of the component to false.
>
> I was thinking this might be something that could be useful at a shale
> or clay level.  If not at that level then maybe a shale-xxx.jar
> plugin.  Any thoughts?
>
> Ryan
>


--
Alexandre Poitras
Québec, Canada

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