Users & Groups

Access control

• happens on repository level
• users and groups stored in repository
• permissions stored as nodes

Consist of:

• principal - user or a group
• subject - right assigned to a principal
• access control and authorization

Groups

• collections of users and/or other groups (members of a group)
• simplify maintenance process - change made to a group is applied to all members

Actions

• Read
• Modify - modify existing conntent on page and page children, create new paragraphs on page and children. On JCR level allows to modify properties, lock, versioning,
• Create - create new page or child page, if modify is denied then allowing create will not work on nodes under jcr:content cause creating resources under that node is considered as modification (same for delete action)
• Delete - delete existing paragraphs from page and children, delete page or child page
• Read ACL - The user can read the access control list of the page or child pages.
• Edit ACL - The user can modify the access control list of the page or any child pages.
• Replicate - can replicate content to another environment (for example, the Publish environment). The privilege is also applied to any child pages.

Permissions and ACLs

• ACLs - Access Control Lists
• defines who is allowed do perform an action on a resource
• permissions can be granted/denied for a given principal
• Access Control Lists are made up of the individual permissions and are used to determine the order in which these permissions are actually applied. The list is formed according to the hierarchy of the pages under consideration. This list is then scanned bottom-up until the first appropriate permission to apply to a page is found.

Evaluation of a Subject

• process of comparing subject's permissions with those required to access a resource
• a subject is used to combine the access rights for a user principal and groups user belongs to
• list of access rights applicable for a subject is constructed from rights assigned directy to user account and all rights assigned to any of the groups he belongs to - it will consider also groups subject belongs to (transitive groups too)
• user principal always take precedence over group principals (order in access control list and position in node hierarchy does not matter)
• oak looks for the nearest ancestor that is allowing or denying action and goes with that decision

Impersonators

• allows user to work on behalf on another user
• if user B is allowed to impersonate user A then user B can take actions using fill account details of user A (ID, name, access rights)
• it works like user B would log in as user A - all events are registered as user A would do them, no entries in logs that indicates that action was performed via impersonated user
• there is an entry in audit log when impersonation starts and ends

Best practices

• assign permissions to groups not users
• if principal should be able to modify pages it could have only modify right (without delete/create)
• Rather use Allow for specific paths then deny - using deny can cause unexpected rffects if permissions are applied in a different order than expected. If user is member of 2 groups and one is denying and access to a resource that the other group allows to then the allow statement might be ignored. Using deny statement might make it difficult to manage permissions
• Always update the Default Users and Groups immediately after installation to help prevent any security issues.
• pages locked by user A can not be unlocked by user that impersonates him - it can be done by use A or admin only

Documentation

• User Administration and Security