Jackrabbit Oak – Permission Evaluation with Principal-Based Authorization

Permission Evaluation with Principal-Based Authorization

The examples below describe permission evaluation based on an authorization setup with the following characteristices:

FilterProviderImpl:
    - Path: "/home/users/system/supported"

CompositeAuthorizationConfiguration (CompositionType=AND): 
   
    PrincipalBasedAuthorizationConfiguration
    - FilterProvider: reference to FilterProviderImpl as configured above (default implementation)
    - Enable AggregationFilter: true
    - Ranking: 500
    
    AuthorizationConfigurationImpl
    - Ranking: 100

The following principals will be used in various combinations:

Principals not supported by the configured 'FilterProvider'

- GroupPrincipal:      'testgroup'        
- Principal:           'user'        
- SystemUserPrincipal: 'service-A' with path /home/users/system/45

Principals supporeted by the configured 'FilterProvider'

- SystemUserPrincipal: 'service-B' with path /home/users/system/supported/featureB/11
- SystemUserPrincipal: 'service-C' with path /home/users/system/supported/featureC/C1

The following access control setup has been defined:

grant access using regular path-based ac-management calls 
i.e. 'AccessControlManager.getApplicablePolicies(String)' or 'AccessControlManager.getPolicies(String))'

- 'testgroup': /content [jcr:read, jcr:readAccessControl]
- 'service-A': /content [jcr:versionManagement]
- 'service-B': /content [jcr:read, jcr:modifyProperties]

grant access using principal-based ac-management calls (only possible for supported principals)
i.e. 'JackrabbitAccessControlManager.getApplicablePolicies(Principal)' or 'AccessControlManager.getPolicies(Principal))'

- 'service-B': /content [jcr:read, jcr:nodeTypeManagement]
- 'service-C': /content [jcr:read, jcr:lockManagement]

Example 1: Subject with principals ‘user’, ‘testgroup’

Since neither ‘user’ nor ‘testgroup’ is a system-user-princial supported by principal-based authorization, principal-based permission evaluation is omitted.

Result: the Session is granted jcr:read, jcr:readAccessControl at /content.

Example 2: Subject with principals ‘service-A’, ‘testgroup’

Since neither ‘service-A’ nor ‘testgroup’ is supported by principal-based authorization, principal-based permission evaluation is omitted.

Result: the Session is granted jcr:read, jcr:readAccessControl, jcr:versionManagement at /content.

Example 3: Subject with principals ‘service-B’, ‘testgroup’

Since ‘testgroup’ is not supported by principal-based authorization, principal-based permission evaluation is omitted and only path-based access control setup take effect.

Result: the Session is granted jcr:read,jcr:readAccessControl,jcr:modifyProperties at /content.

Example 4: Subject with principals ‘service-A’, ‘service-B’

Since ‘service-A’ is not supported by principal-based authorization, principal-based permission evaluation is omitted and only path-based access control setup take effect.

Result: the Session is granted jcr:read,jcr:modifyProperties,jcr:versionManagement at /content.

Example 5: Subject with principals ‘service-B’

‘service-B’ is supported by principal-based authorization and no unsupported principal is present in the Subject. Therefore, principal-based permission evaluation takes effect. Since the AggregationFilter is enabled in the configuration describedf above, permission evaluation stops and does not continue evaluating path-based permissions.

Result: the Session is granted jcr:read, jcr:nodeTypeManagement at /content.

NOTE: If AggregationFilter was disabled both permission providers would be used for the evaluation. The result then depends on the CompositionType:

`AggregationFilter`	`CompositionType.AND`	`CompositionType.OR`
enabled	`jcr:read`, `jcr:nodeTypeManagement`	`jcr:read`, `jcr:nodeTypeManagement`
disabled	`jcr:read`	`jcr:read`, `jcr:modifyProperties`, `jcr:nodeTypeManagement`

Example 6: Subject with principals ‘service-C’

‘service-C’ is supported by principal-based authorization and no unsupported principal is present in the Subject. Therefore, principal-based permission evaluation takes effect. Since the AggregationFilter is enabled in the configuration described above, permission evaluation stops and does not continue evaluating path-based permissions.

Result: the Session is granted jcr:read, jcr:lockManagement at /content.

NOTE: If AggregationFilter was disabled both permission providers would be used for the evaluation. The result then depends on the CompositionType:

`AggregationFilter`	`CompositionType.AND`	`CompositionType.OR`
enabled	`jcr:read`, `jcr:lockManagement`	`jcr:read`, `jcr:lockManagement`
disabled	-	`jcr:read`, `jcr:lockManagement`

Example 6: Subject with principals ‘service-B’, ‘service-C’

Both ‘service-B’ and ‘service-C’ are supported by principal-based authorization and no unsupported principal is present in the Subject. Therefore, principal-based permission evaluation takes effect. Since the AggregationFilter is enabled in the configuration described above, permission evaluation stops and does not continue evaluating path-based permissions.

Result: the Session is granted jcr:read, jcr:nodeTypeManagement, jcr:lockManagement at /content.

NOTE: If AggregationFilter was disabled both permission providers would be used for the evaluation. The result then depends on the CompositionType:

`AggregationFilter`	`CompositionType.AND`	`CompositionType.OR`
enabled	`jcr:read`, `jcr:nodeTypeManagement`, `jcr:lockManagement`	`jcr:read`, `jcr:nodeTypeManagement`, `jcr:lockManagement`
disabled	`jcr:read`	`jcr:read`, `jcr:modifyProperties`, `jcr:nodeTypeManagement`, `jcr:lockManagement`