[
https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13713475#comment-13713475
]
angela edited comment on OAK-791 at 7/19/13 9:34 AM:
-----------------------------------------------------
1) Characteristics of the Default Implementation
----------------------------------------------------------------------------------------------------------------------------
The default user management implementation present with OAK always stores
user/group information in the workspace associated with the editing Session
(see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant
corresponding to Jackrabbit's default
UserManagerImpl is blocked by missing workspace handling (see OAK-118).
The current user manager has the following characteristics that differ from the
corresponding Jackrabbit implementation:
a) General
- Changes made to the user management API are always transient and require
Session#save() to be persisted.
- In case of a failure Session#refresh is no longer called in order to prevent
reverting other changes unrelated to the user mgt operation. Consequently it's
the responsibility of the API consumer to specifically revert pending or
invalid transient modifications.
- The implementation is no longer built on top of the JCR API but instead
directly acts on Tree and PropertyState defined by the OAK API. This move
allows to make use of the user management API within the OAK layer (aka SPI).
b) User/Group creation
- The rep:password property is no longer defined to be mandatory. Therefore a
new user might be created without specifying a password. Note however, that
User#changePassword does not allow to remove the password property.
- UserManager#createGroup(Principal) will no longer generate a groupID in case
the principal name collides with an existing user or group ID. This has been
considered redundant as the Jackrabbit API in the mean time added
UserManager#createGroup(String groupID).
- Since OAK is designed to scale with flat hierarchies the former configuration
options 'autoExpandTree' and 'autoExpandSize' are no longer supported.
c) Handling of the Authorizable ID
- As of OAK the node type definition of rep:Authorizable defines a new property
rep:authorizableId which is intended to store the ID of a user or group.
- The default implementation comes with a dedicated property index for
rep:authorizableId which asserts the uniqueness of that ID.
- Authorizable#getID returns the string value contained in rep:authorizableID
and for backwards compatibility falls back on the node name in case the ID
property is missing.
- The name of the authorizable node is generated based on a configurable
implementation of the 'AuthorizableNodeName' interface (see configuration
section below). By default it uses the ID as name hint and includes a
conversion to a valid JCR node name.
2) Builtin Users
----------------------------------------------------------------------------------------------------------------------------
The setup of builtin user and group accounts is triggered by the configured
WorkspaceInitializer associated with the user management configuration (see
Configuration section below).
The default user mgt implementation in OAK comes with an initializer that
creates the following builtin user accounts (as in JR2):
a) Administrator user
The admin user is always being created. The ID of this user is retrieved from
the user configuration parameter PARAM_ADMIN_ID, which defaults to "admin".
As of OAK 1.0 however the administrator user might be created without initial
password forcing the application to set the password upon start (see
PARAM_OMIT_ADMIN_PW configuration parameter).
b) Anonymous user
In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional.
Creation will be skipped if the value of the PARAM_ANONYMOUS_ID configuration
parameter is null or empty.
Note, that the anonymous user will always be created without specifying a
password in order to prevent login with SimpleCredentials. The proper way to
obtain a guest session is:
{code}
Repository#login(new GuestCredentials(), wspName);
{code}
was (Author: anchela):
1) Characteristics of the Default Implementation
-------------------------------------------------------------------------
The default user management implementation present with OAK always stores
user/group information in the workspace associated with the editing Session
(see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant
corresponding to Jackrabbit's default
UserManagerImpl is blocked by missing workspace handling (see OAK-118).
The current user manager has the following characteristics that differ from the
corresponding Jackrabbit implementation:
a) General
- Changes made to the user management API are always transient and require
Session#save() to be persisted.
- In case of a failure Session#refresh is no longer called in order to prevent
reverting other changes unrelated to the user mgt operation. Consequently it's
the responsibility of the API consumer to specifically revert pending or
invalid transient modifications.
- The implementation is no longer built on top of the JCR API but instead
directly acts on Tree and PropertyState defined by the OAK API. This move
allows to make use of the user management API within the OAK layer (aka SPI).
b) User/Group creation
- The rep:password property is no longer defined to be mandatory. Therefore a
new user might be created without specifying a password. Note however, that
User#changePassword does not allow to remove the password property.
- UserManager#createGroup(Principal) will no longer generate a groupID in case
the principal name collides with an existing user or group ID. This has been
considered redundant as the Jackrabbit API in the mean time added
UserManager#createGroup(String groupID).
- Since OAK is designed to scale with flat hierarchies the former configuration
options 'autoExpandTree' and 'autoExpandSize' are no longer supported.
c) Handling of the Authorizable ID
- As of OAK the node type definition of rep:Authorizable defines a new property
rep:authorizableId which is intended to store the ID of a user or group.
- The default implementation comes with a dedicated property index for
rep:authorizableId which asserts the uniqueness of that ID.
- Authorizable#getID returns the string value contained in rep:authorizableID
and for backwards compatibility falls back on the node name in case the ID
property is missing.
- The name of the authorizable node is generated based on a configurable
implementation of the 'AuthorizableNodeName' interface (see configuration
section below). By default it uses the ID as name hint and includes a
conversion to a valid JCR node name.
> UserManagement: Document changes wrt Jackrabbit 2
> -------------------------------------------------
>
> Key: OAK-791
> URL: https://issues.apache.org/jira/browse/OAK-791
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: jcr
> Reporter: angela
> Assignee: angela
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
