deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marek Posolda <>
Subject Re: [DISCUSS] Security - authorization and permissions
Date Thu, 19 Jul 2012 09:14:40 GMT

some feedback from me on Permission API

1) How about having PermissionMapper as an interface and provide 
implementation DefaultPermissionMapper instead of directly having 
PermissionMapper as a class? I think this will add possibility for 
people to implement custom logic for determine weight of individual 
permissionResolvers and custom logic for determine which resolver has 
bigest vote (priority). For example, someone may want to use 
PermissionResolver, which has biggest priority and his decision always 
wins in comparison to other PermissionResolvers etc.

2) I am seeing class Permission having fields like:

     private Object resource;
     private IdentityType recipient;
     private String permission;

Do we really want to have the field "resource" here? I guess it may be 
better to have two fields like "Class resourceClass" and "String 
resourceId"? I think that this will be also aligned with current 
JPAPermissionStore implementation (I am seeing that 
JPAPermissionStoreConfig.StoreMetadata is using "aclResourceClass" and 

Another option is to use separate class ResourceIdentifier, which will 
encapsulate resourceClass and resourceIdentifier? I think it was 
discussed earlier on this list to have something like this class but I 
am not seeing it in current API. So Permission class could possible have 
fields like this:

     private Class<?> resourceClass;
     private String resourceId;
     private IdentityType recipient;
     private String permission;

or this (in case of ResourceIdentifier will be introduced):

     private ResourceIdentifier resourceId;
     private IdentityType recipient;
     private String permission;


3) On the other hand, on JPAPermissionStore.StoreMetadata there is only 
single field for identify recipient: private Property<String> aclRecipient;

Is this sufficient to identify recipient? It seems to me that no, as 
recipient can be any IdentityType (user, group, role) so if aclRecipient 
represents ID, we also need to add field for aclRecipientType. WDYT?

Can I help with the implementation of API and JPAPermissionStore and 
with the security-console example?


On 07/09/12 02:50, Shane Bryzak wrote:
> Hi all,
> I've put together a list of many of the changes I've made to the 
> security module in relation to authorization, specifically Permissions 
> and Permission Management.  You can find a prototype with these 
> changes in my github repo here:
> The changes are based on the earlier security discussions we had on 
> the mailing list.  I'd like to open a discussion this week, and invite 
> anyone interested to review the overall design before I push this to 
> the master repo.  Development will be ongoing so the code may be in a 
> slight state of flux.  As far as expectations go, I would not expect 
> that we will be pushing polished code into master, however I believe 
> that the prototype has reached a stage where it is complete enough for 
> a review so that we can decide whether to continue development in the 
> master repository.
> Here's a list of the changes:
> 1. Moved Identity and DefaultIdentity classes to root security package 
> as they are cross-cutting and not restricted to just authentication.
> 2. Renamed LoginCredential -> LoginCredentials and 
> DefaultLoginCredential -> DefaultLoginCredentials.  At some point 
> during the discussion there was an arbitrary decision to restrict 
> class names to the singular, without examining the sensibility of such 
> a decision.  This is contrary to the standard set by the JDK, which 
> itself includes a number of "plural" class names. Furthermore, in 
> everyday spoken English it makes far more sense - you'll never hear 
> someone ask "May I see your credential"; it's always the plural, and 
> this also happens to align with the function of the LoginCredentials 
> class - it is intended to hold the user's "credentials".
> 3. To compensate for the removal of the PasswordCredential 
> implementation of the Credential interface,  getPassword() and 
> setPassword() methods have been added to DefaultLoginCredentials to 
> allow setting of a String credential within a JSF page without the 
> requirement of a converter.
> 4. The @Named annotation was added to DefaultIdentity to allow access 
> to this bean from a JSF page.
> 5. A new security-console example has been added which demonstrates 
> the authentication, authorization and Identity Management features of 
> DeltaSpike.
> 6. The class has been removed 
> (replaced with 
> interface).  Similar interfaces have been created for Role, Group and 
> Membership, and basic implementations have been created in the same 
> package.
> 7. Bolek's IDM changes (previously mentioned on the mailing list) have 
> been merged in, including the interfaces mentioned in 5) plus other 
> IDM related interfaces/classes such as IdentityManager.  I did a 
> slight refactor on these to make the identity model interfaces (User, 
> Group, Role, etc) more lightweight and move identity management 
> related operations out of these classes and into IdentityManager.
> 8. Added annotations to security API 
> ( for the 
> configuring of ACL storage entities - these annotations can be used to 
> configure an entity bean for storing ACL permissions.
> 9. Added two authorization-related methods to the Identity interface:
>     hasPermission(Object resource, String operation)
>     hasPermission(Class<?> resourceClass, Serializable identifier, 
> String operation)
> 10. Added a Permission class 
> ( to 
> represent an application permission.
> 11. Added a PermissionManager interface 
> ( for 
> the management of ACL permissions.  This class may be used to query, 
> grant and revoke application permissions.
> 12. Added a PermissionQuery class which is used to set the criteria 
> for a permission search.
> 13. Added the PermissionStore SPI interface.  This interface defines 
> the methods required for managing permissions through a persistent 
> storage facility.
> 14. Added JPAPermissionStore, a PermissionStore implementation that 
> uses JPA for persisting of permissions.  This implementation is still 
> under construction (so some code is missing).  Also added 
> JPAPermissionStoreConfig, which is an extension that scans for ACL 
> stores (annotated with the annotations mentioned in 8.) and builds the 
> configuration metadata.
> 15. Added PersistentPermissionResolver, a PermissionResolver 
> implementation used to perform permission checks (still under 
> construction).
> 16. Added the Property and Property Query API from Solder 
> ( which is currently missing 
> from DeltaSpike Core.  We may consider moving these to core.
> 17. Added selected reflection utils from Solder - these seem to have 
> already been ported to DeltaSpike Core however have been modified (and 
> seem to have some functionality missing now).  An outstanding TODO is 
> to update the security module to use the reflection utils in DS-Core 
> (and update DS-Core if anything is missing) and delete these util 
> classes from the security module.
> The security-console example is still heavily under construction. We 
> can use this example to demonstrate many of the features of the 
> security module and give developers a starting point to learn how they 
> can integrate DeltaSpike's security features into their own 
> applications.  The example is quite ugly right now and needs an 
> extreme makeover, however we can look at this after it's more complete 
> functionality-wise.
> As far as Identity Management related features are concerned, I've 
> purposefully kept that separate except for the minimal overlap in the 
> identity model classes.  Bolek is holding the reigns for IDM and I'm 
> certain we'll be discussing it in more detail on the mailing list 
> shortly.
> Thanks,
> Shane

View raw message