I'm definitely thinking of simplified environments. Those with
enterprise security systems aren't going to be using our GUI for
managing their users, but if they are using the simple TextRealm or
JDBCRealm they will.
I understand the desire for the APIs to not assume a specific security
model, but if they are using the simple realm implementations are
already implicitly agreeing to an RBACish (users/roles/permissions)
model. Specificlly, if they are using the TextRealm, they have really
no control over the file format and with JDBC they really only have
control over the mappings. I'm hoping I can create a small interface
that both these reals can implement which has methods like add/remove
user/role/permission and assignUserRole/assignRolePermission. My
overall goal is to be able to easily switch between file and database
permissions without having to change the GUI.
As part of this project we will be building a GUI for this that I'm
fairly confident we could opensource. The UI will be EXTJS+Rest so
I'm not sure everyone will be interest, but it should be a good
starting point.
Anyway, I'm going to start hacking on a MutableRealm and I'll post
more when I get some code working. Even if the code turns out not to
be a generic solution, it should be a good example for others that
need user management features.
-dain
On Jul 18, 2008, at 7:27 AM, Jeremy Haile wrote:
Repost since I accidentally posted to the wrong thread the first time:
I've often thought that a good spinoff project from JSecurity would
be a UI
and infrastructure for managing users, roles, permissions, etc.
I've always
viewed it as something that would be a separate project that depends
on the
JSecurity core. Every project with security has to manage the users
somehow, so why not have an OS project that lets you manage it all
out of
the box?
I'm not sure whether the infrastructure to mutate users, etc.
belongs in
the JSecurity core or in a separate sub-project. If it did, I could
see
something like a MutableRealm interface. But I don't know if we
want to
make those kind of assumptions about the underlying model. I'd be
more
comfortable making those assumptions in a sub-project that was
optional and
was intended to get basic security up and running quickly. (useful for
simple web apps or for the beginning stages of advanced web apps)
Heck, I
wish I had a simple UI for editing roles and permissions for my
application
at work right now!
Ideas?
Jeremy
On Jul 18, 2008, at 9:35 AM, Les Hazlewood wrote:
If we can do it in such a way that it is applicable for any
environment, I'd
love it. Because Realms abstract JSecurity away from the
application's
domain model, it might be tricky to do this in a clean manner.
For example, you could pass in an Account object to the realm to be
created. But that might mean that the application's domain object
would
have to implement our Account interface - not something that is
considered a
best practice (embedding a framework's interfaces in your core domain
model). Realms were created for this purpose - to prevent this tight
coupling.
But, I'm of course open to ideas - maybe what you describe is
perfectly
suitable for simplified environments, maybe where people have text-
based or
file-based realms and don't want to create user/role/permission
objects from
scratch.
In any case, I definitely look forward to it. Could you please
create a
Jira issue at https://issues.apache.org/jira/browse/JSEC and attach
a patch?
Thanks!
Les
On Thu, Jul 17, 2008 at 11:56 PM, Dain Sundstrom <[EMAIL PROTECTED]>
wrote:
We're planning on using JSecurity in some REST applications. Most
of
JSecurity should work for us out-of-the-box with the exception
that we need
our basic realms (text and database) to be mutable at runtime, so
we can
provide simple user management functions for standalone
environments.
I have been looking at the realm implementations and don't think
it will be
difficult to add support for runtime mutability of simple
user->role->permission mappings. Is this something the project
would be
interested in as a contribution?
-dain
