Re: Security framework (not only a pull tool), Part 1

[Eric Dobbs <er...@dobbse.net>]

On Sunday, October 28, 2001, at 01:37  AM, jaco@libero.it wrote:

> If I have well understood this is your solution:
> DEVELOPER:
> a) he assigns a (Turbine) group to screens and actions
> b) he sets (Turbine) permissions within screens and actions (where are
> needed)
> DEPLOYER:
> a) he groups together permissions in roles
> b) he assigns to users the needed roles in groups
> So, the developer 'creates' groups and permissions, the
> deployer 'creates' roles. A 'group' is a group (!) of related actions
> and screens.
> IMHO this is a very clever solution and also a good approach for using
> groups, roles etc...
> I must confess that I was looking for a solution like this (a few days
> ago, I wrote a message on this subject, see "Best way to use groups,
> roles, permissions..."): do you think this could become a standard
> approach?

Sorry I wasn't paying closer attention to that thread.  What do
you mean by "standard approach?"  Are you mainly asking to see
an addition to the Turbine documentation which explains these
typical uses for Turbine User, Group, Role, and Permission?



>>> The DEVELOPER, the one that creates the modules (mainly screen and
>>> action
>>> classes), has the following responsibilities:
>>> a) he assigns a security label (name) to the module (modules with
> the
>>> same
>>> name, e.g. a default name, share the same security config
> parameters):
>>> we
>>> could think of it as a family name
>>
>> I believe the Turbine "group" serves this same purpose.  It's a
>> developer defined label which is given to a collection of screens
>> and actions.
>
> Within my system, the deployer can give a different name to each screen
> and action: this allows the deployer to configure the security related
> stuff of each module in a different way (however this is not mandatory,
> since the deployer can set a default module security configuration for
> all the modules that are not explicitly configured).
> With your solution the number of groups could be very high.

If I understand you correctly, this sounds like something that is
not covered elegantly by the existing Turbine security.  Please
explain how the default module security works again because I'm not
sure I get it.  Here's how I think Turbine security could be used
to accomplish the notion you give for "a default module security
configuration."

One could use Turbine's global group and a "global" role.

#set ($acl = $data.ACL)
#if ($acl.hasPermission("foo") || $acl.hasPermission("foo","bar"))
    ## show "bar" stuff here
#end

hasPermission("foo") checks for "foo" permission in the global
group.  hasPermission("foo","bar") checks for "foo" permission
within the "bar" group.  In order to make the above template code
meaningful the Developer would need to be sure that all users had
a "global" role within the global group.  Then the Deployer would
be able to assign the default permissions to the "global" role.

I think the scenario I have just described is not elegant, but
it seems like it would handle the case of "a default module
security configuration."


[snip]
>>> The TEMPLATE (Velocity) DESIGNER has the following responsibility:
>>> a) due to security constraints, some users could see different
> things
>>> in the
>>> page... he has to know what could change and, accordingly to this,
>>> design
>>> the template correctly.
>>
>> So in the template you might find something like this
>> #if ($data.ACL.hasPermission("DISPLAY_PRICE"))
>>      ## display the price column here
>> #end
>>
>
> By using a different () permission every time you need to set a check
> point could be boring:
> how many permissions will be generated?
> what about permissions' name conflict(e.g. in group "billing", I have
> two screens with a "DISPLAY_PRICE" permission, but with different
> meanings)

Please explain how would this be different in your solution?
If I'm correct about the similarity between a Turbine
permission and your "task" it seems to me the template designer
is in for the same amount of work either way.


[snip]
> Maybe you are right, the concepts of "module names" and "tasks" are
> fairly similar to the concepts of "groups" and "permissions" but IMHO
> by them you can:
> 1) leave the maximum flexibility to the deployer in the decision of how
> to use groups, roles, permissions (What is a group/role/permission?
> How many groups/roles/permissions does he want to manage?). We don't
> make any assumption on them: since there is not (unfortunately) a
> consolidated standard way of using groups, etc.. this could be an
> interesting point

I think we are agreed on the goal of flexibility for the deployer.
But I am not yet convinced that your solution is sufficiently
better than Turbine's existing tools for meeting that goal.  And I
find Turbine's tools more easy to understand (which is extremely
important for our application).


> 2) link to a task a very complex security check (e.g. for task "access"
> are allowed: the users with role "operator" AND role "configurator" in
> group "global" OR permission "update" in group "admin" etc. etc.) or a
> very basic one without changing the code; the code is always:
> if (isAllowed("access")) {
> // access granted
> }

This aspect of your solution does seem to go beyond Turbine's
security.  None of the applications that I have been working on
need that kind of complexity in the security configuration.  In
this area I think you have added more flexibility, but it is
more than I think I would ever need to use and also much more
confusing.

But I'm intrigued enough by this idea of attaching complex rules
to a "task" that I'm still willing to be persuaded.


> Sorry for the length of this message and thank you for the time you are
> spending for this thread,

It happens that I have a few other things at work that need
thinking about security in Turbine apps, so this thread is well
timed.

-Eric

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Security framework (not only a pull tool), Part 1

[Jacopo Cappellato <ja...@libero.it>]

Hi Eric,

----- Original Message -----
From: Eric Dobbs <er...@dobbse.net>
To: <tu...@jakarta.apache.org>
Sent: Tuesday, November 06, 2001 1:33 AM
Subject: Re: Security framework (not only a pull tool), Part 1
>
> Sorry I wasn't paying closer attention to that thread.  What do
> you mean by "standard approach?"  Are you mainly asking to see
> an addition to the Turbine documentation which explains these
> typical uses for Turbine User, Group, Role, and Permission?
>

Yes Eric, I'm looking for documentation regarding 'best practices' on using
Turbine User, Group, Role, and Permission... I've found something in
http://cvs.apache.org/viewcvs/jakarta-turbine-flux/xdocs/ (an interesting
discussion among Jason, Rafal and Fedor).
I'm a Turbine newbie: every day I discover new things on Turbine... at now
I'm interested in setting a good approach for
integrating security in Turbine webapps... if I can't find the solution that
I need then I try to build a new one: this is what I've done with the
security framework. I'm not sure that the result is good: maybe

> >
> > Within my system, the deployer can give a different name to each screen
> > and action: this allows the deployer to configure the security related
> > stuff of each module in a different way (however this is not mandatory,
> > since the deployer can set a default module security configuration for
> > all the modules that are not explicitly configured).
> > With your solution the number of groups could be very high.
>
> If I understand you correctly, this sounds like something that is
> not covered elegantly by the existing Turbine security.  Please
> explain how the default module security works again because I'm not
> sure I get it.  Here's how I think Turbine security could be used
> to accomplish the notion you give for "a default module security
> configuration."
>
> One could use Turbine's global group and a "global" role.
>
> #set ($acl = $data.ACL)
> #if ($acl.hasPermission("foo") || $acl.hasPermission("foo","bar"))
>     ## show "bar" stuff here
> #end
>
> hasPermission("foo") checks for "foo" permission in the global
> group.  hasPermission("foo","bar") checks for "foo" permission
> within the "bar" group.  In order to make the above template code
> meaningful the Developer would need to be sure that all users had
> a "global" role within the global group.  Then the Deployer would
> be able to assign the default permissions to the "global" role.
>
> I think the scenario I have just described is not elegant, but
> it seems like it would handle the case of "a default module
> security configuration."
>

I'm going to describe how you could configure my system to do the same
security checks of your example:
DEVELOPER:
// this code is extracted from, let's say,  the YourExampleScreen class:
if (isAllowed("display_bar_task")) {
    // add bar stuff to the context
}
DEPLOYER: the deployer has different options
1) Worste case (a lot of code)
# The following two lines do exactly the same things of your code
security.screen.YourExampleScreen.display_bar_task.global.permissions = foo
security.screen.YourExampleScreen.display_bar_task.bar.permissions = foo
2) Similar to point 1
# For the all the tasks (here the "default" keyword is in place of
"display_bar_task")
# defined in YourExampleScreen perform the same
# security checks (foo in global, foo in bar)
security.screen.YourExampleScreen.default.global.permissions = foo
security.screen.YourExampleScreen.default.bar.permissions = foo
3) This uses a default module rule definition
# This is a default module definition:
# for a generic task in a generic screen perform two security
# checks (foo in global, foo in bar)
security.screen.default.default.global.permissions = foo
security.screen.default.default.bar.permissions = foo
# We could override the default rules for a task of a a screen; for example:
# for the new task "change_value" defined in YourExampleScreen perform the
# following security checks: has the user the foo AND write permissions in
global group?
security.screen.YourExampleScreen.change_value.global.permissions = foo &
write

> > By using a different () permission every time you need to set a check
> > point could be boring:
> > how many permissions will be generated?
> > what about permissions' name conflict(e.g. in group "billing", I have
> > two screens with a "DISPLAY_PRICE" permission, but with different
> > meanings)
>
> Please explain how would this be different in your solution?
> If I'm correct about the similarity between a Turbine
> permission and your "task" it seems to me the template designer
> is in for the same amount of work either way.
>
>

The work is the same only if we make the following assumption:
every template belongs to one Turbine group and every security check
is made against one permission. Am I wrong?
I'm not saying that this is a big problem...
I'm only trying to fix some points (a 'best practice').
When I developed my framework I didn't know that there was a preferred way
to set groups, roles, permissions (e.g. that is better to perform a check
against a permission
rather than a role; that it is a good way to assign each screen to a group
and so on) and so my
effort was to keep things as flexible as possible... maybe I re-invented the
wheel but I'm not so sure...

> [snip]
> > Maybe you are right, the concepts of "module names" and "tasks" are
> > fairly similar to the concepts of "groups" and "permissions" but IMHO
> > by them you can:
> > 1) leave the maximum flexibility to the deployer in the decision of how
> > to use groups, roles, permissions (What is a group/role/permission?
> > How many groups/roles/permissions does he want to manage?). We don't
> > make any assumption on them: since there is not (unfortunately) a
> > consolidated standard way of using groups, etc.. this could be an
> > interesting point
>
> I think we are agreed on the goal of flexibility for the deployer.
> But I am not yet convinced that your solution is sufficiently
> better than Turbine's existing tools for meeting that goal.  And I
> find Turbine's tools more easy to understand (which is extremely
> important for our application).
>

Maybe you are right...

>
> > 2) link to a task a very complex security check (e.g. for task "access"
> > are allowed: the users with role "operator" AND role "configurator" in
> > group "global" OR permission "update" in group "admin" etc. etc.) or a
> > very basic one without changing the code; the code is always:
> > if (isAllowed("access")) {
> > // access granted
> > }
>
> This aspect of your solution does seem to go beyond Turbine's
> security.  None of the applications that I have been working on
> need that kind of complexity in the security configuration.  In
> this area I think you have added more flexibility, but it is
> more than I think I would ever need to use and also much more
> confusing.
>

Hmmm... same as before...

> But I'm intrigued enough by this idea of attaching complex rules
> to a "task" that I'm still willing to be persuaded.
>
> -Eric
>

Thank you Eric,

Jacopo




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>