Re: Turbine Security Schema - why use groups

[John McNally <jm...@collab.net>]

I have used them similar to a Project in the past.  But your example of 
Pictures is good.  The idea is that User3 might be the Owner of 
Picture1, but only a Viewer of Picture2 and Picture3.

John McNally


Szűcs Attila wrote:
> Hello !
>
>    I have been using Turbine for almost a year. I was always wondering on how to use correctly the Turbine Security Schema.
>  As you know Turbine provides us User, Role, Permission, Group interfaces to interact with.
> I understand the use of Permission and Role. It's obvious that permissions need to be organized into roles. The need for a User table is also trivial.  But I was thinking on why does the Turbine Security need a fourth abstraction layer, the Group table. I am sure than many of you are familiar with this concept so please correct me if I am wrong.
> On the official Turbine site there is a very brief explanation. I have found an article saying that the Turbine Group was not meant to group users. Instead it is a context that permissions are assigned to. This approach describes the power of groups in reusing permissions saying that a write Permission means something slightly different in a user administrator or a server administrator Group. I haven't had any situation where I could use groups as described above. However, I can imagine a scenario where groups are used to group users around certain objects.
>
> Let's take look at this:
> There is an object let's say a Picture. Each picture instance has an owner (the user who created, or at least uploaded the picture). The owner of the picture may grant different permissions (not the same as Turbine permission) to certain users. These permissions are represented as roles as the following table describes :
> ------------------------------------------------------------
> Turbine_Role             Turbine_Permission
> ------------------------------------------------------------
> Viewer                         View,Comment
> Editor                            View,Comment,Edit
> Owner                          View,Comment,Edit,Delete
> ------------------------------------------------------------
> In this case there may be many users of Picture1 that each have different roles. User2 may have an 'Editor' Role while User1 may has 'Viewer' Role. Given this situation we are forced to group the users around Pictures :
> -------------------------------------------------
>                     User1        User2      User3
> -------------------------------------------------
> Viewer         X
> Editor                                X
> Owner                                                  X
> --------------------------------------------------
> It is possible that later on we will need to group users based on a different criteria so we use a prefix for the Group names : PICTURE_ID where ID is the id of the given picture. Other groups (like articles) will use other prefixes.
>
>
> This is how I understand the use of groups in the security schema.
> If this logic is wrong please correct me and please give an example of how this should be used.
>
> Thanks,
>    Atti
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org