Re: [DISCUSS] DELTASPIKE-79 Authorization API - Permission Management and ACLs

[Marek Posolda]

On 24.4.2012 10:56, Marek Posolda wrote:
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?
Based on your last mail with subject "[DISCUSS] DELTASPIKE-79 
Authorization API - Identity Model" I assume that best case would be to 
cover IdentityType in the API, which will allow possibility to cover 
users/groups/roles. So having method like:

List<Permission> listPermissions(Object resource, Identity String 
operation, IdentityType identityType)




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%';