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:
+ ++<Users> + <User userId="1" username="jill" password="$PBKDF2WithHmacSHA512,10000,256$61646d696e$cb69962946617da006a2f95776d78b49e5ec7941d2bdb2d25cdb05f957f64344"> + <Firstname>Jill</Firstname> + <Lastname>Someone</Lastname> + <State>ENABLED</State> + <Locale>en_GB</Locale> + <Roles> + <Role>AppUser</Role> + </Roles> + <Properties> + <Property name="realm" value="execution" /> + </Properties> + </User> +</Users> + +<Roles> + <Role name="AppUser"> + <Privilege name="li.strolch.service.api.Service" policy="DefaultPrivilege"> + <AllAllowed>true</AllAllowed> + </Privilege> + <Privilege name="li.strolch.model.query.StrolchQuery" policy="DefaultPrivilege"> + <AllAllowed>true</AllAllowed> + </Privilege> + <Privilege name="li.strolch.search.StrolchSearch" policy="DefaultPrivilege"> + <AllAllowed>true</AllAllowed> + </Privilege> + <Role> +<Roles> ++ +
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:
-
+
PrivilegeContext
→ supplied by privilege and gives access to the +Certificate
, thus identifying the user for which privilege access is to be validated. +
+ IPrivilege
→ Contains the privilege values:AllAllowed
, +Allow
andDeny
+ Restrictable
→ An interface from which the privilege name is retrieved, and the + associated value. The value is an object, and is cast to the relevant input in + the concrete privilege policy. +
+
The following privilege policies are already implemented:
+-
+
+
- DefaultPrivilege → simple policy where the passed
Restrictable
is expected to return a + String value, which is compared with allow and deny values. +
+
+
+ - Internal: RoleAccessPrivilege → policy used for the internal privileges
PrivilegeGetRole
, +PrivilegeAddRole
,PrivilegeModifyRole
orPrivilegeModifyRole
+ - Internal: UserAccessPrivilege → policy used for the internal privileges
PrivilegeGetUser
, +PrivilegeAddUser
,PrivilegeRemoveUser
,PrivilegeModifyUser
, +PrivilegeAddRoleToUser
,PrivilegeRemoveRoleFromUser
,PrivilegeSetUserState
, +PrivilegeSetUserLocale
orPrivilegeSetUserPassword
+ - Internal: UserAccessWithSameOrganisationPrivilege → Same as the
+
UserAccessPrivilege
but expects the authenticated user to have a propertyorganisation
+ and validates that the user being modified is in the same organisation. +
+ - Internal: UsernameFromCertificatePrivilege → This policy expects a
Restrictable
+ to return the certificate of another authenticated user and is used when modifying an + authenticated user, i.e. killing a session, or modifying its current state, e.g. locale + etc. +
+ - Internal: UsernameFromCertificateWithSameOrganisationPrivilege → Same as
UsernameFromCertificatePrivilege
+ but expects the authenticated user to have a propertyorganisation
and + validates that the user being modified is in the same organisation. +
+
Note: As a rule, the sequence is AllAllowed
→ Allow
→
+ Deny
→ default deny