17 Jan
2017
17 Jan
'17
8:14 p.m.
I'd like something more complex, and more flexible at the same time.
Instead of having simple user names, I'd like to see a more powerful
"principal" mechanism in XWiki, with roles and delegates.
A first usecase is separating users and their admin privileges. Instead
of automatically granting admin privileges to users all the time, there
should be a "sudo" equivalent. This gives a bit of safety against
cross-XYZ / XYZ-injection attacks, since normally a user browsing the
wiki wouldn't have admin/scripting/programming privileges, unless
manually entering "admin mode". There wouldn't be an "Admin" user
anymore, just users that can switch to "Administrator" mode, and this
would be recorded as (for example):
delegate::role(user::xwiki:Users.jdoe|role::administrator)
delegate::role(user::xwiki:Users.jdoe|role::developer)
When asking for the current principal, this is what would be returned,
and stored as the author of a document after a change. We still know
that it was "jdoe" performing the changes. Checking for scripting rights
later is done both on the source user (if it's denied) and on the target
role (if it's allowed).
return <is the source denied> ? false : <is the target allowed>
Another usecase would be an admin logging in as another user, to
experience what the user sees without having to ask (or temporarily
change) the user's password. Jira has this feature, and it's very useful
for debugging rights. This can also be recorded as a delegate principal:
delegate::su(user::xwiki:Users.tanderson|user::xwiki:Users.neo)
A third usecase, which doesn't make much sense in the base XWiki, but
which is needed in more complex applications where there's a more
pronounced emphasis on groups, is when a group member acts on behalf of
the group:
delegate::member(user::xwiki:Users.padams|group::xwiki.Groups.Pediatricians)
Here, Patch Adams is acting on behalf of the group of pediatricians when
writing a press release.
Another one: more info about guests. Instead of pretending that there's
only one special "XWikiGuest" user, we can record more information:
role::guest(ip:192.168.0.123|visit:42)
Later, we can see everything this guest did.
That's on the "who am I" end, but this also extends to "who should I
be"
part, i.e. setting rights for special roles.
allow admin for role::administrator
allow scripting for role::developer
deny scripting for group::xwiki:Groups.TheBadGuys
allow delete for role::creator
deny view for role::guest
allow sudo for group::xwiki:Groups.Administrators
deny vote for karma::lt(100)
The last one shows that the types of principals can be customized by new
component implementations, and evaluating if the current principal
matches a target principal can be more complex than what's there now,
"is the same user" or "is member of a group". Also, the rights should
be
extensible, right now adding a new right is not impossible, but not very
easy either.
I've been working on designing and implementing this on and off for the
past year, but there's still a long way to go.
Just some food for thought, -0 for the proposed change.
On 01/17/2017 10:54 AM, Thomas Mortagne wrote:
Hi devs,
I'm thinking since a long time that maybe we should automatically make
superadmin the author of the pages when installing a XAR as long as
the current user (and current author) have programming right (i.e. has
the same rights than superadmin when the extension is installed). I
don't really see anything against it these days and it's easy to do so
why not.
Basically the goal is to reduce the possibility to break extensions
when you play with existing users/groups/rights. Common user case
being to get rid of some old adminsys leaving the company.
WDYT ?
Note: to be complete we could imagine the same kind of thing for admin
user but that require the introduction of a virtual admin right user
like superadmin is a vitual programming right user. But let's not
discuss too many thing at once.
--
Sergiu Dumitriu
http://purl.org/net/sergiu