which is added as follows:
<Privilege name="ch.eitchnet.privilege.handler.SystemUserAction"
policy="DefaultPrivilege">
<Allow>ch.eitchnet.privilege.test.model.TestSystemUserAction</Allow>
<Deny>ch.eitchnet.privilege.test.model.TestSystemUserActionDeny</Deny>
</Privilege>
- privilegeConflictResolution is used to configure how conflicts of
privileges on multiple roles are handled.
- Implemented is STRICT where if a privilege with the same name exists
on a role used by the same user occurs, then an exception is thrown.
- Next is MERGE where if a conflict occurs, then the privileges are
merged: allAllowed overrides, allow and deny list are merged
- this solves the situation where a user might be allowed to add a user
with a specific role, but not change a role and other such use cases
Now there are privileges for every use case with two new
PrivilegePolicies:
- RoleAccessPrivilege
- UserAccessPrivilege
both of these policies expect a ch.eitchnet.utils.collections.Tuple as
privilege value. The Tuple is a simple wrapper for two values: first and
second. Each privilege has its own requirement on the actual values
Special privilege actions:
- PrivilegeAction -> privilege vlaue: String
- Persist (required Allow)
- Reload (required Allow)
- GetPolicies (required Allow)
Role specific privileges:
- PrivilegeGetRole -> privilege value: Tuple(null, newRole)
- PrivilegeAddRole -> privilege value: Tuple(null, newRole)
- PrivilegeRemoveRole -> privilege value: Tuple(null, newRole)
- PrivilegeModifyRole -> privilege value: Tuple(oldRole, newRole)
Use specific privileges:
- PrivilegeGetUser -> privilege value: Tuple(null, newUser)
- PrivilegeAddUser -> privilege value: Tuple(null, newUser)
- PrivilegeRemoveUser -> privilege value: Tuple(null, newUser)
- PrivilegeModifyUser -> privilege value: Tuple(oldUser, newUser)
- NOTE: without modifying roles, only fields and properties!
- PrivilegeAddRoleToUser -> privilege value: Tuple(oldUser, roleName)
- PrivilegeRemoveRoleFromUser -> privilege value: Tuple(oldUser,
roleName)
Now the PrivilegeContext object is central and once the user logged in,
this object is bound to a ThreadLocal. From then there is no further
need to interact with the PrivilegeHandler - this allows for
authenticated users to get a remote copy of the PrivilegeContext so that
on a remote client, the user can check for permissions, without having
to do the round trip to the server.
A code review of this change would be good, but preliminary tests show
that it works. A test should now be implemented to check if getting a
remote copy also allows for authorization.
Implementing the runAsSystem() so that special actions can be performed,
where no user is logged in
Refactored the test classes so that model specific classes are in the
model sub package.
Robert von Burg
eitch