Oak Documentation

Administrator

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).

Repository#login(new GuestCredentials(), wspName);

Everyone Group

The default user management implementation in Oak contains special handling for the optional group that represents the everyone principal, which is marked by the reserved principal name and by definition has all other principals as members.

This special group always contains all users/groups as member and cannot be edited with user management API. As of OAK this fact is consistently reflected in all group membership related methods. See also Principal Management.

Reading Authorizables

Creating Authorizables

• 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.
• Since version 1.1.0 Oak supports the new API to create dedicated system users JCR-3802.

Searching

XPathQueryBuilder

Oak 1.0 comes with a default XPATH based implementation of the QueryBuilder interface which is passed to the query upon calling UserManager#findAuthorizables(Query).

Group Membership

See section Group Membership for details.

Autosave Behavior

Due to the nature of the UserManager (see above) we decided to drop the auto-save behavior in the default implementation present with OAK. Consequently,

• UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException
• UserManager#isAutoSave() always returns false

See also PARAM_SUPPORT_AUTOSAVE below; while this should not be needed if application code has been written against the Jackrabbit API (and thus testing if auto-save mode is enabled or not) this configuration option can be used as last resort.

XML Import

As of Oak 1.0 user and group nodes can be imported both with Session and Workspace import. Other differences compared to Jackrabbit 2.x:

• Importing an authorizable to another tree than the configured user/group node will only failed upon save (-> see UserValidator during the Root#commit). With Jackrabbit 2.x core it used to fail immediately.
• The BestEffort behavior is now also implemented for the import of impersonators (was missing in Jackrabbit /2.x).

Password Expiry and Force Initial Password Change

Since Oak 1.1.0 the default user management and authentication implementation provides password expiry and initial password change.

By default, these features are disabled. See section Password Expiry and Force Initial Password Change for details.

Password History

Since Oak 1.3.3 the default user management implementation provides password history support. By default, this feature is disabled.

See section Password History for details.

Impersonation

The default implementation of the Impersonation interface comes with the following limitations and features:

• only user principals can be granted impersonation
• every user can impersonate itself
• the admin user always can impersonate all users (and therefore cannot be granted impersonation)
• the Configuration allows to define a list of user or group principals that can impersonate all users (since Oak 1.54.0, see OAK-10173)

Configuration Parameters supported by the default implementation

The following configuration parameters present with the default implementation in Jackrabbit 2.x are no longer supported and will be ignored:

• compatibleJR16
• autoExpandTree
• autoExpandSize
• groupMembershipSplitSize

The optional cacheExpiration configuration option listed above is discussed in detail in section Caching Results of Principal Resolution. It is not related to user management s.str. but affects the implementation specific PrincipalProvider implementation exposed by UserConfiguration.getUserPrincipalProvider.

UserAuthenticationFactory : Authenticating Users

Since Oak 1.1.5 the default user management implementation allows to configure and thus replace the default UserAuthenticationFactory, which links the user management implementation with the authentication (specifically the uid/pw-login) as it exposes the Authentication implementation to be used for verification of the specified credentials according to details provided by a given user management implementation.

@Component()
@Service(UserAuthenticationFactory.class)
public class MyUserAuthenticationFactory implements UserAuthenticationFactory {

    private Set<String> ids = Collections.emptySet();

    public MyUserAuthenticationFactory() {}

    //--------------------------------------< UserAuthenticationFactory >---
    @Override
    Authentication getAuthentication(@Nonnull UserConfiguration configuration, @Nonnull Root root, @Nullable String userId) {
        final boolean canAuthenticate = (userId != null && ids.contains(userId));
        return new Authentication() {
            @Override
            public boolean authenticate(@Nullable Credentials credentials) {
                return canAuthenticate;
            }
        };
    }

    //------------------------------------------------< SCR Integration >---
    @Activate
    private void activate(Map<String, Object> properties) {
         ids = ImmutableSet.copyOf(PropertiesUtil.toStringArray(properties.get("ids"), new String[0]));
    }
}