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 <[email protected]> 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 <
>> [email protected]> 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/
