ComponentIndividual Documentation Coverage
The security service is responsible to check the permission on a
repository. Permission check will be usually forwarded to the
security manager defined on the repository. This may change later.
It holds a permission provider that defines the list of available permission
names and how they are combined into groups of permissions.
It also defines which permissions are high level permissions that are to be
managed through the end user interface and in which order they should be
display in management menus.
It also holds a security policy service that can stack custom policies.
These policies can override default permission checks based on acls set on
the document and/or its parents.
Version: missing
Location: nuxeo-core/nuxeo-core/src/main/resources/OSGI-INF/SecurityService.xml
No requirements
Not required
Extension point to register permission definitions or override
existing permissions.
Example to define a single atomic permissions that are not meant
to be displayed in the rights management screen of folders:
<permission name="Browse" />
<permission name="ReadVersion" />
<permission name="ReadProperties" />
<permission name="ReadChildren" />
<permission name="ReadLifeCycle" />
<permission name="ReviewParticipant" />
Example to define a compound permission that holds many related
atomic permissions into a single high level (role-like)
permission:
<permission name="Read">
<include name="Browse" />
<include name="ReadVersion" />
<include name="ReadProperties" />
<include name="ReadChildren" />
<include name="ReadLifeCycle" />
<include name="ReviewParticipant" />
</permission>
Note that each of the included permissions should have been
previously registered with their on <permission/>
declaration.
It is later possible to override that definition in another
contribution to that extension-point to add a new permission
'CustomPerm' and remove 'ReviewParticipant':
<permission name="CustomPerm" />
<permission name="Read">
<include name="CustomPerm" />
<remove name="ReviewParticipant" />
</permission>
Eventually the permissions declaration also accept 'alias' tags to
handle backward compatibility with deprecated permissions:
<permission name="ReadVersion">
<alias name="Version" />
</permission>
NB: the alias feature is parsed by the extension point but the
underlying SecurityManager implementation does not leverage it
yet.
Extension point to register permission visibility in user
interface or override existing settings.
Example to define the default list of permissions that are
manageable through the UI screens:
<visibility>
<item order="10" show="true">Read</item>
<item order="50" show="true">ReadWrite</item>
<item order="100" show="true">Everything</item>
</visibility>
This list of options items will be displayed if no type specific
settings are registered.
Example to define the default list of permissions that are
specific to the Section document type:
<visibility type="Section">
<item order="10" show="true">Read</item>
<item order="100" show="true">Everything</item>
</visibility>
Note: the 'show' attribute defaults to 'true' and the 'order'
attribute defaults to '0'.
Extension point to register custom security policies or override existing
policies.
Policies are checked in the order they are defined. They can grant or deny
access, in case following policies - as well as the default security check
relying on the acp set on the document - will be ignored. They can also
return an undefined access, in case following policy checks will continue.
Example to define a custom policy :
<policy class="org.nuxeo.ecm.core.security.LockSecurityPolicy" name="lock" order="10" />
The class used has to implement the
org.nuxeo.ecm.core.security.SecurityPolicy interface.
It is later possible to override that definition in another contribution
to that extension-point to disable or override a policy:
<policy enabled="false" name="lock" />
<policy class="org.nuxeo.ecm.core.security.LockSecurityPolicy" name="lock" order="20" />
Last generation: 18:21:25 CEST 11/07/2009