Perhaps [1] is what you're looking for. XWiki's security mechanism [2] is tightly bound to internally stored rights, and changing its code allows only minor cosmetic alterations to the decision process.
PhenoTips' "authorization" mechanism [3] makes things extremely modular: you're free to implement as many modules you want, and each module is free to decide in whatever way how rights are given. All you have to do is write a component that implements AuthorizationModule [4]. All available modules are active, and they're chained based on their priority [5]. The authorization manager service [6] calls each module in the descending order of their priority, asking them [7] if a specific action is allowed or not. When asked, each module can either allow (return True), deny (return False), or take no decision and defer to the following modules (return null). The two already implemented modules defer to XWiki's classic security module [8], and take a default (configurable) decision to either allow or deny all so far undecided calls [9]. However, if [8] is active in the system, [9] will never actually be reached, but it is still useful if you decide to remove XWiki's rights altogether. The "bridge" [10] registers this modular authorization mechanism with XWiki, so that it is called instead of the current XWiki security mechanism. All you have to do is set [11] as the rights class in xwiki.cfg: xwiki.authentication.rightsclass=org.phenotips.security.authorization.ModularRightServiceImpl Based on this mechanism, we have several modules that deal with specific rights restrictions: [12] allows to lock a document, preventing all edits, even from administrators, until the document is unlocked again. [13] allows assigning documents to "Projects", giving rights to project owners over those documents. [14] allows setting a document owner, who then is given all access on that document. And more optional modules will be added. [1] https://github.com/phenotips/phenotips/tree/master/components/security [2] https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwiki-platform-security [3] https://github.com/phenotips/phenotips/tree/master/components/security/authorization [4] https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java [5] https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java#L48 [6] https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationService.java [7] https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java#L59 [8] https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/internal/XWikiACLAuthorizationModule.java [9] https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/internal/BaseAuthorizationModule.java [10] https://github.com/phenotips/phenotips/tree/master/components/security/bridge [11] https://github.com/phenotips/phenotips/blob/master/components/security/bridge/src/main/java/org/phenotips/security/authorization/ModularRightServiceImpl.java [12] https://github.com/phenotips/phenotips/blob/master/components/record-locking/api/src/main/java/org/phenotips/recordLocking/internal/authorization/LockedAuthorizationModule.java [13] https://github.com/phenotips/phenotips/blob/PT-1987-projects/components/projects/api/src/main/java/org/phenotips/projects/authorization/ProjectAuthorizationModule.java [14] https://github.com/IJessa/phenotips/blob/issue-1023/components/patient-access-rules/api/src/main/java/org/phenotips/data/permissions/internal/OwnerAccessAuthorizationModule.java On 04/12/2016 06:15 AM, Denis Gervalle wrote: > Hi Andrey, > > I would not advice to reimplement the ContextualAuthorizationManager, since > it only provide context to the AuthorizationManager, and there is probably > no need for you to change that part. I would not even advice to reimplement > the AuthorizationManage (since the way it works provide some useful caching > mechanism using the security cache), unless you really want to revamp the > way rights are managed. This could be a lot of work, while there is a lot > of room for customizing rights and the way these are interpreted. > > The AuthorizationSettler, which receive information from the wiki (security > rules) and take the decision is probably the easiest place where you can > change the way decision are taken. Moreover, this one is configurable in > xwiki.properties, see > http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module#HRightsandaccessdecisions > . > > If your need is better solved by injecting custom security rules, you may > also want to override the bridge part. The security module is completely > agnostic to XWiki itself, and the junction is made by the security bridge > module. This where you will found the default SecurityEntryReader. > > When you need to override a component that does not have a dedicated > configuration, during your development or when installed as an extension, > you have to unregister the existing component (to be polite), and register > yours in replacement, see > http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HComponentRegistration > about > component registration. > If you end up packaging the component in a custom war, you may want to use > the priority override solution, as describe in > http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOverrides > > I hope this answer your questions, I encourage you to read the Javadoc of > the security module for explanation about each roles and how they could > influence the whole system, as I said, a lot can be done without having to > rewrite the whole thing, which is a tough task. > Regards, > > > On Tue, Apr 12, 2016 at 10:16 AM, abtv <andreybu...@mail.ru> wrote: > >> When I use XWikiCachingRightService I register it in xwiki.cfg file. Where >> should I register my implementation of ContextualAuthorizationManager >> interface? What is a relation between ContextualAuthorizationManager and >> AuthorizationSettler? >> -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
