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 <[email protected]>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 <
> [email protected]> 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 <[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/
>>
>
>
--
Regards,
Heshan Suriyaarachchi
http://heshans.blogspot.com/
