Hi,
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
"aclIdentifier")
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;
WDYT?
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?
Thanks!
Marek
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:
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)
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
