You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by "Brekke, Jeff" <Je...@qg.com> on 2002/01/04 18:14:19 UTC
RE: How to extend TURBINE_USER - a solution to the documented pro
blem
We have similar issues. We are using NT for username and password auth. We
also have corporate database tables with usernames, addresses, employee
numbers, etc. We don't really have the requirement to have persistent
information stored with the user, so we just created our own SecurityService
and UserManager. The service just authenticates the username and password
against the domain, and looks up information from our corporate tables,
populating a TurbineUser object. We could write our own User object instead
of using TurbineUser, but we really only are using it for storage. The only
hacky thing is we use the confirmed field in the object to hold the users
employee number. In the service we also populate the permissions and roles
from the nt domain groups. Once we move to 2000, maybe we'll look at using
ldap and hitting active directory for everything.
-----------------------------------------------------------------
Jeffrey D. Brekke Quad/Graphics
Jeff.Brekke@qg.com http://www.qg.com
-----------------------------------------------------------------
> -----Original Message-----
> From: Pugh, Eric [mailto:EPugh@MuseumCompany.com]
> Sent: Friday, January 04, 2002 8:43 AM
> To: 'Turbine Users List'
> Subject: RE: How to extend TURBINE_USER - a solution to the documented
> pro blem
>
>
> Scott,
>
> I am not sure how many changes you are proposing, but one
> change that I
> would love to see is that the interface User was a lot more
> abstract. For
> our company right now, we use microsoft technologies, and all
> our users are
> stored using NT Authentication. Until I can hook turbine up
> to ask for a
> username and password that is validated against the NT
> domain, it doesn't
> make sense for us to duplicate users passwords into the
> Turbine tables.
> Therefore, we decided as a stop gap, that since usernames
> change rarely, but
> passwords change frequently, that we would use an already
> existing table
> EMPLOYEE, and just add an OBJECTDATA column to it to store
> extended Turbine
> information. Unfortuantantly, the existing TurbineUser
> interface has led to
> a lot of problems for us.
>
> Our EMPLOYEE table schema:
> EMPLOYEE_ID int
> USERNAME varchar
> ACTIVE bit
> OBJECTDATA image
>
> Therefore we don't have things like getConfirmed values, Last
> Access Date,
> Last Name, Password, etc.. Now, a lot of that could have
> been stored as
> part of the ObjectData value, but we didn't need any of that.
>
> I ended up hacking up a lot of the Turbine's built in code
> for handling
> users to make it work with our system, but it is not very pretty.
> Eventually, when we go back to having username AND password for
> authentication, then we can go back to using the existing
> Turbine system.
> But in the meantime, what would have made life much easier
> would be to have
> a very basic interface for User and TurbineUser. That way we
> wouldn't have
> to dummy up a lot of values and methods.
>
> My code that I used is viewable as a zip at
> http://briefcase.yahoo.com/dep4b
> in the Java directory.
>
> Just my 2 cents...
>
> Eric
>
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Friday, January 04, 2002 6:36 AM
> To: turbine-user@jakarta.apache.org
> Subject: How to extend TURBINE_USER - a solution to the documented
> problem
>
>
> About a month ago I revisited the work I did earlier on
> extending turbine_user. My goal was to overcome the
> problem I had identified and documented about 3/4 of
> the way down the extend-user-howto under the heading
> "Additional Information (Added 12 Nov 2001)". To
> summarise, after going through all of the effort to extend
> turbine_user, the implementation is incomplete because
> user.save() fails to save any related objects you may have
> added using the generated user.addXXX() methods.
>
> By making some small changes to torque's Object.vm
> template it is possible to have the code necessary to
> save the related objects generated in the OM class
> for the turbine_user alias. This solution is reasonably
> small and it works well (I am using it in a production
> site).
>
> The only trouble with this solution is that it seems a
> bit like a hack because it mixes non-turbine security
> objects with turbine security objects - you can include
> the user.save() in a transaction, but the saving of the
> actual turbine_user record will not be part of the
> transaction because the turbine db security
> implementation does not allow for this.
>
> Anyway, I have a solution that works. My question
> is, should I submit a patch to Object.vm that could
> be considered to be a hack or should I just outline the
> hack in a patch to extend-user-howto so that interested
> users can apply the patch themselves?
>
>
> BTW: Anyone that has extended turbine_user will love
> this change. With it you can use data.getUser() just
> like any other OM class (after casting it to your alias
> class).
>
> Any thoughts?
>
> Scott
>
>
>
> --
> 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>
--
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>
Proposal for a new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
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: How to extend TURBINE_USER - a solution to the documented pro blem
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> We have similar issues. We are using NT for username and
> password auth.
<rant>
One of the things that always bothered me about Turbine's user
system is that it tries to do too much. It certainly looks like
it is geared towards Internet apps, where users can create
their own accounts. However, I really believe that for the
general case (which is what Turbine should tackle), things like
e-mail address, etc. are too much; in this case, less is better.
So, I concur with previous posters in claiming that Turbine's
user system should tackle one and only one objective: a rational
way of providing security management. I would like to see a
user system based on VERY SIMPLE interfaces, using opaque ids,
and pliable enough to allow using it as the front end for various
real-world back-ends (Windows NT security, LDAP, DB, YP, whatever).
I'm thinking of the following abstractions (interfaces):
* User: id
validatePassword(password)
changePassword(password)
hasPermission(permission)
hasAnyPermission(permissionList)
hasAllPermissions(permissionList)
* Permission: id
* Role: id
* Application (or Realm, or System, what today is Role): id
* The following relationships:
Role_Permission
User_Role_Application
* No additional data in any of the objects.
* A REALLY EASY and WELL DOCUMENTED way of extending a default
Turbine implementation of these concepts, so that more data
could be added to the objects (e-mail, whatever).
* (Maybe the same as previous) An easy way of mixing Turbine's
user system with existing systems (NT, LDAP, whatnot).
</rant>
To put my money next to what I'm saying here, I am willing to
cooperate in designing, implementing, testing, etc. such a
system, if we agree this is a good idea.
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>