On Sun, Jul 8, 2012 at 7:50 PM, Shane Bryzak <[email protected]> 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: > > https://github.com/sbryzak/**DeltaSpike/tree/security<https://github.com/sbryzak/DeltaSpike/tree/security> > > 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 org.apache.deltaspike.**security.api.User class has been removed > (replaced with org.apache.deltaspike.**security.api.idm.User 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 (org.apache.deltaspike.** > security.api.permission.**annotations) 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) > IMO there should be a getPermissions(xyz) method that provides a set of permissions for an user. Imagine a UI application that is trying to display resources based on the user's permissions. If there are 100 resources, there will be 100 hasPermission calls. > > 10. Added a Permission class (org.apache.deltaspike.** > security.api.permission.**Permission) to represent an application > permission. > > 11. Added a PermissionManager interface (org.apache.deltaspike.** > security.api.permission.**PermissionManager) 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 > (org.apache.deltaspike.**security.impl.util) 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 >
