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