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