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