You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Shane Bryzak <sb...@redhat.com> on 2012/07/09 02:50:01 UTC
[DISCUSS] Security - authorization and permissions
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
Re: [DISCUSS] Security - authorization and permissions
Posted by Anil Saldhana <an...@gmail.com>.
On Sun, Jul 8, 2012 at 7:50 PM, Shane Bryzak <sb...@redhat.com> 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
>
Re: [DISCUSS] Security - authorization and permissions
Posted by Marek Posolda <mp...@redhat.com>.
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
>
Re: [DISCUSS] Security - authorization and permissions
Posted by Shane Bryzak <sb...@redhat.com>.
I don't see any problem with doing that, we can just make the idm module
a dependency of the core security module and perhaps use shading to
create a jar that contains all the security libs.
On 09/07/12 23:36, Anil Saldhana wrote:
> Was there any thought on the suggestion to split the security module into
> idm and non-idm jars/submodules?
>
> On Mon, Jul 9, 2012 at 2:24 AM, Boleslaw Dawidowicz <
> boleslaw.dawidowicz@gmail.com> wrote:
>
>> On Jul 9, 2012, at 2:50 AM, Shane Bryzak wrote:
>>
>>> 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.
>>
>> I would like to start working this week on providing JPA implementation of
>> IdentityStore. Additionally will try to improve the API design (like Query
>> part) based on recent feedback). Please let me know if you have any
>> comments on this or would like to cooperate
>>
>> Bolek
>>
>>
Re: [DISCUSS] Security - authorization and permissions
Posted by Anil Saldhana <an...@gmail.com>.
Was there any thought on the suggestion to split the security module into
idm and non-idm jars/submodules?
On Mon, Jul 9, 2012 at 2:24 AM, Boleslaw Dawidowicz <
boleslaw.dawidowicz@gmail.com> wrote:
>
> On Jul 9, 2012, at 2:50 AM, Shane Bryzak wrote:
>
> > 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.
>
> I would like to start working this week on providing JPA implementation of
> IdentityStore. Additionally will try to improve the API design (like Query
> part) based on recent feedback). Please let me know if you have any
> comments on this or would like to cooperate
>
> Bolek
>
>
Re: [DISCUSS] Security - authorization and permissions
Posted by Boleslaw Dawidowicz <bo...@gmail.com>.
On Jul 9, 2012, at 2:50 AM, Shane Bryzak wrote:
> 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.
I would like to start working this week on providing JPA implementation of IdentityStore. Additionally will try to improve the API design (like Query part) based on recent feedback). Please let me know if you have any comments on this or would like to cooperate
Bolek