Bruno,
We considered roles and found it to be too rigid. We need fine grained
object level rights administrated by the user rather than a fixed
set administrated by the administrator. This flexibility is very
important and hence Roles will be used more a hint/default rather
than the actual control mechanism.
regards,
Dinesh
At Thursday, 6 February 20037, Bruno Wolff III <bruno@wolff.to> wrote:
>On Thu, Feb 06, 2003 at 10:17:15 -0500,
> Dinesh Visweswaraiah <dinesh@trailblazingsolutions.com> wrote:
>> Hi Oliver,
>>
>> Actually the story is a little different. I used Invoice and
Product
>> and Quantity because everybody understands those. Reality is that
>> this is a table that has AuthorizationSetId, UserId and Privileges.
>> Objects in my application have a set of authorizations with specified
>> userid and privileges, specifying who is permitted to do what. The
>> Idea is to identify a AuthorizationSetId so that when the set of
>> UserId and Privileges change, I can reuse a AuthorizationSetId
rather
>> than create a new one. In fact without reuse, there is no point
>> in having a AuthorizationSetId in the first place.
>
>If you are trying to group commonly associated security rights to
simplify
>administration, then the normal way to do this is with roles.
>You have a table relating users and roles and another table relating
>roles and security rights. By joining these two tables you get the
>security rights for an individual user.
>
>---------------------------(end of broadcast)-------------------
--------
>TIP 4: Don't 'kill -9' the postmaster
>
Dinesh
Cell:703-725-4153
Email:dinesh@trailblazingsolutions.com
Web Site:http://www.trailblazingsolutions.com/dinesh
The significant problems we face cannot be solved by the same level
of thinking that created them - Albert Einstein