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/
