No framework is complete without user management and privilege validation. The basic form would be Users and Roles, and then validating that an authenticated user has a given role. In Strolch we go a step further: A User has roles assigned, and each role has a set of Privileges. The privileges can overlap, a validation is performed to make sure that the one role doesn't deny and another role allows a specific action.

As explained in the Privilege Configuration section, users are defined in the PrivilegeUsers.xml file, and roles are defined in the PrivilegeRoles.xml file.

Let's assume the following user and role definition:

  <User userId="1" username="jill" password="$PBKDF2WithHmacSHA512,10000,256$61646d696e$cb69962946617da006a2f95776d78b49e5ec7941d2bdb2d25cdb05f957f64344">
      <Property name="realm" value="execution" />

  <Role name="AppUser">
    <Privilege name="li.strolch.service.api.Service" policy="DefaultPrivilege">
    <Privilege name="li.strolch.model.query.StrolchQuery" policy="DefaultPrivilege">
    <Privilege name="" policy="DefaultPrivilege">

This configuration contains one user and one role. The user jill has the role AppUser and the role AppUser has three privileges assigned.

Note how the user's password is configured similar to a unix password definition: Using the dollar sign & first the hashing algorithm is configured (algorithm, iterations, key length), then the salt, followed by the password hash.

Note: The password can also still be saved using two separate fields: a salt and password field. This configuration will be immediately changed to the unix form, so won't be described further here.

Further a user always has a firstname and last name. Optionally a locale can be set, otherwise the system locale is used. The user's state must be defined as one of NEW, ENABLED, DISABLED, EXPIRED or SYSTEM. A user can only authenticate/login with the state ENABLED. A user can have any number of properties, which can then be used at runtime. A user can also reference any number of roles, the assigned privilege can overlap, a global configuration mode defines how duplicate privileges are handled.

Roles have a name and any number of Privilege definitions. A Privilege has a name, which in many cases is the name of Java class/interface on which an action is being invoked. The policy value defines which policy to use when evaluating the privilege access. The privilege definition is defined in the PrivilegeConfig.xml and is the name of a class to call for privilege validation.

Further the privilege definitions can have a AllAllowed boolean flag, or any number of Allow or Deny values. How these values are interpreted is defined in the policy implementation. A policy takes three input parameters:

The following privilege policies are already implemented:

Note: As a rule, the sequence is AllAllowedAllowDenydefault deny