RFE to Permission recipient field

[rdelaplante]

Hi,

I would like RBAC per entity instance. For example, if I were creating a forums application then each forum would have RBAC.  Each Document instance in a document management system could have RBAC.  Each Menu instance could have RBAC.  Each MenuItem instance could have RBAC.

I've looked at other systems that have a similar RBAC mechanism to Seam Security, but with one important difference that makes it possible to do what I want to do. The recipient field of the permission is actually two separate fields.  A recipient type, and a recipient id.  I was thinking of maybe combining type and id to work in Seam Security, for example  Forum-1234, MenuItem-21, but it would be nicer if Seam had built in support for this.

What do you think?  Do you have a better solution in mind?

Thanks,
Ryan

[rdelaplante]

I didn't mean to say recipient field, I meant to say target field.  It would be nice to be able to split it into a target type and target id.

[rdelaplante]

It would also be nice to be able to specify a recipient type so my program knows if it is a role or a user.

It would also be nice if the permission knows if it is an Allow, or Deny permission

[rdelaplante]

BTW the Allow/Deny setting on a permission would be used to override inherited permissions like in OpenCMS.

So for example if I wrote something that let users create directories, subdirectories, and upload files... the user would be able to set permissions on the directories because he created them. The permissions would be implicitly inherited by subdirectories and files, and can be overridden.  I haven't worked out how I would do overrides with Seam Security yet.

[rdelaplante]

Looking deeper at the reference documentation I see that there are @PermissionUser, @PermissionRole, and @PermissionDiscriminator annotations to help determine if a recipient is a user or a role.  Excellent.

For the target field I found IdentifierStrategy, and more specifically section '15.6.10.3.7. EntityIdentifierStrategy'. For a Customer instance with an id value of 1, the value of the identifier would be 'Customer:1'.   @Identifier(name='cust') can be applied to the entity to make it output 'cust:1' instead. Excellent.

Now I feel much better about using Seam Security. I knew you guys were too smart to miss something like this. Now as for permission inheritence, I still don't see how that would work and I need to do some more thinking.