Gonzalo A. Diethelm wrote:
>>I do prefer Module to Application, as Application
>>doesn't make me think "grouping".
>>
>>In Helm, we have both UserGroup and ProjectGroup entities
>>(ProjectGroups are probably near the equivalent of nested Scarab
>>Modules).
>>
>>Gonzalo, I haven't looked at the code yet, but from your description
>>don't see any interfaces for user or project groups (necessary for
>>finer grained permissioning). Is there any particular reason not to
>>include interfaces for these things (preferably ones which do not have
>>to be used if the user's application does not need'em)?
>>
>
>What I called "Application" is what a Group is today in Turbine 2,
>and I believe it would be akin to your UserGroup. I didn't think
>about adding ProjectGroup because there was no such thing in T2,
>and that was my starting point. What would be the exact semantics
>for ProjectGroup? Where does it fit in:
>
> A Role has Permissions.
> A User has Roles within a UserGroup.
> A Session may o may not have a User.
>
In my application we have been using T2 "groups" as what I think you are
referring to as ProjectGroups, instead of "groups" as methods to
restrict access per application. Under T2 I have deduced that this
kind of scheme was the intent:
Permissions - read, write, delete, update...etc.
Roles - Admin (has read,write,delete, update); User ( read, update) and
so on.
Group - Contact Database, Schedule, WebSite Mangement System.
So T2 was designed so there were roles that people can have under
specific applications or "groups." But, the ProjectGroup-ing arises
when we not only have different applications, but these applications
have different projects underneath them. For example say I have a
Project Managment application with several different projects in it.
Then we have:
Permissions - read, write, delete, update...etc.
Roles - Admin (has read,write,delete, update); User ( read, update) and
so on.
Group (or Application) - Project Management, Contact Database.
ProjectGroup - Marketing Campaign for XXX, TV Ads for ABC Inc.
Then different people can have different permissions in different
projects or no permissions in some projects. This making sense at all?
But the problems don't end here I believe. Because as has been said
many times over there is not a one size fits-all security mechanism...
Not all people are going to have projects, and not all people will want
an application grouping mechanism. Jetspeed is just one counter-example.
So I would just like to put my vote in for a pluggable architecture -
rather a hookable architecture. We could distribute a couple different
security implementations - ClassicTurbine, Portlet Security, Project
Security. All we do is put hooks in the RunData object to the security
system. So then if I'm running the ClassicTurbine SecuritySystem I do
(for lack of a better name I have chose SecuritySystem. Its equivalent
to the ACL Object in T2):
if (data.getSecuritySystem().hasPermission("read", "application"))...do
something
But, If I had my project security system setup I would do:
if (data.getSecuritySystem().hasPermission("read", "application",
"projectid"))...do something
Notice I am not promoting an interface that has a consistent way of
checking for permissions across all implementations. Each API is going
to be different for each system. I think the best way to go about it is
to put hooks in the existing code to reference whatever security system
we want. So while the security system would be "pluggable", you can't
readily replace one with the other unless you change your whole
codebase. This is because there are no defined methods to check for
permissions in the SecuritySystem interface. There is only a way to
retrieve the SecuritySystem object.
I am very willing to help on this project, especially since I have to do
something about it anyways for my application. :)
- Dan Diephouse
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
