Hi Shane,
If I understand correctly this PermissionManager would be used by
PersistentPermissionResolver, which will be the default
PermissionResolver implementation? As it will be good if people have
flexibility to implement their own PermissionResolver and use some
completely different security framework of their own, if they need it.
Some feedback for the PermissionManager itself:
1) I think we should provide also methods for dealing with
ResourceIdentifier case? So we should have also methods like:
List<Permission> listPermissions(ResourceIdentifier resource, String
operation)
List<Permission> listPermissions(ResourceIdentifier resource)
etc.
2) How about cover user identity in the API? For example: I want to know
that user "john" has permission to READ customer "Mary Kelly". With
current API I would need to call: listPermissions(maryKellyCustomer,
"READ") and then iterate through all the Permission objects from result
list and see if they are applicable for John. It does not seem to be
good from usability and performance perspective.
So I guess we need also methods like:
List<Permission> listPermissions(Object resource, Identity String
operation, User user)
When more thinking about it, I think the recipient of the Permission can
be single user or also group? And IMO we should also think about roles
to have things more complicated :)
So you can easily ask PermissionManager for questions like: Has
"MANAGER" of group "PowerUsers" permissions to "READ" customer "Mary
Kelly" ? This may be fine with method like:
List<Permission> listPermissions(Object resource, Identity String
operation, String identityId, String identityType, String roleType);
Maybe instead of using Strings as last 3 arguments, we can encapsulate
all recipient informations into single object.
WDYT?
3) Another potentially missing thing is pagination. I assume that we can
have thousands of users in DB and thousands of resource objects, which
in next turn means that you can have millions of permissions. In large
environments, invoking of PermissionManager.listPermissions(Object
resource, String operation) could return like 10.000 records. So
counting with this case and provide additional methods for pagination
support may be good IMO. Something like:
List<Permission> listPermissions(Object resource, Identity String
operation, int offset, int pageSize);
Thanks,
Marek
On 23.4.2012 11:56, Shane Bryzak wrote:
Following up to the recent outline of object permissions, I'd like to
continue with a description of the permission management API.
At the centre of this API is the PermissionManager bean. This bean
provides all of the operations required to grant, deny and query
object permissions. Here's a description of the methods:
List<Permission> listPermissions(Object resource, String operation)
Returns a List of all the Permissions that have been granted for the
specified resource and operation.
List<Permission> listPermissions(Object resource)
Returns a List of all the Permissions that have been granted for the
specified resource
boolean grantPermission(Permission permission)
Grants the specified permission, returns true if successful.
boolean grantPermissions(List<Permission> permissions)
Grants all the permissions contained in the specified List, returns
true if successful.
boolean revokePermission(Permission permission)
Revokes the specified permission, returns true if successful.
boolean revokePermissions(List<Permission> permissions)
Revokes the specified permissions, returns true if successful.
List<String> listAvailableOperations(Object resource)
Returns a list containing all the known allowed operations for the
specified resource.
Each of these methods in turn will invoke a permission check to ensure
that the current user has permission to invoke that particular
permission management operation.
Behind the scenes, the PermissionManager uses a PermissionStore to do
the actual work. The PermissionStore interface is practically
identical to the PermissionManager interface, in face we can possibly
just have it extend it. DeltaSpike should provide one PermissionStore
implementation out of the box, JpaPermissionStore which allows the
user to store their permissions in a database table. We can use
annotations to configure the entity that is used to store permissions:
@Entity
public class ObjectPermission
{
private Long permissionId;
@PermissionRecipient private String recipient;
@PermissionResourceIdentifier private String resourceId;
@PermissionOperation private String operation;
@PermissionDiscriminator private String discriminator;
}
It should also be possible to use multiple tables to store
permissions. Take for example the use case where a user might wish to
query a table based on assigned permissions:
SELECT
C.*
FROM
CUSTOMER C,
CUSTOMER_PERMISSION CP
WHERE
C.CUSTOMER_ID = CP.CUSTOMER_ID
AND CP.OPERATION CONTAINS '%READ%';
