You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Heshan Suriyaarachchi <he...@gmail.com> on 2009/03/17 15:59:49 UTC
UI Management Console for managing Groups, Users, Roles, and
Permissions.
Hi Guys,
I'm planning to take part in Google Summer of Code this year. I
thought of doing a UI Management Console for managing Groups, Users, Roles,
and Permissions for JSecurtiy aka Ki. I need to start on working on a
proposal for GSoC. Therefore I would like to know your feedback on how the
Management Console be implemented and what functionalities should it
support.
--
Regards,
Heshan Suriyaarachchi
http://heshans.blogspot.com/
Re: UI Management Console for managing Groups, Users, Roles, and
Permissions.
Posted by Les Hazlewood <lh...@apache.org>.
Actually, we should link from here:
http://wiki.apache.org/general/SummerOfCode2009
I'm following the instructions on that page on my end. I am not an ASF
Mentor, so I may not be able to do this, but we'll see. Hopefully it will
be ok.
On Wed, Mar 25, 2009 at 10:00 AM, Les Hazlewood <lh...@apache.org>wrote:
> Unless our Apache Mentors think otherwise, I would think the project
> proposal should be in google docs (it is a google proposal, not an Apache
> proposal), but when accepted, all the actual project documentation would go
> in the Apache wiki.
>
> Cheers,
>
> Les
>
>
> On Tue, Mar 24, 2009 at 3:21 PM, Heshan Suriyaarachchi <
> heshan.suri@gmail.com> wrote:
>
>> Hi Les,
>> You can register as a mentor here [1]. When I am creating the
>> proposal, should I do it in a Apache wiki page or in google docs? which
>> method would you prefer?
>>
>> [1] - http://socghop.appspot.com/org/apply_mentor/google/gsoc2009
>>
>>
>> On Tue, Mar 24, 2009 at 12:49 AM, Les Hazlewood <lh...@apache.org>wrote:
>>
>>> Hi Heshan,
>>>
>>> I'd be happy to mentor. Where is the link to register as a mentor?
>>>
>>> Regards,
>>>
>>> Les
>>>
>>>
>>> On Mon, Mar 23, 2009 at 1:10 PM, Heshan Suriyaarachchi <
>>> heshan.suri@gmail.com> wrote:
>>>
>>>> Hey guys,
>>>> Thank you for your feedback. I think that I have enough
>>>> information to start writing a proposal for GSoC. We can refine the ideas as
>>>> we go through with the project. btw I need a mentor for the project as well
>>>> [?]. I hope one of you guys will volunteer to guide me through the
>>>> project.
>>>>
>>>>
>>>> On Fri, Mar 20, 2009 at 7:31 PM, Jeremy Haile <jh...@fastmail.fm>wrote:
>>>>
>>>>> I think before we get too deep in the guts of what things should look
>>>>> like, we should first discuss the goals of the project. I've had many
>>>>> people ask me about this sort of thing - usually they are starting a new
>>>>> project and want to get the security part of their app (data model, data
>>>>> access, UI for managing, etc.) up and running quickly. They don't want to
>>>>> have to think about the data model, building user interfaces for managing
>>>>> it, etc.
>>>>>
>>>>> I think that as the applications grow, the users may then want to
>>>>> extend our data model to add additional fields, etc.
>>>>>
>>>>> The goals I would have for the project would be:
>>>>> 1) Provides a basic data model that can be used out-of-the-box
>>>>> 2) Provides a war that can be quickly and easily configured and
>>>>> deployed to manage security configuration (no coding required!!)
>>>>> 3) Provides data access objects that can be used out of the box, or
>>>>> replaced if desired (at least JPA, maybe LDAP)
>>>>> 4) Allows a user to optionally replace or extend our data model
>>>>> 5) Provide this as an optional extension to JSecurity (a completely
>>>>> separate module) and not something that is added to the core or required in
>>>>> any way
>>>>>
>>>>> Therefore I think it makes sense to:
>>>>> a) Model the data as a set of interfaces that most of the module code
>>>>> would reference
>>>>> b) Provide basic implementations of this data model that are suitable
>>>>> for JPA persistence or LDAP
>>>>> c) Provide a service layer for managing the objects that is independent
>>>>> of our data access strategy. I think this service layer should be totally
>>>>> separate services (managers) from the ones in jsecurity-core.
>>>>> d) Provide DAO interfaces with a couple of implementations - allow the
>>>>> user to substitute in their own DAO if desired
>>>>> e) Provide a web layer that uses the service layer to manage security
>>>>> objects.
>>>>> f) The web interface should be a modern, simple, clean interface that
>>>>> allows creating, editing, deleting users; creating, editing, and deleting
>>>>> roles/permissions; creating, deleting, and assigning users to groups (once
>>>>> jsecurity-core supports the concepts of groups)
>>>>>
>>>>> Jeremy
>>>>>
>>>>>
>>>>> On Mar 19, 2009, at 9:11 AM, Les Hazlewood wrote:
>>>>>
>>>>> Hi Heshan,
>>>>>>
>>>>>> I think this is a great idea, but it will require some decent thought.
>>>>>>
>>>>>> Currently JSecurity's API is essentially read-only. We do this
>>>>>> because the
>>>>>> data model can and does change significantly across projects. So, we
>>>>>> have
>>>>>> things like AuthorizationInfo and AuthenticationInfo interfaces that
>>>>>> end-users can implement and return from their Realm implementations
>>>>>> which
>>>>>> abstracts away their environment from JSecurity.
>>>>>>
>>>>>> If we would be able to write to one or more datasources, we'd also
>>>>>> have to
>>>>>> create an API for the concepts that JSecurity does not currently read
>>>>>> explicilty. I'm thinking of Interfaces like:
>>>>>>
>>>>>> Group
>>>>>> Role
>>>>>>
>>>>>> Maybe we need another Interface like Account to make the associations
>>>>>> between Group and Role (account.getGroups() or account.getRoles()).
>>>>>>
>>>>>> Or maybe there isn't an Account, and we just use Subject for that
>>>>>> (Subject.getGroups(), Subject.getRoles()), etc.
>>>>>>
>>>>>> Role.getPermissions(), Group.getPermissions(),etc. These are all
>>>>>> things
>>>>>> that need to be decided upon. I've done this _many_ times in real
>>>>>> applications, and maybe the modeling I have done can be re-used to a
>>>>>> large
>>>>>> extent. It is very flexible and handles for a large variety of domain
>>>>>> model
>>>>>> permutations - something that would be necessary for supporting many
>>>>>> applications.
>>>>>>
>>>>>> Then, after that is decided, we need to come up with a 'service' API
>>>>>> that
>>>>>> could be called to make the associations. Maybe that service is just
>>>>>> the
>>>>>> existing SecurityManager interface. Things like:
>>>>>>
>>>>>> createRole( Role role );
>>>>>> addRole( PrincipalCollection subjectIdentity, Role role );
>>>>>> deleteRole( Serializable roleId);
>>>>>> addPermission( Serializable roleId, Permission p);
>>>>>>
>>>>>> etc.
>>>>>>
>>>>>> Then we could call this service API to make the changes at runtime.
>>>>>> Then
>>>>>> that service would probably delegate to the internal collection of
>>>>>> Realms to
>>>>>> allow each to respond to the call. The SecurityManager is probably
>>>>>> the best
>>>>>> candidate for this type of service work, as it does the same thing but
>>>>>> for
>>>>>> existing read-only operations.
>>>>>>
>>>>>> The user agent layer should only just call methods on the
>>>>>> SecurityManager
>>>>>> such that any user agent technology could be used (command line, web
>>>>>> console, swing/flex app, etc).
>>>>>>
>>>>>> Anyone else have any thoughts or ideas? Any questions Heshan?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Les
>>>>>>
>>>>>> On Tue, Mar 17, 2009 at 10:59 AM, Heshan Suriyaarachchi <
>>>>>> heshan.suri@gmail.com> wrote:
>>>>>>
>>>>>> Hi Guys,
>>>>>>> I'm planning to take part in Google Summer of Code this
>>>>>>> year. I
>>>>>>> thought of doing a UI Management Console for managing Groups, Users,
>>>>>>> Roles,
>>>>>>> and Permissions for JSecurtiy aka Ki. I need to start on working on
>>>>>>> a
>>>>>>> proposal for GSoC. Therefore I would like to know your feedback on
>>>>>>> how the
>>>>>>> Management Console be implemented and what functionalities should it
>>>>>>> support.
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Heshan Suriyaarachchi
>>>>>>>
>>>>>>> http://heshans.blogspot.com/
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Heshan Suriyaarachchi
>>>>
>>>> http://heshans.blogspot.com/
>>>>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Heshan Suriyaarachchi
>>
>> http://heshans.blogspot.com/
>>
>
>
Re: UI Management Console for managing Groups, Users, Roles, and
Permissions.
Posted by Les Hazlewood <lh...@apache.org>.
Unless our Apache Mentors think otherwise, I would think the project
proposal should be in google docs (it is a google proposal, not an Apache
proposal), but when accepted, all the actual project documentation would go
in the Apache wiki.
Cheers,
Les
On Tue, Mar 24, 2009 at 3:21 PM, Heshan Suriyaarachchi <
heshan.suri@gmail.com> wrote:
> Hi Les,
> You can register as a mentor here [1]. When I am creating the
> proposal, should I do it in a Apache wiki page or in google docs? which
> method would you prefer?
>
> [1] - http://socghop.appspot.com/org/apply_mentor/google/gsoc2009
>
>
> On Tue, Mar 24, 2009 at 12:49 AM, Les Hazlewood <lh...@apache.org>wrote:
>
>> Hi Heshan,
>>
>> I'd be happy to mentor. Where is the link to register as a mentor?
>>
>> Regards,
>>
>> Les
>>
>>
>> On Mon, Mar 23, 2009 at 1:10 PM, Heshan Suriyaarachchi <
>> heshan.suri@gmail.com> wrote:
>>
>>> Hey guys,
>>> Thank you for your feedback. I think that I have enough
>>> information to start writing a proposal for GSoC. We can refine the ideas as
>>> we go through with the project. btw I need a mentor for the project as well
>>> [?]. I hope one of you guys will volunteer to guide me through the
>>> project.
>>>
>>>
>>> On Fri, Mar 20, 2009 at 7:31 PM, Jeremy Haile <jh...@fastmail.fm>wrote:
>>>
>>>> I think before we get too deep in the guts of what things should look
>>>> like, we should first discuss the goals of the project. I've had many
>>>> people ask me about this sort of thing - usually they are starting a new
>>>> project and want to get the security part of their app (data model, data
>>>> access, UI for managing, etc.) up and running quickly. They don't want to
>>>> have to think about the data model, building user interfaces for managing
>>>> it, etc.
>>>>
>>>> I think that as the applications grow, the users may then want to extend
>>>> our data model to add additional fields, etc.
>>>>
>>>> The goals I would have for the project would be:
>>>> 1) Provides a basic data model that can be used out-of-the-box
>>>> 2) Provides a war that can be quickly and easily configured and deployed
>>>> to manage security configuration (no coding required!!)
>>>> 3) Provides data access objects that can be used out of the box, or
>>>> replaced if desired (at least JPA, maybe LDAP)
>>>> 4) Allows a user to optionally replace or extend our data model
>>>> 5) Provide this as an optional extension to JSecurity (a completely
>>>> separate module) and not something that is added to the core or required in
>>>> any way
>>>>
>>>> Therefore I think it makes sense to:
>>>> a) Model the data as a set of interfaces that most of the module code
>>>> would reference
>>>> b) Provide basic implementations of this data model that are suitable
>>>> for JPA persistence or LDAP
>>>> c) Provide a service layer for managing the objects that is independent
>>>> of our data access strategy. I think this service layer should be totally
>>>> separate services (managers) from the ones in jsecurity-core.
>>>> d) Provide DAO interfaces with a couple of implementations - allow the
>>>> user to substitute in their own DAO if desired
>>>> e) Provide a web layer that uses the service layer to manage security
>>>> objects.
>>>> f) The web interface should be a modern, simple, clean interface that
>>>> allows creating, editing, deleting users; creating, editing, and deleting
>>>> roles/permissions; creating, deleting, and assigning users to groups (once
>>>> jsecurity-core supports the concepts of groups)
>>>>
>>>> Jeremy
>>>>
>>>>
>>>> On Mar 19, 2009, at 9:11 AM, Les Hazlewood wrote:
>>>>
>>>> Hi Heshan,
>>>>>
>>>>> I think this is a great idea, but it will require some decent thought.
>>>>>
>>>>> Currently JSecurity's API is essentially read-only. We do this because
>>>>> the
>>>>> data model can and does change significantly across projects. So, we
>>>>> have
>>>>> things like AuthorizationInfo and AuthenticationInfo interfaces that
>>>>> end-users can implement and return from their Realm implementations
>>>>> which
>>>>> abstracts away their environment from JSecurity.
>>>>>
>>>>> If we would be able to write to one or more datasources, we'd also have
>>>>> to
>>>>> create an API for the concepts that JSecurity does not currently read
>>>>> explicilty. I'm thinking of Interfaces like:
>>>>>
>>>>> Group
>>>>> Role
>>>>>
>>>>> Maybe we need another Interface like Account to make the associations
>>>>> between Group and Role (account.getGroups() or account.getRoles()).
>>>>>
>>>>> Or maybe there isn't an Account, and we just use Subject for that
>>>>> (Subject.getGroups(), Subject.getRoles()), etc.
>>>>>
>>>>> Role.getPermissions(), Group.getPermissions(),etc. These are all
>>>>> things
>>>>> that need to be decided upon. I've done this _many_ times in real
>>>>> applications, and maybe the modeling I have done can be re-used to a
>>>>> large
>>>>> extent. It is very flexible and handles for a large variety of domain
>>>>> model
>>>>> permutations - something that would be necessary for supporting many
>>>>> applications.
>>>>>
>>>>> Then, after that is decided, we need to come up with a 'service' API
>>>>> that
>>>>> could be called to make the associations. Maybe that service is just
>>>>> the
>>>>> existing SecurityManager interface. Things like:
>>>>>
>>>>> createRole( Role role );
>>>>> addRole( PrincipalCollection subjectIdentity, Role role );
>>>>> deleteRole( Serializable roleId);
>>>>> addPermission( Serializable roleId, Permission p);
>>>>>
>>>>> etc.
>>>>>
>>>>> Then we could call this service API to make the changes at runtime.
>>>>> Then
>>>>> that service would probably delegate to the internal collection of
>>>>> Realms to
>>>>> allow each to respond to the call. The SecurityManager is probably the
>>>>> best
>>>>> candidate for this type of service work, as it does the same thing but
>>>>> for
>>>>> existing read-only operations.
>>>>>
>>>>> The user agent layer should only just call methods on the
>>>>> SecurityManager
>>>>> such that any user agent technology could be used (command line, web
>>>>> console, swing/flex app, etc).
>>>>>
>>>>> Anyone else have any thoughts or ideas? Any questions Heshan?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Les
>>>>>
>>>>> On Tue, Mar 17, 2009 at 10:59 AM, Heshan Suriyaarachchi <
>>>>> heshan.suri@gmail.com> wrote:
>>>>>
>>>>> Hi Guys,
>>>>>> I'm planning to take part in Google Summer of Code this year.
>>>>>> I
>>>>>> thought of doing a UI Management Console for managing Groups, Users,
>>>>>> Roles,
>>>>>> and Permissions for JSecurtiy aka Ki. I need to start on working on a
>>>>>> proposal for GSoC. Therefore I would like to know your feedback on how
>>>>>> the
>>>>>> Management Console be implemented and what functionalities should it
>>>>>> support.
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Heshan Suriyaarachchi
>>>>>>
>>>>>> http://heshans.blogspot.com/
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Heshan Suriyaarachchi
>>>
>>> http://heshans.blogspot.com/
>>>
>>
>>
>
>
> --
> Regards,
> Heshan Suriyaarachchi
>
> http://heshans.blogspot.com/
>
Re: UI Management Console for managing Groups, Users, Roles, and
Permissions.
Posted by Heshan Suriyaarachchi <he...@gmail.com>.
Hi Les,
You can register as a mentor here [1]. When I am creating the
proposal, should I do it in a Apache wiki page or in google docs? which
method would you prefer?
[1] - http://socghop.appspot.com/org/apply_mentor/google/gsoc2009
On Tue, Mar 24, 2009 at 12:49 AM, Les Hazlewood <lh...@apache.org>wrote:
> Hi Heshan,
>
> I'd be happy to mentor. Where is the link to register as a mentor?
>
> Regards,
>
> Les
>
>
> On Mon, Mar 23, 2009 at 1:10 PM, Heshan Suriyaarachchi <
> heshan.suri@gmail.com> wrote:
>
>> Hey guys,
>> Thank you for your feedback. I think that I have enough
>> information to start writing a proposal for GSoC. We can refine the ideas as
>> we go through with the project. btw I need a mentor for the project as well
>> [?]. I hope one of you guys will volunteer to guide me through the
>> project.
>>
>>
>> On Fri, Mar 20, 2009 at 7:31 PM, Jeremy Haile <jh...@fastmail.fm> wrote:
>>
>>> I think before we get too deep in the guts of what things should look
>>> like, we should first discuss the goals of the project. I've had many
>>> people ask me about this sort of thing - usually they are starting a new
>>> project and want to get the security part of their app (data model, data
>>> access, UI for managing, etc.) up and running quickly. They don't want to
>>> have to think about the data model, building user interfaces for managing
>>> it, etc.
>>>
>>> I think that as the applications grow, the users may then want to extend
>>> our data model to add additional fields, etc.
>>>
>>> The goals I would have for the project would be:
>>> 1) Provides a basic data model that can be used out-of-the-box
>>> 2) Provides a war that can be quickly and easily configured and deployed
>>> to manage security configuration (no coding required!!)
>>> 3) Provides data access objects that can be used out of the box, or
>>> replaced if desired (at least JPA, maybe LDAP)
>>> 4) Allows a user to optionally replace or extend our data model
>>> 5) Provide this as an optional extension to JSecurity (a completely
>>> separate module) and not something that is added to the core or required in
>>> any way
>>>
>>> Therefore I think it makes sense to:
>>> a) Model the data as a set of interfaces that most of the module code
>>> would reference
>>> b) Provide basic implementations of this data model that are suitable for
>>> JPA persistence or LDAP
>>> c) Provide a service layer for managing the objects that is independent
>>> of our data access strategy. I think this service layer should be totally
>>> separate services (managers) from the ones in jsecurity-core.
>>> d) Provide DAO interfaces with a couple of implementations - allow the
>>> user to substitute in their own DAO if desired
>>> e) Provide a web layer that uses the service layer to manage security
>>> objects.
>>> f) The web interface should be a modern, simple, clean interface that
>>> allows creating, editing, deleting users; creating, editing, and deleting
>>> roles/permissions; creating, deleting, and assigning users to groups (once
>>> jsecurity-core supports the concepts of groups)
>>>
>>> Jeremy
>>>
>>>
>>> On Mar 19, 2009, at 9:11 AM, Les Hazlewood wrote:
>>>
>>> Hi Heshan,
>>>>
>>>> I think this is a great idea, but it will require some decent thought.
>>>>
>>>> Currently JSecurity's API is essentially read-only. We do this because
>>>> the
>>>> data model can and does change significantly across projects. So, we
>>>> have
>>>> things like AuthorizationInfo and AuthenticationInfo interfaces that
>>>> end-users can implement and return from their Realm implementations
>>>> which
>>>> abstracts away their environment from JSecurity.
>>>>
>>>> If we would be able to write to one or more datasources, we'd also have
>>>> to
>>>> create an API for the concepts that JSecurity does not currently read
>>>> explicilty. I'm thinking of Interfaces like:
>>>>
>>>> Group
>>>> Role
>>>>
>>>> Maybe we need another Interface like Account to make the associations
>>>> between Group and Role (account.getGroups() or account.getRoles()).
>>>>
>>>> Or maybe there isn't an Account, and we just use Subject for that
>>>> (Subject.getGroups(), Subject.getRoles()), etc.
>>>>
>>>> Role.getPermissions(), Group.getPermissions(),etc. These are all things
>>>> that need to be decided upon. I've done this _many_ times in real
>>>> applications, and maybe the modeling I have done can be re-used to a
>>>> large
>>>> extent. It is very flexible and handles for a large variety of domain
>>>> model
>>>> permutations - something that would be necessary for supporting many
>>>> applications.
>>>>
>>>> Then, after that is decided, we need to come up with a 'service' API
>>>> that
>>>> could be called to make the associations. Maybe that service is just
>>>> the
>>>> existing SecurityManager interface. Things like:
>>>>
>>>> createRole( Role role );
>>>> addRole( PrincipalCollection subjectIdentity, Role role );
>>>> deleteRole( Serializable roleId);
>>>> addPermission( Serializable roleId, Permission p);
>>>>
>>>> etc.
>>>>
>>>> Then we could call this service API to make the changes at runtime.
>>>> Then
>>>> that service would probably delegate to the internal collection of
>>>> Realms to
>>>> allow each to respond to the call. The SecurityManager is probably the
>>>> best
>>>> candidate for this type of service work, as it does the same thing but
>>>> for
>>>> existing read-only operations.
>>>>
>>>> The user agent layer should only just call methods on the
>>>> SecurityManager
>>>> such that any user agent technology could be used (command line, web
>>>> console, swing/flex app, etc).
>>>>
>>>> Anyone else have any thoughts or ideas? Any questions Heshan?
>>>>
>>>> Cheers,
>>>>
>>>> Les
>>>>
>>>> On Tue, Mar 17, 2009 at 10:59 AM, Heshan Suriyaarachchi <
>>>> heshan.suri@gmail.com> wrote:
>>>>
>>>> Hi Guys,
>>>>> I'm planning to take part in Google Summer of Code this year.
>>>>> I
>>>>> thought of doing a UI Management Console for managing Groups, Users,
>>>>> Roles,
>>>>> and Permissions for JSecurtiy aka Ki. I need to start on working on a
>>>>> proposal for GSoC. Therefore I would like to know your feedback on how
>>>>> the
>>>>> Management Console be implemented and what functionalities should it
>>>>> support.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Heshan Suriyaarachchi
>>>>>
>>>>> http://heshans.blogspot.com/
>>>>>
>>>>>
>>>
>>
>>
>> --
>> Regards,
>> Heshan Suriyaarachchi
>>
>> http://heshans.blogspot.com/
>>
>
>
--
Regards,
Heshan Suriyaarachchi
http://heshans.blogspot.com/
Re: UI Management Console for managing Groups, Users, Roles, and
Permissions.
Posted by Les Hazlewood <lh...@apache.org>.
Hi Heshan,
I'd be happy to mentor. Where is the link to register as a mentor?
Regards,
Les
On Mon, Mar 23, 2009 at 1:10 PM, Heshan Suriyaarachchi <
heshan.suri@gmail.com> wrote:
> Hey guys,
> Thank you for your feedback. I think that I have enough
> information to start writing a proposal for GSoC. We can refine the ideas as
> we go through with the project. btw I need a mentor for the project as well
> [?]. I hope one of you guys will volunteer to guide me through the project.
>
>
> On Fri, Mar 20, 2009 at 7:31 PM, Jeremy Haile <jh...@fastmail.fm> wrote:
>
>> I think before we get too deep in the guts of what things should look
>> like, we should first discuss the goals of the project. I've had many
>> people ask me about this sort of thing - usually they are starting a new
>> project and want to get the security part of their app (data model, data
>> access, UI for managing, etc.) up and running quickly. They don't want to
>> have to think about the data model, building user interfaces for managing
>> it, etc.
>>
>> I think that as the applications grow, the users may then want to extend
>> our data model to add additional fields, etc.
>>
>> The goals I would have for the project would be:
>> 1) Provides a basic data model that can be used out-of-the-box
>> 2) Provides a war that can be quickly and easily configured and deployed
>> to manage security configuration (no coding required!!)
>> 3) Provides data access objects that can be used out of the box, or
>> replaced if desired (at least JPA, maybe LDAP)
>> 4) Allows a user to optionally replace or extend our data model
>> 5) Provide this as an optional extension to JSecurity (a completely
>> separate module) and not something that is added to the core or required in
>> any way
>>
>> Therefore I think it makes sense to:
>> a) Model the data as a set of interfaces that most of the module code
>> would reference
>> b) Provide basic implementations of this data model that are suitable for
>> JPA persistence or LDAP
>> c) Provide a service layer for managing the objects that is independent of
>> our data access strategy. I think this service layer should be totally
>> separate services (managers) from the ones in jsecurity-core.
>> d) Provide DAO interfaces with a couple of implementations - allow the
>> user to substitute in their own DAO if desired
>> e) Provide a web layer that uses the service layer to manage security
>> objects.
>> f) The web interface should be a modern, simple, clean interface that
>> allows creating, editing, deleting users; creating, editing, and deleting
>> roles/permissions; creating, deleting, and assigning users to groups (once
>> jsecurity-core supports the concepts of groups)
>>
>> Jeremy
>>
>>
>> On Mar 19, 2009, at 9:11 AM, Les Hazlewood wrote:
>>
>> Hi Heshan,
>>>
>>> I think this is a great idea, but it will require some decent thought.
>>>
>>> Currently JSecurity's API is essentially read-only. We do this because
>>> the
>>> data model can and does change significantly across projects. So, we
>>> have
>>> things like AuthorizationInfo and AuthenticationInfo interfaces that
>>> end-users can implement and return from their Realm implementations which
>>> abstracts away their environment from JSecurity.
>>>
>>> If we would be able to write to one or more datasources, we'd also have
>>> to
>>> create an API for the concepts that JSecurity does not currently read
>>> explicilty. I'm thinking of Interfaces like:
>>>
>>> Group
>>> Role
>>>
>>> Maybe we need another Interface like Account to make the associations
>>> between Group and Role (account.getGroups() or account.getRoles()).
>>>
>>> Or maybe there isn't an Account, and we just use Subject for that
>>> (Subject.getGroups(), Subject.getRoles()), etc.
>>>
>>> Role.getPermissions(), Group.getPermissions(),etc. These are all things
>>> that need to be decided upon. I've done this _many_ times in real
>>> applications, and maybe the modeling I have done can be re-used to a
>>> large
>>> extent. It is very flexible and handles for a large variety of domain
>>> model
>>> permutations - something that would be necessary for supporting many
>>> applications.
>>>
>>> Then, after that is decided, we need to come up with a 'service' API that
>>> could be called to make the associations. Maybe that service is just the
>>> existing SecurityManager interface. Things like:
>>>
>>> createRole( Role role );
>>> addRole( PrincipalCollection subjectIdentity, Role role );
>>> deleteRole( Serializable roleId);
>>> addPermission( Serializable roleId, Permission p);
>>>
>>> etc.
>>>
>>> Then we could call this service API to make the changes at runtime. Then
>>> that service would probably delegate to the internal collection of Realms
>>> to
>>> allow each to respond to the call. The SecurityManager is probably the
>>> best
>>> candidate for this type of service work, as it does the same thing but
>>> for
>>> existing read-only operations.
>>>
>>> The user agent layer should only just call methods on the SecurityManager
>>> such that any user agent technology could be used (command line, web
>>> console, swing/flex app, etc).
>>>
>>> Anyone else have any thoughts or ideas? Any questions Heshan?
>>>
>>> Cheers,
>>>
>>> Les
>>>
>>> On Tue, Mar 17, 2009 at 10:59 AM, Heshan Suriyaarachchi <
>>> heshan.suri@gmail.com> wrote:
>>>
>>> Hi Guys,
>>>> I'm planning to take part in Google Summer of Code this year. I
>>>> thought of doing a UI Management Console for managing Groups, Users,
>>>> Roles,
>>>> and Permissions for JSecurtiy aka Ki. I need to start on working on a
>>>> proposal for GSoC. Therefore I would like to know your feedback on how
>>>> the
>>>> Management Console be implemented and what functionalities should it
>>>> support.
>>>>
>>>> --
>>>> Regards,
>>>> Heshan Suriyaarachchi
>>>>
>>>> http://heshans.blogspot.com/
>>>>
>>>>
>>
>
>
> --
> Regards,
> Heshan Suriyaarachchi
>
> http://heshans.blogspot.com/
>
Re: UI Management Console for managing Groups, Users, Roles, and
Permissions.
Posted by Heshan Suriyaarachchi <he...@gmail.com>.
Hey guys,
Thank you for your feedback. I think that I have enough
information to start writing a proposal for GSoC. We can refine the ideas as
we go through with the project. btw I need a mentor for the project as well
[?]. I hope one of you guys will volunteer to guide me through the project.
On Fri, Mar 20, 2009 at 7:31 PM, Jeremy Haile <jh...@fastmail.fm> wrote:
> I think before we get too deep in the guts of what things should look like,
> we should first discuss the goals of the project. I've had many people ask
> me about this sort of thing - usually they are starting a new project and
> want to get the security part of their app (data model, data access, UI for
> managing, etc.) up and running quickly. They don't want to have to think
> about the data model, building user interfaces for managing it, etc.
>
> I think that as the applications grow, the users may then want to extend
> our data model to add additional fields, etc.
>
> The goals I would have for the project would be:
> 1) Provides a basic data model that can be used out-of-the-box
> 2) Provides a war that can be quickly and easily configured and deployed to
> manage security configuration (no coding required!!)
> 3) Provides data access objects that can be used out of the box, or
> replaced if desired (at least JPA, maybe LDAP)
> 4) Allows a user to optionally replace or extend our data model
> 5) Provide this as an optional extension to JSecurity (a completely
> separate module) and not something that is added to the core or required in
> any way
>
> Therefore I think it makes sense to:
> a) Model the data as a set of interfaces that most of the module code would
> reference
> b) Provide basic implementations of this data model that are suitable for
> JPA persistence or LDAP
> c) Provide a service layer for managing the objects that is independent of
> our data access strategy. I think this service layer should be totally
> separate services (managers) from the ones in jsecurity-core.
> d) Provide DAO interfaces with a couple of implementations - allow the user
> to substitute in their own DAO if desired
> e) Provide a web layer that uses the service layer to manage security
> objects.
> f) The web interface should be a modern, simple, clean interface that
> allows creating, editing, deleting users; creating, editing, and deleting
> roles/permissions; creating, deleting, and assigning users to groups (once
> jsecurity-core supports the concepts of groups)
>
> Jeremy
>
>
> On Mar 19, 2009, at 9:11 AM, Les Hazlewood wrote:
>
> Hi Heshan,
>>
>> I think this is a great idea, but it will require some decent thought.
>>
>> Currently JSecurity's API is essentially read-only. We do this because
>> the
>> data model can and does change significantly across projects. So, we have
>> things like AuthorizationInfo and AuthenticationInfo interfaces that
>> end-users can implement and return from their Realm implementations which
>> abstracts away their environment from JSecurity.
>>
>> If we would be able to write to one or more datasources, we'd also have to
>> create an API for the concepts that JSecurity does not currently read
>> explicilty. I'm thinking of Interfaces like:
>>
>> Group
>> Role
>>
>> Maybe we need another Interface like Account to make the associations
>> between Group and Role (account.getGroups() or account.getRoles()).
>>
>> Or maybe there isn't an Account, and we just use Subject for that
>> (Subject.getGroups(), Subject.getRoles()), etc.
>>
>> Role.getPermissions(), Group.getPermissions(),etc. These are all things
>> that need to be decided upon. I've done this _many_ times in real
>> applications, and maybe the modeling I have done can be re-used to a large
>> extent. It is very flexible and handles for a large variety of domain
>> model
>> permutations - something that would be necessary for supporting many
>> applications.
>>
>> Then, after that is decided, we need to come up with a 'service' API that
>> could be called to make the associations. Maybe that service is just the
>> existing SecurityManager interface. Things like:
>>
>> createRole( Role role );
>> addRole( PrincipalCollection subjectIdentity, Role role );
>> deleteRole( Serializable roleId);
>> addPermission( Serializable roleId, Permission p);
>>
>> etc.
>>
>> Then we could call this service API to make the changes at runtime. Then
>> that service would probably delegate to the internal collection of Realms
>> to
>> allow each to respond to the call. The SecurityManager is probably the
>> best
>> candidate for this type of service work, as it does the same thing but for
>> existing read-only operations.
>>
>> The user agent layer should only just call methods on the SecurityManager
>> such that any user agent technology could be used (command line, web
>> console, swing/flex app, etc).
>>
>> Anyone else have any thoughts or ideas? Any questions Heshan?
>>
>> Cheers,
>>
>> Les
>>
>> On Tue, Mar 17, 2009 at 10:59 AM, Heshan Suriyaarachchi <
>> heshan.suri@gmail.com> wrote:
>>
>> Hi Guys,
>>> I'm planning to take part in Google Summer of Code this year. I
>>> thought of doing a UI Management Console for managing Groups, Users,
>>> Roles,
>>> and Permissions for JSecurtiy aka Ki. I need to start on working on a
>>> proposal for GSoC. Therefore I would like to know your feedback on how
>>> the
>>> Management Console be implemented and what functionalities should it
>>> support.
>>>
>>> --
>>> Regards,
>>> Heshan Suriyaarachchi
>>>
>>> http://heshans.blogspot.com/
>>>
>>>
>
--
Regards,
Heshan Suriyaarachchi
http://heshans.blogspot.com/
Re: UI Management Console for managing Groups, Users, Roles, and Permissions.
Posted by Jeremy Haile <jh...@fastmail.fm>.
I think before we get too deep in the guts of what things should look
like, we should first discuss the goals of the project. I've had many
people ask me about this sort of thing - usually they are starting a
new project and want to get the security part of their app (data
model, data access, UI for managing, etc.) up and running quickly.
They don't want to have to think about the data model, building user
interfaces for managing it, etc.
I think that as the applications grow, the users may then want to
extend our data model to add additional fields, etc.
The goals I would have for the project would be:
1) Provides a basic data model that can be used out-of-the-box
2) Provides a war that can be quickly and easily configured and
deployed to manage security configuration (no coding required!!)
3) Provides data access objects that can be used out of the box, or
replaced if desired (at least JPA, maybe LDAP)
4) Allows a user to optionally replace or extend our data model
5) Provide this as an optional extension to JSecurity (a completely
separate module) and not something that is added to the core or
required in any way
Therefore I think it makes sense to:
a) Model the data as a set of interfaces that most of the module code
would reference
b) Provide basic implementations of this data model that are suitable
for JPA persistence or LDAP
c) Provide a service layer for managing the objects that is
independent of our data access strategy. I think this service layer
should be totally separate services (managers) from the ones in
jsecurity-core.
d) Provide DAO interfaces with a couple of implementations - allow the
user to substitute in their own DAO if desired
e) Provide a web layer that uses the service layer to manage security
objects.
f) The web interface should be a modern, simple, clean interface that
allows creating, editing, deleting users; creating, editing, and
deleting roles/permissions; creating, deleting, and assigning users to
groups (once jsecurity-core supports the concepts of groups)
Jeremy
On Mar 19, 2009, at 9:11 AM, Les Hazlewood wrote:
> Hi Heshan,
>
> I think this is a great idea, but it will require some decent thought.
>
> Currently JSecurity's API is essentially read-only. We do this
> because the
> data model can and does change significantly across projects. So,
> we have
> things like AuthorizationInfo and AuthenticationInfo interfaces that
> end-users can implement and return from their Realm implementations
> which
> abstracts away their environment from JSecurity.
>
> If we would be able to write to one or more datasources, we'd also
> have to
> create an API for the concepts that JSecurity does not currently read
> explicilty. I'm thinking of Interfaces like:
>
> Group
> Role
>
> Maybe we need another Interface like Account to make the associations
> between Group and Role (account.getGroups() or account.getRoles()).
>
> Or maybe there isn't an Account, and we just use Subject for that
> (Subject.getGroups(), Subject.getRoles()), etc.
>
> Role.getPermissions(), Group.getPermissions(),etc. These are all
> things
> that need to be decided upon. I've done this _many_ times in real
> applications, and maybe the modeling I have done can be re-used to a
> large
> extent. It is very flexible and handles for a large variety of
> domain model
> permutations - something that would be necessary for supporting many
> applications.
>
> Then, after that is decided, we need to come up with a 'service' API
> that
> could be called to make the associations. Maybe that service is
> just the
> existing SecurityManager interface. Things like:
>
> createRole( Role role );
> addRole( PrincipalCollection subjectIdentity, Role role );
> deleteRole( Serializable roleId);
> addPermission( Serializable roleId, Permission p);
>
> etc.
>
> Then we could call this service API to make the changes at runtime.
> Then
> that service would probably delegate to the internal collection of
> Realms to
> allow each to respond to the call. The SecurityManager is probably
> the best
> candidate for this type of service work, as it does the same thing
> but for
> existing read-only operations.
>
> The user agent layer should only just call methods on the
> SecurityManager
> such that any user agent technology could be used (command line, web
> console, swing/flex app, etc).
>
> Anyone else have any thoughts or ideas? Any questions Heshan?
>
> Cheers,
>
> Les
>
> On Tue, Mar 17, 2009 at 10:59 AM, Heshan Suriyaarachchi <
> heshan.suri@gmail.com> wrote:
>
>> Hi Guys,
>> I'm planning to take part in Google Summer of Code this
>> year. I
>> thought of doing a UI Management Console for managing Groups,
>> Users, Roles,
>> and Permissions for JSecurtiy aka Ki. I need to start on working
>> on a
>> proposal for GSoC. Therefore I would like to know your feedback on
>> how the
>> Management Console be implemented and what functionalities should it
>> support.
>>
>> --
>> Regards,
>> Heshan Suriyaarachchi
>>
>> http://heshans.blogspot.com/
>>
Re: UI Management Console for managing Groups, Users, Roles, and
Permissions.
Posted by Les Hazlewood <lh...@apache.org>.
Hi Heshan,
I think this is a great idea, but it will require some decent thought.
Currently JSecurity's API is essentially read-only. We do this because the
data model can and does change significantly across projects. So, we have
things like AuthorizationInfo and AuthenticationInfo interfaces that
end-users can implement and return from their Realm implementations which
abstracts away their environment from JSecurity.
If we would be able to write to one or more datasources, we'd also have to
create an API for the concepts that JSecurity does not currently read
explicilty. I'm thinking of Interfaces like:
Group
Role
Maybe we need another Interface like Account to make the associations
between Group and Role (account.getGroups() or account.getRoles()).
Or maybe there isn't an Account, and we just use Subject for that
(Subject.getGroups(), Subject.getRoles()), etc.
Role.getPermissions(), Group.getPermissions(),etc. These are all things
that need to be decided upon. I've done this _many_ times in real
applications, and maybe the modeling I have done can be re-used to a large
extent. It is very flexible and handles for a large variety of domain model
permutations - something that would be necessary for supporting many
applications.
Then, after that is decided, we need to come up with a 'service' API that
could be called to make the associations. Maybe that service is just the
existing SecurityManager interface. Things like:
createRole( Role role );
addRole( PrincipalCollection subjectIdentity, Role role );
deleteRole( Serializable roleId);
addPermission( Serializable roleId, Permission p);
etc.
Then we could call this service API to make the changes at runtime. Then
that service would probably delegate to the internal collection of Realms to
allow each to respond to the call. The SecurityManager is probably the best
candidate for this type of service work, as it does the same thing but for
existing read-only operations.
The user agent layer should only just call methods on the SecurityManager
such that any user agent technology could be used (command line, web
console, swing/flex app, etc).
Anyone else have any thoughts or ideas? Any questions Heshan?
Cheers,
Les
On Tue, Mar 17, 2009 at 10:59 AM, Heshan Suriyaarachchi <
heshan.suri@gmail.com> wrote:
> Hi Guys,
> I'm planning to take part in Google Summer of Code this year. I
> thought of doing a UI Management Console for managing Groups, Users, Roles,
> and Permissions for JSecurtiy aka Ki. I need to start on working on a
> proposal for GSoC. Therefore I would like to know your feedback on how the
> Management Console be implemented and what functionalities should it
> support.
>
> --
> Regards,
> Heshan Suriyaarachchi
>
> http://heshans.blogspot.com/
>