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 theCertificate
, 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