You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by "Gonzalo A. Diethelm" <go...@aditiva.com> on 2002/01/05 21:35:16 UTC
Proposal for a new security model
I have been thinking a little more about Turbine's current security
service and the model behind it. I believe things could be simplified
by refactoring things into the following ideas:
* Very shallow interfaces for User, Permission, Role, Application and
Session. These only hold a unique key for each object and have
methods to query and set their relationships; for instance, Role
would have getPermissionSet, hasPermission, addPermission,
removePermission, etc. And maybe some administrative methods for
each, such as rename, delete, etc. Of course, User would have
validatePassword and changePassword, and would hold a Session.
* A straightforward implementation for each of these interfaces within
Fulcrum: FulcrumUser, FulcrumPermission, etc.
* ALL USES of the security objects in Fulcrum and Turbine must be
through the security interfaces! If we find that there are
additional fields required to keep Turbine's current functionality
(I believe last_access could be one of these), we could discuss
adding those to the basic interfaces.
(Notice that up to this point there is no information on how these
objects are loaded, saved, etc.).
* Interfaces for mapper objects that take care of loading, saving,
etc. the basic security objects from whatever backend. For example,
UserMapper would have load, save, rename, delete, etc. This opens
up the possibilities to map the security objects to whatever backend
the programmer wants to use.
* A straightforward implementation for each mapper within Fulcrum.
This implementation could just read the data from an XML file and
forbid any modification of the data; this way, Fulcrum would not
require a DB for its basic configuration.
* A good set of configuration entries in TR.props, so that the
programmer can choose what classes to use for each of the security
objects and each of the mapper objects.
* Turbine 3 could include objects such as ClassicUser, etc. that
extend FulcrumUser, etc. and add all the other data fields that are
there today (email, etc.). This could or could not be the default
security implementation within Turbine; that's not for me to
decide, although I do believe it should really be simpler than it is
today.
Advantages:
* We could still support Turbine's current security service.
* We can get rid in the default implementation of all those awkward
data fields (email, etc.).
* We can support multiple backends for security data (XML, DB, LDAP,
NT security, whatever).
* Whatever Turbine uses to implement its default security service
(say, based on XML and read-only, or based on a DB with today's
fields), a programmer can "extend" this implementation by writing
her own classes for security and mapper objects.
I believe this could be implemented pretty easily, but would like to
get some feedback before starting the work. Regards,
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Proposal for a new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> I'm looking forward to seeing the new security interface write up. I
> like the sound of your ideas, Gonzalo.
Thanks! I believe this is where we are standing:
* We have to decide whether we will drop Turbine's own security system and
adopt something else. Alternatives that spring up are:
JAAS: http://java.sun.com/products/jaas/
RBAC: http://sourceforge.net/projects/rbac/
Any others?
* If we drop Turbine's own security system, should we provide thin wrappers
for whatever system we adopt (a la JBoss, as described in
http://www.jboss.org/online-manual/HTML/ch09s08.html)?
* If we keep Turbine's security system, how should we modify it? My proposal
fits here; how should we change it? What's missing? What should we do to
make sure (or, as sure as we can) that it satisfies the requirements for
all known Turbine-based projects (such as Jetspeed, Tambora, Scarab,
etc.).
* How do all these issues fit within Jakarta? Should such a security system
be part of commons (or whatever ya wanna call it)? A separate project?
Daniel, it would be great if you could hash these issues around during the
Collab meeting, which I believe is to be held today.
Best regards,
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for a new security model
Posted by Daniel Rall <dl...@finemaltcoding.com>.
I'm looking forward to seeing the new security interface write up. I
like the sound of your ideas, Gonzalo.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Questions on Torque?
Posted by Ian Lim <ma...@ematic.com>.
Hi
Thanks for the question which makes me rethink on the whole definition
regarding
Multiple Database.
I removed it from the feature list for the moment.
The next thing I am thinking of adding is the compatability of the different
libraries
with the different RDBMS (Oracle, Sybase, Interbase, MySQL, PostgresSQL )
available.
This might show some interesting perspective.
Regards
==========
Ian Lim
email: mallim_sg@yahoo.com.sg
homepage: http://www.webappcabaret.com/mallim
P.S. For those who don't know head or tail regarding the above comments,
please refer to
http://www.webappcabaret.com/mallim/main/template/omcompare.vm
----- Original Message -----
From: "Gonzalo A. Diethelm" <go...@aditiva.com>
To: "Turbine Users List" <tu...@jakarta.apache.org>
Sent: Monday, January 07, 2002 07:33 PM
Subject: RE: Questions on Torque?
> What exactly do you mean by "multiple database", where Torque has a "No"?
>
>
> --
> Gonzalo A. Diethelm
> gonzalo.diethelm@aditiva.com
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Questions on Torque?
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
What exactly do you mean by "multiple database", where Torque has a "No"?
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Questions on Torque?
Posted by Ian Lim <ma...@ematic.com>.
Hi
I have incorporated feedback from a few people and update the chart
to my best knowledge.
Changes Done:
- modified the title to reflect more accurately what is the chart about
- added in the column for Object Bridge, however I don't have enough
information at this moment.
- added broad categories Database Support, Tools Support, Mapping Features
New Features List
- Latest Version
- Query Language Support
- Two-Phase Commit
- Multiple Database
- Large ResultSet Cursoring
- GUI Mapping Tool
- Polymorphic Loading
- Self Referential Relation
- Large Object Support
- m:n Relationship
Regarding Torque, I'm not sure of the following things:
- Does Torque able to support large result set cursoring and
self-referencing relationships ?
Regards
==========
Ian Lim
email: mallim_sg@yahoo.com.sg
homepage: http://www.webappcabaret.com/mallim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Proposal for a new security model -- some thoughts
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> I guess you can separate how the security information is stored from how
> it is used. We are using the rbac api for security
>
> http://sourceforge.net/projects/rbac/
I'll take a look at it and come back with my thoughts.
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Proposal for a new security model -- some thoughts
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> We still have access control list like permissions at a user level, but
> the majority of our security is role based. We have two major types of
> permissions: page permissions and object permissions.
Aaron, could you provide some specific examples on how this is used
in your work? The RBAC zip file I downloaded didn't have much in the
way of documentation, and it's not clear to me how it is used in a
real app. Thanks,
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Proposal for a new security model -- some thoughts
Posted by Aaron Smuts <aa...@verizon.net>.
Some thoughts:
I guess you can separate how the security information is stored from how
it is used. We are using the rbac api for security
http://sourceforge.net/projects/rbac/
We still have access control list like permissions at a user level, but
the majority of our security is role based. We have two major types of
permissions: page permissions and object permissions.
Page permisisons can restrict access to a page or an operation based on
a regular expression like check of the url requested or on the
parameters passed. We can decoratively apply page permissions,
developing a security layer after development. An administrator can
define roles and restrictions and limit activity in this way. The
dispatcher used by our front controller servlet applies the
restrictions. This gets a bit annoying for the user, since links are
presented that the user can't access. The sourceforge site works this
way.
Object permissions are more abstract and are used to programatically
restrict the operations of the user. Pages are built using object
permissions. A drop down won't appear or will be limited to a subset of
available data, for instance.
The rbac info for a user is loaded at login and cached, so most of the
checks occur without having to go to the database. This helps a lot.
Check out the rbac api. It is pretty nice. You could make loaders from
a variety of data sources. . . .
Aaron
-----Original Message-----
From: Gonzalo A. Diethelm [mailto:gonzalo.diethelm@aditiva.com]
Sent: Saturday, January 05, 2002 3:35 PM
To: Turbine Users List
Subject: Proposal for a new security model
I have been thinking a little more about Turbine's current security
service and the model behind it. I believe things could be simplified
by refactoring things into the following ideas:
* Very shallow interfaces for User, Permission, Role, Application and
Session. These only hold a unique key for each object and have
methods to query and set their relationships; for instance, Role
would have getPermissionSet, hasPermission, addPermission,
removePermission, etc. And maybe some administrative methods for
each, such as rename, delete, etc. Of course, User would have
validatePassword and changePassword, and would hold a Session.
* A straightforward implementation for each of these interfaces within
Fulcrum: FulcrumUser, FulcrumPermission, etc.
* ALL USES of the security objects in Fulcrum and Turbine must be
through the security interfaces! If we find that there are
additional fields required to keep Turbine's current functionality
(I believe last_access could be one of these), we could discuss
adding those to the basic interfaces.
(Notice that up to this point there is no information on how these
objects are loaded, saved, etc.).
* Interfaces for mapper objects that take care of loading, saving,
etc. the basic security objects from whatever backend. For example,
UserMapper would have load, save, rename, delete, etc. This opens
up the possibilities to map the security objects to whatever backend
the programmer wants to use.
* A straightforward implementation for each mapper within Fulcrum.
This implementation could just read the data from an XML file and
forbid any modification of the data; this way, Fulcrum would not
require a DB for its basic configuration.
* A good set of configuration entries in TR.props, so that the
programmer can choose what classes to use for each of the security
objects and each of the mapper objects.
* Turbine 3 could include objects such as ClassicUser, etc. that
extend FulcrumUser, etc. and add all the other data fields that are
there today (email, etc.). This could or could not be the default
security implementation within Turbine; that's not for me to
decide, although I do believe it should really be simpler than it is
today.
Advantages:
* We could still support Turbine's current security service.
* We can get rid in the default implementation of all those awkward
data fields (email, etc.).
* We can support multiple backends for security data (XML, DB, LDAP,
NT security, whatever).
* Whatever Turbine uses to implement its default security service
(say, based on XML and read-only, or based on a DB with today's
fields), a programmer can "extend" this implementation by writing
her own classes for security and mapper objects.
I believe this could be implemented pretty easily, but would like to
get some feedback before starting the work. Regards,
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for a new security model
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/5/02 11:48 PM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:
>>> I believe this could be implemented pretty easily, but would like to
>>> get some feedback before starting the work. Regards,
>>
>> I'm about to jump on a plane and I would like to look at your
>> proposal but I
>> urge you to fully work out the design before you start coding. I
>> agree that
>> the security model that we have is too complicated for most uses
>> and people
>> have either misused it or have been confused.
>
> That's exactly why I posted my message to the forum: I really would
> like to hear as many opinions, hints and criticism as I can before
> sitting down and getting anything done.
Great, thanks Gonzalo.
>
>> I have no doubt in your ability but please let us debug the design as a
>> group. As with the pipeline Dan and I have made tests and chatted
>> about how
>> it might work but no serious work has been done because we still need to
>> decide exactly how it works.
>
> Now that I re-discovered IRC, I would definitely like to talk at
> length about the security system.
Cool, there's usually a bunch of us in the IRC chat room. It's definitely a
good place to bounce ideas around.
>> I think that the best thing you could do is present the design in the form
>> of the interfaces (or UML if you prefer) and lets put the design through a
>> couple of use cases. I usually think about Tambora and Jetspeed as my
>> examples. Tambora has relatively simple security needs, but Jetspeeds are
>> somewhat more complicated.
>
> Ok, I will write up the Interfaces, trying to keep an eye on what's there
> for Turbine 3, and send it to the list for examination.
Awesome :-)
>> If you have ideas, throw them into CVS and we can talk about those too at
>> the informal meeting on the 10th @ Collab.
>
> Will notify when I have something done.
>
>> Jason van Zyl
>
>
> --
> Gonzalo A. Diethelm
> gonzalo.diethelm@aditiva.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Proposal for a new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> > I believe this could be implemented pretty easily, but would like to
> > get some feedback before starting the work. Regards,
>
> I'm about to jump on a plane and I would like to look at your
> proposal but I
> urge you to fully work out the design before you start coding. I
> agree that
> the security model that we have is too complicated for most uses
> and people
> have either misused it or have been confused.
That's exactly why I posted my message to the forum: I really would
like to hear as many opinions, hints and criticism as I can before
sitting down and getting anything done.
> I have no doubt in your ability but please let us debug the design as a
> group. As with the pipeline Dan and I have made tests and chatted
> about how
> it might work but no serious work has been done because we still need to
> decide exactly how it works.
Now that I re-discovered IRC, I would definitely like to talk at
length about the security system.
> I think that the best thing you could do is present the design in the form
> of the interfaces (or UML if you prefer) and lets put the design through a
> couple of use cases. I usually think about Tambora and Jetspeed as my
> examples. Tambora has relatively simple security needs, but Jetspeeds are
> somewhat more complicated.
Ok, I will write up the Interfaces, trying to keep an eye on what's there
for Turbine 3, and send it to the list for examination.
> If you have ideas, throw them into CVS and we can talk about those too at
> the informal meeting on the 10th @ Collab.
Will notify when I have something done.
> Jason van Zyl
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for a new security model
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/5/02 3:35 PM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:
> I believe this could be implemented pretty easily, but would like to
> get some feedback before starting the work. Regards,
I'm about to jump on a plane and I would like to look at your proposal but I
urge you to fully work out the design before you start coding. I agree that
the security model that we have is too complicated for most uses and people
have either misused it or have been confused.
I have no doubt in your ability but please let us debug the design as a
group. As with the pipeline Dan and I have made tests and chatted about how
it might work but no serious work has been done because we still need to
decide exactly how it works.
I think that the best thing you could do is present the design in the form
of the interfaces (or UML if you prefer) and lets put the design through a
couple of use cases. I usually think about Tambora and Jetspeed as my
examples. Tambora has relatively simple security needs, but Jetspeeds are
somewhat more complicated.
I too want to see Turbine 3.x out the door as much as anyone but I think
something like the security has to worked out as a group. We obviously have
problems with our current model and I think this is because it was primarily
implemented by a single person without much feedback during the process. I
would like that not to happen again.
If you have ideas, throw them into CVS and we can talk about those too at
the informal meeting on the 10th @ Collab.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>