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.
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
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.
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 '18.104.22.168.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.