You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2015/08/12 09:47:45 UTC

[jira] [Comment Edited] (OAK-2947) Allow configured system user(s) to impersonate regular users

    [ https://issues.apache.org/jira/browse/OAK-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14693071#comment-14693071 ] 

angela edited comment on OAK-2947 at 8/12/15 7:47 AM:
------------------------------------------------------

whether or not a system user can be created/modified/updated/deleted depends on the permission setup present in the repository. in theory everyone could create one if the permission setup is defined accordingly. there is no hardcoded -only-admins-can-create-system-users... it really a matter of the permissions present.

the problem with your comment is that you are referring to a particular setup as you expect it to be present in one particular application. even for that application it's just a matter of permission setup that may or may not be there at a given point in time.

however, from a oak (and security) point of view we must not implement this feature based on assumptions about a particular setup (that may or may not be present). we need to make sure it's secure out of the box. so, any kind of "but it's expected/assumed to be like that and therefore we can take a shortcut or simply do it this way round because it makes it so easy" is not acceptable.


was (Author: anchela):
whether or not a system user can be created depends on the permission setup present in the repository. in theory everyone could create one if the permission setup is defined accordingly. there is no hardcoded -only-admins-can-create-system-users... it really a matter of the permissions present.

the problem with your comment is that you are referring to a particular setup as you expect it to be present in one particular application. even for that application it's just a matter of permission setup that may or may not be there at a given point in time.

however, from a oak (and security) point of view we must not implement this feature based on assumptions about a particular setup (that may or may not be present). we need to make sure it's secure out of the box. so, any kind of "but it's expected/assumed to be like that and therefore we can take a shortcut or simply do it this way round because it makes it so easy" is not acceptable.

> Allow configured system user(s) to impersonate regular users
> ------------------------------------------------------------
>
>                 Key: OAK-2947
>                 URL: https://issues.apache.org/jira/browse/OAK-2947
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 1.2
>            Reporter: angela
>            Assignee: angela
>         Attachments: OAK-2947.patch
>
>
> Based on some private discussion on how to implement a feature that allows a given subject to continue working on 'his' modifications after changes being persisted, we ([~djaeggi], [~chaotic] and [~anchela]) thought that it would be beneficial to have a configuration option in Oak that allows certain system users to impersonate regular users irrespective on the {{rep:impersonators}} properties present with those users.
> [~fmeschbe] additionally proposed to allow for a configuration that not only states the name(s) of the service users but also limits the sudo-rights to members of a certain group: for example the impersonation ability of a potential system user "impersonate-content-authors" could be limited to impersonate members of the "content-authors" group.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)