Hi Sergiu, On Tue, Apr 12, 2016 at 3:19 PM, Sergiu Dumitriu <[email protected]> wrote:
> 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. > This is a bit harsh. You seems to have missed an important goal of the rewrite of the right system I did. Available since version 4.x and integrated in XWiki 5.0 and later, our complete rewrite of the security authorization module allows custom definition of new rights, full customization of the authorization decision process, and is almost entirely disconnected from the XWiki platform (the only reason it is not in commons, is just the EntityReference related stuffs). The new module not only provide several entry points for customization, it also provide a very efficient security cache. The new module is articulated around the AuthorizationManager which provide a very generic authorization checking interface, SecurityRules that provide a generic definition of security access rules, and an AuthorizationSettler which is pluggable and responsible for all final decision. Injecting rules into the system could be done by reimplementing a different SecurityEntryReader, but if you want, you may as well benefit of all the infrastructure provide by the wiki while managing rights in a very different manner simply by providing a different authorization settler. 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). > This seems to be about allowing to have several authorization managers. It would be interresting to see why you felt you needed that. It would have been nice to bring the subject on the mailing list before doing it on your side since it seems to be simple enough to be integrated in standard if really needed. > 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 > Hopelessly, this is wrong. This configuration option is deprecated since XWiki 5.x, and should no more be used to hook the XWiki authorization system. Here is the excerpt from the configuration file: #-# (Deprecated) The authorization management class. #-# [Since 5.0M2] The default right service is now org.xwiki.security.authorization.internal.XWikiCachingRightService #-# which is a bridge to the new security authorization component. It provides increased security and performance, but #-# its right policies differ sightly from the old Right Service implementation. In rare situation, you may want to #-# switch back to the old unmaintained implementation by uncommenting the following line. However, only old #-# implementation, still using a bridged RightService will be impacted by this parameter. Customization of the new #-# security authorization component should be done in the new xwiki.properties configuration (security.*). While in XWiki 5.x, most of the xwiki services were still using the old RightService, and so you were capturing more than 90% of the security checks, as more time and version passes, you are capturing less and less of these call, and in a future I do not expect too far, none of them. The new component use for security authorization checks is now the ContextualAuthorizationManager, which is a context based version of the AuthorizationManager, and more and more XWiki components are now targeting those two components directly, fully bypassing the legacy XWikiRightService interface. Therefore, by no means, you can really capture the authorization service using the above configuration change. > > 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. > I do not really see the benefit, since you can achieve the exact same goal with the current rules available in XWiki. > [14] allows setting a document owner, who then is given all access on > that document. > This could be easily implemented using a customization of the CREATOR right. > And more optional modules will be added. > I admit that there are still room for improvement as usual in our new security module, and I would be pleased to receive your contribution. But please, stop saying that our actual implementation could only be used for minor cosmetic alterations of the decision process. Thanks in advance for your understanding, > > [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 <[email protected]> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
