demexp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Demexp-dev] Access right management in demexp: possible future evolutio


From: David MENTRE
Subject: [Demexp-dev] Access right management in demexp: possible future evolution. Delegation.
Date: Fri, 26 May 2006 14:09:06 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux)

Hello,

Jéméry and myself had a lengthy discussion last Wednesday on security
topics and more specifically on management of access rights to RPC
methods.

Currently, the right management is rather crude: three roles have been
defined (standard, administrator and classifier) and each role has
hard-coded rights (e.g. add new accounts for administrator role).

It has been requested (on demexp-fr, see Vincent Becker emails) that
demexp allows a more fine grained management of rights, so demexp could
be used in other contexts that the democratic experience project.

Jéremy and myself are currently looking at following scheme:

 - a mutable table that store for each user the set of roles he has;

 - a mutable table that gives for each role the set of rights given.

That way, people could change the set of available roles, with a precise
definition of individual rights for each role. That should fulfill our
users' requirements.

Jérémy will have a look at current demexp code and at a clean definition
of above scheme and we will look at how to implement it.

We have also devised a scheme to implement a central point to check
rights in the code, so that we would have a clean and short code to
audit in order to ensure correctness of right check.


We also discussed a bit on delegation and how it could be
implemented. Jérémy suggested an interesting (and simple!) scheme where
each delegation (e.g. Individual("David") delegates tag "Rennes" to
Delegate("delegate_jeremy")) is implemented as a special vote
Vote_as("delegate_jemery") for user David on *all* questions having the
tag "Rennes" at the time of delegation. This scheme might be a bit
compute intensive but it is simple and it could be possible to design an
efficient implementation. At least a point of view to consider.

Best wishes,
d.
-- 
pub  1024D/A3AD7A2A 2004-10-03 David MENTRE <address@hidden>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A





reply via email to

[Prev in Thread] Current Thread [Next in Thread]