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)
The problem was due to a naming problem with the PrivilegeMessages class
and property bundle having the same name and being in the same package.
Moved the properties file now to the resources directory
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.
A number classes had JavaDocs with @see parameters on overriding
methods. This was changed so that they were removed, as they are not
needed.
In some classes the toString() methods were missing, as well as equals()
and hashcode() they were now added
Robert von Burg