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/ >
