The typical name for that arrangement is "role based security", and
it's typical counterpart is "permission based security". To align the
terminology, let me restate what you said.
With role based security, your application has a set of defined roles
that users are assigned to. These roles are then checked by the
application against the current user's credentials. Typically roles
might author, editor, administrator. Role based security is simpler
to manage, but less flexible.
With permission based security, your applications has a set of defined
permissions that can be used to build permission groups. Then users
are assigned to permission groups. These permissions are then checked
by the application against the current user's credentials (via the
groups the user is assigned to). Typical permissions might be
view_documents, add_document, edit_document, delete_document,
post_document. Permission based security is more complex to manage
(because you must also manage the groups themselves), but it is more
flexible.
What should be obvious is that if you the developer define the
permission groups in a permission based security system, you've
created a role based system. As such, I'd almost always recommend
going with the permission based system from the outset, and optionally
hiding group creation (providing a set of default groups) so it
behaves exactly like role based security. Then if your user's require
it, you just need to expose the group management to them to give them
all the flexibility.
Regarding implementation, you always have to have something akin to
isUserAuthorized("NAME_OF_SOMETHING"). In your case it's a role name.
In a permission based system it's a permission name. How it's
checked is up to you, but I go with an immutable 'permission' table in
my DB that stores all the permissions the system will check against,
so that I can build groups out of them exactly like I'd build any
other sort of many-to-many relationship in the DB. You do have to be
careful about ensuring the permission that the application checks
against are identical to the ones in the database, but unless your
application is very fluid, that's usually not much of a hassle.
cheers,
barneyb
On 11/11/06, Pete Ruckelshaus <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm building a content management application targeted at
> small-businesses. Currently, I am using group-level security
> (individual users are assigned to groups, groups are granted or
> declined rights at the page level). Unfortunately, this method
> requires that I hard code the groups that are authorized access to the
> page. I'm adding quite a bit of functionality and clients have asked
> for more control over groups (i.e. limiting access to calendar, news,
> content admin, etc.) and would like to move away from hard-coding this
> and moving it into a database.
>
> Has anyone done this, and what approach did you take?
>
> Thanks,
>
> Pete
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting,
up-to-date ColdFusion information by your peers, delivered to your door four
times a year.
http://www.fusionauthority.com/quarterly
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:260043
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
