You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2013/10/03 15:44:19 UTC
UserAdmin and GroupAdmin groups in Oak
Hi,
For my Sling tests (SLING-3144) I'm missing these groups, which are
present on the previous Jackrabbit setup but not with my current Oak
0.9 setup.
IIUC it's the UserAccessControlProvider [1] that created those groups
for Jackrabbit, is there an equivalent in Oak?
-Bertrand
[1] http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/user/UserAccessControlProvider.html
Re: UserAdmin and GroupAdmin groups in Oak
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Oct 8, 2013 at 11:43 AM, Angela Schreiber <an...@adobe.com> wrote:
>... as far as i understood the sling team is claiming that sling
> is implemented strictly against the JCR specification and using
> Jackrabbit API is considered evil... with that in mind i am a bit
> surprised to see how much it relies on implementation details.
> but maybe this is a good chance to clean up those parts?...
Yes probably - I'm "just" working on getting the Sling integration
tests to work with oak and stumbled on SLING-3144 but I'm not familiar
with the code that uses that.
IIUC it's just about making it possible for users to create users and
groups - I'll study the code in more detail, and might come back with
a more precise question.
There are also some places where Sling *tests* make too many
assumptions about the backend, I am fixing those as part of the
general SLING-2788 "run Sling on Oak" effort.
-Bertrand
Re: UserAdmin and GroupAdmin groups in Oak
Posted by Angela Schreiber <an...@adobe.com>.
just one additional comment:
the UserAccessControlProvider really only makes sense (if at all)
in the light of a multi-workspace setup where users are stored
in a dedicated separate workspace as we originally had it in CRX 1.x.
the users were in that setup shared between all workspaces.
nowadays i would consider this just legacy.
an somewhat equivalent replacement for that implementation in OAK
should IMO rather store user/group information underneath /jcr:system in
a place that is shared by all workspaces (similar to the version store
or the node type information)... but that's still just an idea and i
have no concrete plans for that (there are also quite some
open questions to solve).
kind regards
angela
On 10/8/13 11:43 AM, "Angela Schreiber" <an...@adobe.com> wrote:
>hi bertrand
>
>the two groups you mention are not built-in authorizables but
>only present with and used by the UserAccessControlProvider.
>currently we have no plans to provide a OAK level equivalent to that
>ac provider implementation but rather wish to take advantage
>of this rewrite to drop it altogether...
>
>however, as with most changes and differences: if we have a
>compelling reason to continue supporting it, we can try to build
>it again... it's rather a matter of priority than ability.
>
>having said that: in the near future we should IMO try to get
>the functionality completed that is actually used in production by us
>and our customers, which IMO should also be the default setup
>in OAK.
>
>as far as i understood the sling team is claiming that sling
>is implemented strictly against the JCR specification and using
>Jackrabbit API is considered evil... with that in mind i am a bit
>surprised to see how much it relies on implementation details.
>but maybe this is a good chance to clean up those parts?
>
>kind regards
>angela
>
>
>On 10/8/13 11:20 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>
>>Hi,
>>
>>Angela wrote:
>>> ..there is no equivalent implementation in Oak and there will be no
>>>equivalent
>>> implementation as long as we don't support multiple workspaces...
>>
>>The SLING-3144 issue is not related to multiple workspaces AFAIK, I'm
>>only missing these additional features provided by [1], as per its
>>javadoc:
>>
>>- members of the 'User administrator' group are allowed to create,
>>modify and remove users,
>>- members of the 'Group administrator' group are allowed to create,
>>modify and remove groups,
>>
>>So let me rephrase my question more precisely: even if the rest of
>>UserAccessControlProvider is not supported by Oak, are there plans to
>>support those out of the box user admin / group admin groups?
>>
>>Otherwise I'll either implement them myself in the part of Sling that
>>needs them, or disable the corresponding Sling functionality when
>>running on Oak.
>>
>>-Bertrand
>>
>>> [1]
>>>http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security
>>>/
>>>user/UserAccessControlProvider.html
>
Re: UserAdmin and GroupAdmin groups in Oak
Posted by Angela Schreiber <an...@adobe.com>.
hi bertrand
the two groups you mention are not built-in authorizables but
only present with and used by the UserAccessControlProvider.
currently we have no plans to provide a OAK level equivalent to that
ac provider implementation but rather wish to take advantage
of this rewrite to drop it altogether...
however, as with most changes and differences: if we have a
compelling reason to continue supporting it, we can try to build
it again... it's rather a matter of priority than ability.
having said that: in the near future we should IMO try to get
the functionality completed that is actually used in production by us
and our customers, which IMO should also be the default setup
in OAK.
as far as i understood the sling team is claiming that sling
is implemented strictly against the JCR specification and using
Jackrabbit API is considered evil... with that in mind i am a bit
surprised to see how much it relies on implementation details.
but maybe this is a good chance to clean up those parts?
kind regards
angela
On 10/8/13 11:20 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>Hi,
>
>Angela wrote:
>> ..there is no equivalent implementation in Oak and there will be no
>>equivalent
>> implementation as long as we don't support multiple workspaces...
>
>The SLING-3144 issue is not related to multiple workspaces AFAIK, I'm
>only missing these additional features provided by [1], as per its
>javadoc:
>
>- members of the 'User administrator' group are allowed to create,
>modify and remove users,
>- members of the 'Group administrator' group are allowed to create,
>modify and remove groups,
>
>So let me rephrase my question more precisely: even if the rest of
>UserAccessControlProvider is not supported by Oak, are there plans to
>support those out of the box user admin / group admin groups?
>
>Otherwise I'll either implement them myself in the part of Sling that
>needs them, or disable the corresponding Sling functionality when
>running on Oak.
>
>-Bertrand
>
>> [1]
>>http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/
>>user/UserAccessControlProvider.html
Re: UserAdmin and GroupAdmin groups in Oak
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
Angela wrote:
> ..there is no equivalent implementation in Oak and there will be no equivalent
> implementation as long as we don't support multiple workspaces...
The SLING-3144 issue is not related to multiple workspaces AFAIK, I'm
only missing these additional features provided by [1], as per its
javadoc:
- members of the 'User administrator' group are allowed to create,
modify and remove users,
- members of the 'Group administrator' group are allowed to create,
modify and remove groups,
So let me rephrase my question more precisely: even if the rest of
UserAccessControlProvider is not supported by Oak, are there plans to
support those out of the box user admin / group admin groups?
Otherwise I'll either implement them myself in the part of Sling that
needs them, or disable the corresponding Sling functionality when
running on Oak.
-Bertrand
> [1] http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/user/UserAccessControlProvider.html
Re: UserAdmin and GroupAdmin groups in Oak
Posted by Angela Schreiber <an...@adobe.com>.
hi bertrand
there is no equivalent implementation in Oak and there will
be no equivalent implementation as long as we don't support
multiple workspaces.
the default security setup in OAK corresponds to one defined
by UserPerWorkspaceSecurityManager in Jackrabbit core which
basically is what we use for our products at Adobe.
kind regards
angela
On 10/3/13 3:44 PM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>Hi,
>
>For my Sling tests (SLING-3144) I'm missing these groups, which are
>present on the previous Jackrabbit setup but not with my current Oak
>0.9 setup.
>
>IIUC it's the UserAccessControlProvider [1] that created those groups
>for Jackrabbit, is there an equivalent in Oak?
>
>-Bertrand
>
>[1]
>http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/u
>ser/UserAccessControlProvider.html