12 Apr
2016
12 Apr
'16
3:19 p.m.
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/xwi…
[3]
https://github.com/phenotips/phenotips/tree/master/components/security/auth…
[4]
https://github.com/phenotips/phenotips/blob/master/components/security/auth…
[5]
https://github.com/phenotips/phenotips/blob/master/components/security/auth…
[6]
https://github.com/phenotips/phenotips/blob/master/components/security/auth…
[7]
https://github.com/phenotips/phenotips/blob/master/components/security/auth…
[8]
https://github.com/phenotips/phenotips/blob/master/components/security/auth…
[9]
https://github.com/phenotips/phenotips/blob/master/components/security/auth…
[10]
https://github.com/phenotips/phenotips/tree/master/components/security/brid…
[11]
https://github.com/phenotips/phenotips/blob/master/components/security/brid…
[12]
https://github.com/phenotips/phenotips/blob/master/components/record-lockin…
[13]
https://github.com/phenotips/phenotips/blob/PT-1987-projects/components/pro…
[14]
https://github.com/IJessa/phenotips/blob/issue-1023/components/patient-acce…
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#HRight…
.
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#HComp…
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#HOver…
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 <andreybutov(a)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/