Move governance-services code to amps/ags

2025-07-24 17:32:48 +00:00 · 2021-05-05 19:41:33 +01:00
parent 91b302d756
commit 36ddba20b2
1671 changed files with 0 additions and 0 deletions
--- a/amps/ags/rm-community/documentation/security/extendedPermissionService.md
+++ b/amps/ags/rm-community/documentation/security/extendedPermissionService.md
@@ -0,0 +1,68 @@
+## Alfresco Governance Services' Extended Permission Service
+
+![Completeness Badge](https://img.shields.io/badge/Document_Level-Complete-green.svg?style=flat-square)
+
+![Version Badge](https://img.shields.io/badge/Version-Current-blue.svg?style=flat-square)
+
+### Purpose
+
+When working on the Records Management module, we needed additional functionality around permissions, and therefore 
+introduced the [ExtendedPermissionService](../../rm-community/rm-community-repo/source/java/org/alfresco/repo/security/permissions/impl/ExtendedPermissionServiceImpl.java).
+
+### Overview
+
+The ExtendedPermissionService is wired in, via [Spring config](../../rm-community/rm-community-repo/config/alfresco/module/org_alfresco_module_rm/extended-repository-context.xml), 
+to extend Alfresco's core PermissionService, and adds support for: 
+* the [RMPermissionModel](../../rm-community/rm-community-repo/source/java/org/alfresco/module/org_alfresco_module_rm/capability/RMPermissionModel.java), which defines the available permissions capabilities.
+* the [PermissionProcessorRegistry](../../rm-community/rm-community-repo/source/java/org/alfresco/repo/security/permissions/processor/PermissionProcessorRegistry.java), which introduces pre- and post- processors.
+* other minor method extensions (e.g. to setInheritParentPermissions)
+
+### Permission Processor Registry
+
+This was added in RM 2.4 to support the requirements around the additional security classifications and markings.
+
+The registry is simply two array lists, one for pre-processors and one for post-processors, which are iterated around 
+before / after (respectively) the wrapped call PermissionService.hasPermission
+
+Out of the box, a system with the RM module installed will have the following permissions processors defined:
+
+#### Community:
+
+##### Pre-processors: 
+* None.
+
+##### Post-processors: 
+* [RecordsManagementPermissionPostProcessor](../../rm-community/rm-community-repo/source/java/org/alfresco/module/org_alfresco_module_rm/permission/RecordsManagementPermissionPostProcessor.java)
+  * If the node is an RM node (i.e. it has the [RecordsManagementModel.ASPECT_FILE_PLAN_COMPONENT](../../rm-community/rm-community-repo/source/java/org/alfresco/module/org_alfresco_module_rm/model/RecordsManagementModel.java) marker aspect) and the 
+  core permissions evaluates to DENIED, then this post processor allows read/writes if the appropriate read/file 
+  permissions are present.
+
+#### Enterprise:
+(links only work in clones of Enterprise repos)
+
+##### Pre-processors:
+* [SecurityMarksPermissionPreProcessor](../../rm-enterprise/rm-enterprise-repo/src/main/java/org/alfresco/module/org_alfresco_module_rm/securitymarks/permission/SecurityMarksPermissionPreProcessor.java)
+  * For all content: denies the result if the required security clearance rules (for classification or marks) are not satisfied. (uses 
+[securityClearanceService.isClearedFor](../../rm-enterprise/rm-enterprise-repo/src/main/java/org/alfresco/module/org_alfresco_module_rm/securitymarks/SecurityClearanceServiceImpl.java))
+
+##### Post-processors: 
+* None.
+
+
+### Configuration and Extension points
+
+Additional processors can be defined by extending either [PermissionPreProcessorBaseImpl](../../rm-community/rm-community-repo/source/java/org/alfresco/repo/security/permissions/processor/impl/PermissionPreProcessorBaseImpl.java) 
+or [PermissionPostProcessorBaseImpl](../../rm-community/rm-community-repo/source/java/org/alfresco/repo/security/permissions/processor/impl/PermissionPostProcessorBaseImpl.java) 
+which call the add method on the appropriate list during init.
+
+### Performance Implications
+
+There is certainly a performance overhead when adding additional processing to permission checks. This is most noticeable
+ in the SecurityMarksPermissionPreProcessor where we need to call out to an external service. This has been profiled 
+ heavily and optimised during 2.5 and 2.6 development.
+ 
+ ###TODO:
+ Not yet documented (in related areas of the code) are:
+ * Capabilities (see rm-capabilities-*.xml, declarativeCapability.java and DeclarativeCompositeCapability.java)
+ * RM's permission system has an any allow allows policy unlike alfresco which policy is any deny denies
+ 
--- a/amps/ags/rm-community/documentation/security/rolesAndCapabilities.md
+++ b/amps/ags/rm-community/documentation/security/rolesAndCapabilities.md
@@ -0,0 +1,41 @@
+## Alfresco Governance Services' Roles and Capabilities
+
+![Completeness Badge](https://img.shields.io/badge/Document_Level-InProgress-yellow.svg?style=flat-square)
+
+![Version Badge](https://img.shields.io/badge/Version-Current-blue.svg?style=flat-square)
+
+### Purpose
+
+Roles and capabilities allow the GS system to provide a finer grain security evaluation, determining whether an authority has the capability to perform a perticular action on a node.
+
+### Overview
+
+Roles are defined as a collection of capabilities.  A capability, generally, has a one to one relationship with an action within the system.
+
+Authorities are assigned roles.  If an authority is assigned to a role then it that authority has the capabilities contained within that role, allowing them to perform the related actions.
+
+An authority can be assigned many roles, with the associated capabilities being additive.
+
+Capabilties are evaluated in addition to any ACLs attached to a node, but they are mutally exclusive.  A authority may have the capability, but not the permissions on a node and vice versa.
+
+### Design 
+
+Roles are implementented as groups.  So for every role that is created, there is a corresponding group within the system.
+
+Capabilities are implemented as permissions.  In order add a new capability to the system, the extended RM permission model needs to be extended.
+
+When a capability is added to a role, then the capability group is assigned the capability role on the root file plan node.
+
+In this way the permissions of the systems roles reflect their capabilities on the file plan via the capability permissions assigned.
+
+When an authority is assigned to a role, that authority is added as a member of the corresponding role group.  In this way they inherit the capability permissions on the file plan that relate to that role group.
+
+If a user attempts to perform an action on a records management artifact which has a related capability.  Assuming the user has permission to see the artifact in the first place, then the users capability to perform the action is evaluated.
+
+This is done by firstly determining whether the capability is relevant for this 'kind' of records management artifact.  For example the addHold capability is not relevant for a record category.
+
+Then the capability permission is evaluated by traversing to the file plan node and checking whether the current user has the capabilty permission byt virtue of it's membership of the right role group.
+
+Finally any further conditions attached to the capability are evaluated.
+
+![](../resource/image/CapabilitiesAndRoles.png)