Mutable Realm

[Dain Sundstrom <da...@iq80.com>]

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

Re: Mutable Realm

[Les Hazlewood <le...@hazlewood.com>]

Sounds great Dain, thanks!

On Fri, Jul 18, 2008 at 1:39 PM, Dain Sundstrom <da...@iq80.com> wrote:

> 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 <da...@iq80.com> 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
>>>>
>>>>
>>
>

Re: Mutable Realm

[Jeremy Haile <jh...@fastmail.fm>]

Yeah - I agree.  I like having a MutableRealm interface that the UI  
knows about so that you could plug-in different realms with the same  
UI.  But probably the REST Service objects should talk directly to the  
MutableRealm, not through the SM.


On Jul 18, 2008, at 3:00 PM, Dain Sundstrom wrote:

> On Jul 18, 2008, at 11:49 AM, Jeremy Haile wrote:
>
>> Dain -
>>
>> I'm really glad to hear that you're working on this.  It would be  
>> really awesome if you were able to open-source the GUI since I'm  
>> sure that's something that would be useful to a lot of people for  
>> getting their projects off the ground faster!
>>
>> My idea would be something along the lines of having a MutableRealm  
>> interface that had things like addRole( Object principal, String  
>> roleName ) removeRole( Object principal, String roleName ).   
>> createUser(....), etc.   The UI that's built would then use the  
>> MutableRealm interface to manage the users, roles, and permissions  
>> within that realm.   For REST support, I'd then think you would  
>> want to have some Service objects that handle processing the REST  
>> request and call the MutableRealm methods as needed.  Is that  
>> similar to the direction you're thinking of going?
>
> Yes. I'm not building the GUI parts, but I will try to get the  
> person doing that on this list.
>
>> Side note: does it make sense to have a MutableRealmSecurityManager  
>> interface that passes through calls to MutableRealms?  Or does it  
>> make more sense that the UI would interact directly with the Realms?
>
> I'm not sure yet.  I'm thinking that methods (addUser, addRole etc)  
> would only apply a single realm, I'm not sure it makes since to  
> expose them at the SM level, but who knows.  After I get some basic  
> MutableRealm implementations, we can experiment with how to expose  
> the details.
>
>> Feel free to bounce ideas or questions off people on this list!
>
> Will do.
>
> -dain
>

Re: Mutable Realm

[Dain Sundstrom <da...@iq80.com>]

On Jul 18, 2008, at 11:49 AM, Jeremy Haile wrote:

> Dain -
>
> I'm really glad to hear that you're working on this.  It would be  
> really awesome if you were able to open-source the GUI since I'm  
> sure that's something that would be useful to a lot of people for  
> getting their projects off the ground faster!
>
> My idea would be something along the lines of having a MutableRealm  
> interface that had things like addRole( Object principal, String  
> roleName ) removeRole( Object principal, String roleName ).   
> createUser(....), etc.   The UI that's built would then use the  
> MutableRealm interface to manage the users, roles, and permissions  
> within that realm.   For REST support, I'd then think you would want  
> to have some Service objects that handle processing the REST request  
> and call the MutableRealm methods as needed.  Is that similar to the  
> direction you're thinking of going?

Yes. I'm not building the GUI parts, but I will try to get the person  
doing that on this list.

> Side note: does it make sense to have a MutableRealmSecurityManager  
> interface that passes through calls to MutableRealms?  Or does it  
> make more sense that the UI would interact directly with the Realms?

I'm not sure yet.  I'm thinking that methods (addUser, addRole etc)  
would only apply a single realm, I'm not sure it makes since to expose  
them at the SM level, but who knows.  After I get some basic  
MutableRealm implementations, we can experiment with how to expose the  
details.

> Feel free to bounce ideas or questions off people on this list!

Will do.

-dain

Re: Mutable Realm

[Jeremy Haile <jh...@fastmail.fm>]

Dain -

I'm really glad to hear that you're working on this.  It would be  
really awesome if you were able to open-source the GUI since I'm sure  
that's something that would be useful to a lot of people for getting  
their projects off the ground faster!

My idea would be something along the lines of having a MutableRealm  
interface that had things like addRole( Object principal, String  
roleName ) removeRole( Object principal, String roleName ).   
createUser(....), etc.   The UI that's built would then use the  
MutableRealm interface to manage the users, roles, and permissions  
within that realm.   For REST support, I'd then think you would want  
to have some Service objects that handle processing the REST request  
and call the MutableRealm methods as needed.  Is that similar to the  
direction you're thinking of going?

Side note: does it make sense to have a MutableRealmSecurityManager  
interface that passes through calls to MutableRealms?  Or does it make  
more sense that the UI would interact directly with the Realms?

Feel free to bounce ideas or questions off people on this list!

Thanks,
Jeremy


On Jul 18, 2008, at 1:39 PM, Dain Sundstrom wrote:

> 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 <da...@iq80.com>  
>>> 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
>>>>
>>
>

Re: Mutable Realm

[Dain Sundstrom <da...@iq80.com>]

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 <da...@iq80.com>  
>> 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
>>>
>

Re: Mutable Realm

[Jeremy Haile <jh...@fastmail.fm>]

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 <da...@iq80.com>  
> 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
>>

Re: Mutable Realm

[Les Hazlewood <le...@hazlewood.com>]

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 <da...@iq80.com> 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
>