> Jeff wrote: > > Permissions are pointers to activities in the application. > Roles are collections of permissions. > Users may be assigned one or more roles. Groups may be assigned to one or more roles. A user may belong to one or more groups. Users acquire roles from the groups to which they belong.
A role is a set or permissions. A group is a set of people. I may be asked to give all managers access to post a job. The Manager group is assigned the JobPoster role, which contains the AddJob and EditJob permissions. What if you don't have groups? Well, there are two options. The first is to create a role that acts as a group, a Manager role. Then assign the AddJob and EditJob permissions to that role. In this case, what you're really doing is assigning permissions to groups and not using roles. The second option is to figure out who all the managers are and assign them each to the JobPoster role. But when a new person joins the company, you have to assign him to each of the roles he needs individually, and you don't really have a standardized way of determining what roles he *should* be assigned to. When a new feature is rolled out, and new roles are created, you have to find all the people who should be assigned that role and add them individually. I think groups without roles is a viable solution if the application's permissions are relatively simple. Roles without groups is a big hairy mess, especially if there are a lot of people in the organization. (And there are a number of reasons outside of security to have groups set up anyway.) But if you want a "universal" security model, you need to have both groups and roles. Patrick ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
