You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Aaron Smuts <aa...@verizon.net> on 2002/01/06 02:47:16 UTC
RE: Proposal for a new security model -- some thoughts
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: 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>