[xwiki-devs] [Discussion] New authorization module. was: Re: [Proposal] Add api to allow scripts choose with the permission of their author.

On Tue, Mar 16, 2010 at 11:08, Caleb James DeLisle &lt;calebdelisle(a)lavabit.com > > Denis Gervalle wrote: >> On Tue, Mar 16, 2010 at 03:46, Caleb James DeLisle < > calebdelisle(a)lavabit.com >>>>> Right now a script which is saved with programming access is allowed to > do >>> things which >>> the viewer (who executes it) is not allowed to do. I would like to > extend >>> this to scripts which do not >>> have programming access. >>> >>> Use case example: >>> A page where the viewer can submit an email address to be put on a > mailing >>> list. The page needs to be able to >>> save the email address to a list but the viewer should not be able to >>> directly edit (or view) the list. >>> >>> I would like to add to xwiki.api.Context: >>> void setScriptUser(String) >>> String getScriptUser() >>> (These names are the best I could think of, suggestions would be great) >>> >>> the input can be either "viewer", "author" or "default" and it stores > this >>> in the XWikiContext >>> If the value is set to author, hasAccessLevel will return an access > check >>> on the author, not the viewer. >>> >>> When includeForm is called, or the include macro is invoked, the only >>> explicit change is that changes made by >>> the called document will be reset when the include ends. >>> If scrips are set to run with author's permissions: >>> If DocumentA includes documentB, documentB executes with documentB's >>> author's permissions. >>> If DocumentA includes _in context_ documentB, documentB executes with >>> documentA's author's permissions. >>> When include of documentB ends, scriptUser is set back to the value > which >>> documentA left it at. >>> >>> I think this will help us achieve the goal of no documents with > programming >>> rights in the XE xar file. >>> >>> WDYT? >>> >>> Caleb >>> >>> _______________________________________________ >>> devs mailing list >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> First of all, I am personally against adding anything to the RightService > in >> its current state. This is already spaghetti code which already lead to > some >> security risks, and trying to improve that partly could be an impossible >> challenge. Moreover, this code is absolutely not optimized, you just have > to >> put it under debug logging to understand what I mean. > +1 I read it and I know exactly what you mean, I *think* a rights check > could be done > in one query. > I have read it as well, and you may find a document I have written in the drafts of XWiki.org about how it is currently working. But anyway, look at the debug logs even after looking the code, you understand that it even worse than you think. Isn't this moving some of the RightService responsibility out of it ? I am already unhappy with how access are checked, since, these check are not only in the right service, but also in many other part of the core, checking special cases, like skin access, inactive user check, etc.... This is not exactly what I am saying, I hate the idea that code became broken when an unpriviledged user have just save its container without being able to change the code itself. This is currently what happen with inclusion, the user may have no right to change the included document, but it break the code by just saving the document that make the inclusion. This is what I means when I say that the privilege of a script should be tightly linked to who has been able to write it. As a helper mechanism, a script may offered the possibility to release its privilege based on the user using it, but it could not raise it, since this could lead to major security issues, and this release should be the choice of the script author. Making PR more fine grained is for me a task for the RightService not the API. Moreover, extending that without thinking about the whole access policy is risky and will create problem for future compatibility. I do not agree. Are you sure that you do not confuse authentication and authorization ?

It is still hard to review the authentication part, and this one needs to be extensible and partly depends on the container. For authentication, I really like the modularity of Acegi Security (aka Spring Security) model (the model, not the implementation as is), which provide a good separation of each roles, allowing easy integration of many way to provide authentications. Authentication should provide a token identifying a user and what are the "global" privileges allowed to this token (group ownership, admin privileges, ???). It should be able to do so for the connected user, and also for a stored token saved with a document (ie the author of a document). It could base its information from many different sources, coming either from the wiki or external to it. It may also provide directory services to the wiki. The authorization part is on the other side and should be independent of the container or any other external stuffs,

and, of course, the way we authenticate users. The communication between the two module should be through some sort of token, that the authentication module ask to the authorization module when needed. Asking could be for the current authenticated user, using an existing persisted token or be built temporarily as a mixed of other tokens for controlling a given script execution. This second part has to be called anytime a privileged operation has to be done on a given object. The caller should normally not tell what he really want to check, but just what operation he want to do on which "object". This is the task of the authorization module to know what to check and this is precisely why I dislike continuing to add some sort of "check this right on this user" anymore.

Well, this is quick and dirty description of what I feel is needed for proper and secure right checking, obviously easier to say than to do. But I feel the work could be started, especially on the authorization part, using some bridging when require. It will be long, but I really think that it is the price to pay for getting something really secure.

Denis