Jacopo,
I have been using the WeakScreen paradigm in test applications. Actually I
just extended VelocityScreen and VelocitySecureScreen into my own classes.
The idea of tying modules to security makes very good sense. It makes
applying security to applications flexible and easy to change quickly. I
also think that being able to have module tied to multiple groups is also a
good idea.
Maybe a good thing to do now is give a concrete definition of what a
"module" is (you may have already done this, if you did I must have missed
the post).
module: a logical organization of screens and actions that require a
certain, specific level of security to both initiate and complete a
transaction. Also, a module should be able to be built from pre-existing
modules to speed deployment and give a sense of object oriented security.
Here is a VERY rough representation in XML of how you could set up
module-level security. Please tell me what you think and add to this as you
see necessary. Comments and criticism are encouraged :)
<module-security>
<!--A standard security implementation for a module -->
<module name="see_stuff">
<!--Define which screens/actions are part of this module-->
<screen>
View.vm
</screen>
<action>
Search
</action>
<!--Define the required security for these screens/actions-->
<required-security>
<!--Use pre-existing groups and roles in Turbine-->
<group name="standard_user">
<!--User is only required to have the "View" role within the
"standard_user" group-->
<role>
View
</role>
</group>
</required-security>
</module>
<!--inherits all the screens, actions and security from see_stuff--->
<!--By extending "see_stuff", users that match any of the
required-security parameters of see_stuff or maintain_things can access
those screens and actions within see_stuff. Extending should always be an
progression in security, i.e. the extending module should require a higher
level of security than the module it extended. -->
<module name="maintain_things" extends="see_stuff">
<!--Additional screens and actions-->
<screen>
Add.vm
</screen>
<screen>
Change.vm
</screen>
<screen>
Delete.vm
</screen>
<action>
Update
</action>
<action>
Delete
</action>
<required-security>
<group name="operator">
<!--Instead of using a broad role we use specific permissions-->
<permission>
Add_things
</permission>
<permission>
Delete_things
</permission>
<permission>
Change_things
</permission>
</group>
</required-security>
</module>
<module name="admin" >
<!--example of how to secure entire directories for ease-of-use and
speed-->
<screen>
admin_screens/*
</screen>
<!-- "The secure_children" attribute specifies whether or not to secure
all the directories below with the same security. Default is false-->
<actions secure_children="true">
admin_actions/*
</actions>
<required-security>
<!--Simple. anybody in the group of admin-->
<group name="admin">
</group>
</required-security>
</module>
</module-security>
Other things:
-If you where to have a screen/action specifically defined within to
seperate modules, the higher security would take precedence over the lower.
- I would extend screen classes to automatically check there own security in
something like a doCheckSecurity(AccesControlList) method. For speed
purposes I would probably have each screen/action cache it's module specific
security in a HashTable or something.
Scott
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 18, 2001 5:41 PM
To: [EMAIL PROTECTED]
Subject: RE: Best way to use groups, roles, permission...
You are right, Scott; in my example I did not deal with 'unsecure'
modules/templates...
probably the best solution is the one illustrated in one of the
Turbine's docs (maybe the Velocity Howto, but I'm not sure...): two
super classes (e.g. WeakScreen, without security controls, and
StrongScreen, with security controls) extended by the modules.
Thus all the modules that don't need a security check extend the
WeakScreen (or WeakAction) and don't belong to any group.
So the log-in procedure is necessary only to gain access to 'group'
modules while the 'no-group' modules are always accessible.
Do you think that this could be a good solution?
And what about modules belonging to more than one group? (e.g. a
BuyBookAction action module that is used by trusted users both in the
SHOP and OFFICE groups)...
Thank you Scott,
Jacopo
> I like everything in Jacopo's post, plus this: the ability to
nominate a
> default user for the site and implement this by extending screens and
> actions. This user's security is used for all transactions until the
user
> manually signs in.
>
> Example:
>
> SCOTT decides to visit the MagicShop to browse it's wonderful and
eclectic
> selection of books. However, he does not have an account nor does he
want
> one at this moment. He just wants to SEARCH and READ as a part of
the SHOP
> group without worrying about signing in. IMOHO, he should be able to
do
> this.
>
> Scott
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 18, 2001 10:43 AM
> To: [EMAIL PROTECTED]
> Subject: Best way to use groups, roles, permission...
>
>
> As I have written in another message posted to this list
(subject: "Security
> framework for modules"), I'm trying to understand which are the best
> practices about the use of Turbine's security stuff.
> In this thread I would like to discuss with you on this issue:
> what is the best way to use Turbine's groups, roles, permissions and
users
> in a complex web application?
>
> This is my humble opinion.
> **************************
> some definitions:
> web application: a (servlet-) context (this is the universe, nothing
exists
> out of here)
> user: someone that can interact with the web application (e.g. jacopo)
> role: a generic (e.g. administrator, guest, operator...) set of
permissions
> permission: a single, generic (e.g. write, read, delete...) or
specific
> (e.g. viewPurchasePrize...) task
> group: a set of logically related modules (actions and screens)
within the
> same web application (universe)
>
> This is the big picture:
> a Turbine user is created for a web application;
> there is only one entry point (a login screen) in the web application;
> the web application is made up of many modules (screens, actions and
so on);
> the web application can be divided in different domains;
> a domain is a Turbine group, and so it is a set of related modules;
> if a user wants to interact with a particular domain, he/she must
have a
> role (or, at least, sufficient permissions) within the domain's group
>
> Example (rather stupid):
> web application: MagicShop, an on-line bookshop
> users: TOM (the application's administrator), JOHN (an employee),
PAUL (a
> customer)
> domains/groups: SHOP (this is where a customer can search and buy
books),
> ADMIN (this is where an administrator can, for example, set the whole
> application default language), OFFICE (this is where the employers
change
> the book list, manage customers' orders and so on...)
> permissions: four generic VIEW, SEARCH, WRITE, DELETE permissions and
a
> specific SEND_A_GIFT one
> roles: GUEST (a generic read-only role made up of VIEW and SEARCH
> permissions) and OPERATOR (a generic read-write role made up of VIEW,
> SEARCH, WRITE and DELETE permissions)
>
> TOM has in group ADMIN the role of OPERATOR and in group OFFICE the
role of
> GUEST (in fact he is also a supervisor for the office tasks)
> JOHN has in group OFFICE the role of OPERATOR
> PAUL has in group SHOP the role of OPERATOR
> TOM has in group OFFICE the special permission SEND_A_GIFT (in fact
he is
> the only one that can send a gift to special customers)
>
> TOM, JOHN, PAUL log in through the same place Login.vm but then they
see
> different index pages...
>
> Ok... let's stop now!!! What do you think of all this stuff? What
about the
> pros and cons of this solution (flexibility, semplicity???).
> I would like to know your ideas...
>
> Thank you in advance,
> Jacopo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
