You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Jason van Zyl <jv...@zenplex.com> on 2002/01/04 15:58:00 UTC
2.2 Plan
Hi,
All users that have responded on the list want to wait for the decoupled
versions of torque and fulcrum to be available for use in 2.x before we
release. We have discussed this briefly in IRC but how about the following
for a plan.
i) Introduction of lifecycle interfaces in org.apache.stratum.lifecycle.
These are direct copies of Avalon's lifecycle interfaces as I see no point
making signatures that aren't compatible, we may never use Avalon but I
could definitely see some of their lifecycle interfaces moving into the
commons eventually.
ii) Make Torque and Fulcrum implement these lifecycle interfaces so that
they can be manipulated in the same fashion with respect to configuration
and initialization.
iii) Code would be added to both t3 and t2 so that subsystems implementing
these lifecycle interfaces can be dealt with. The result will be the
pluggability of large subsystems like services frameworks and persistence
frameworks. So someone could use another services framework or persistence
tool with t3 a lot more easily. The upshot is also that Torque will be used
directly and we'll get rid of the DatabaseService all together.
Martin is willing to work on the Turbine code, and I can work on the Fulcrum
code and making the necessary changes to the turbine code.
This is the only way I can see to allow us to use the decoupled codebases in
both t2 and t3.
In Tambora, as I imagine with many 2.x projects, we want to help contribute
toward the decoupled code bases but we can't move away from 2.x for a while
so Martin and myself can definitely put some time into this as it is
important for Tambora. In a brief chat with Martin we decided that we could
get most of the work and testing done in three weeks if we start today.
I think as soon as we can get rid of the couple code bases the better and it
appears that users are willing to wait, as they've waited this long already.
So I'm an obvious
+1
--
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: First ideas for new security model
Posted by Santiago Gala <sg...@hisitech.com>.
Jason van Zyl wrote:
>Hi,
>
>Can I suggest that we take a different approach to this problem?
>
>There are many different security models and I don't think it is possible to
>find a single model that is going to satisfy every situation, it's just not
>going to happen.
>
>The security models used by Scarab and SourceCast are probably the most
>sophisticated security model that any application would ever need, that
>being the case I think it would be rare that many applications would need
>that level of sophistication.
>
>I think trying to accommodate aspects of all security models into a single
>one is a lost cause. I think we should look for the places where security
>applies to Turbine and find a way for the core to use any model that a
>project wishes to use. From a simple password text file model all the way up
>to a sophisticated model like Scarab's. What we currently have is too
>complicated for most uses and we should allow application programmers to
>choose the model they wish to use. This will also allow easier integration
>into J2EE environments.
>
From the analysis our people is doing, we need to address three
separate issues here (I said two in previous e-mails, I had not grasped
it fully ;-) ):
1- Authentication
2- AccessControl
3- User Management/Profiling
1 means giving a credential to the service and getting back a (set of)
Principal/Subject, you name it.
2 means that, for a certain request and a certain authenticated User
(Principal/Subject/whatever), you can derive a set of Permissions that
are valid. Here is where things like Permission, Group, Role, ... belong
3 means ways to create, store, ... users and information related to
users , like user preferences, etc.
In some cases, we will authenticate against a external source, be it
JAAS, LDAP, pam, Apache,... but we will not get anything from this
external resource except the fact that the Principal name (User name?)
is OK with the system. Thus, we are free to implement our own groups,
roles, ...
In other cases, the AccessControl can be external (let us imagine a
scenario where JAAS and a SecurityManager are switched on). In this
scenario, java.lang.Permission and AccessController.checkPermission()
are already in place.
Even in this scenario, User preferences or permanent information may
need to be stored in the system.
Separating the service in this three components/subservices will help
isolate clean interfaces between them (The work is partially done, as we
have a UserManager in turbine, and also a AccessController). This will
help clean any implementation we do, and will allow for easy
interoperation of different implementations. It will also make audits
simpler, since the code of each sub-component will be simpler and more
focused.
I also suggest to look deeply into JAAS, as I'm afraid that any J2EE
application has already a tight security system working.
>
>I have no particular bias as to which security model is best, they probably
>all have benefits and drawbacks but I would like to take a stab at the hooks
>that would allow different models to be used. Some changes to RunData and
>the addition of site policy mechanism I think can do the trick. I'm working
>on finishing the UML for a new scheduler and I'll try to make some diagrams
>for security model hooks.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Santiago Gala <sg...@hisitech.com>.
Eric Dobbs wrote:
(snip)
> On Tuesday, January 15, 2002, at 04:55 AM, Santiago Gala wrote:
In fact, the idea came to me from a co-worker (Juan Carlos Alvarez)
lurking around here and quite a few other lists, but so shy as to hardly
ever post! Due hommage. ;)
>
>> Separating the service in this three components/subservices will help
>> isolate clean interfaces between them (The work is partially done, as
>> we have a UserManager in turbine, and also a AccessController). This
>> will help clean any implementation we do, and will allow for easy
>> interoperation of different implementations. It will also make audits
>> simpler, since the code of each sub-component will be simpler and
>> more focused.
>
>
> I'm not sure how it will look in code, but I like the idea of
> several specialized and loosely coupled security services.
> Here's Santiago's three (I'll elaborate on this a bit below):
>
>> 1- Authentication
>> 2- AccessControl
>
I used this term on purpose (as we have a AccessController in Turbine),
but it is usually called Authorization, as you point later.
>>
>> 3- User Management/Profiling
>
Things like home directory, the passwd command, .profile, are examples
at the OS level.
>>
>>
>>
I think this idea is very sound. He came to it while finding a way to
implement LDAP authentication while keeping DB Authorizaton (groups,
roles, and permissions) and Profiling (perm storage) information.
After discussion, we agreed that these services can be largely isolated,
so that they use different implementations, because they are
functionally independent, related through the Principal/Subject
abstraction (using JAAS jargon) that a user gets assigned after
successful login.
Your (snipped) elaboration on the Authorization part is nice. I think
you could write good documents on the security service ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Eric Dobbs <er...@dobbse.net>.
Hi All.
Sorry to come in late to the conversation. While I
have been composing this email, you all have started
writing code...
Security means different things in different contexts,
but from following the discussion it seems that
Turbine's security needs are primarily: Authentication
-- verify the user's identity Authorization -- limit
what users are allowed to do
Many systems have those same needs, and Authorization
typically
includes some combination of the following:
abstractions for users,
abstractions for "stuff",
permissions, and
roles or groups
I've seen quite a few different security models. I
think the similarities are greater than the
differences. The fundamental differences boil down to
these issues: 1) are permissions attached to the user,
or attached to the stuff? 2) are users members of
groups, or do they have roles? 3) are the permissions
hierarchical?
For example, WinNT/2K ACLs have permissions attached to
the stuff, specifically to the files and directories.
By contrast, Turbine ACLs attach permissions to the
user (indirectly via roles). Java's Security (not JAAS)
is about protecting computer resources from malicious
programs -- permissions are granted to programs
("stuff") to gain access to system resources (other
"stuff"). Most databases grant permissions to users.
JAAS extends this idea to say that some chunk of code
is granted some permission provided that code is being
run by a particular user or to a user who is playing a
particular role. Permissions are attached to both
stuff and users.
Santiago already made this distinction earlier in the
thread, but I thought I would draw more attention to
it. User preferences and personalization confuse
security matters.
Personalization requires very similar programming to
authorization. Based on information you have about
the user you want to change the display to fit their
preferences, as opposed to their permissions.
Having said all of that, let me now comment directly
on a few items from the thread...
On Monday, January 14, 2002, at 10:15 PM, Jason van Zyl wrote:
> The security models used by Scarab and SourceCast are probably the most
> sophisticated security model that any application would ever need, that
> being the case I think it would be rare that many applications would
> need
> that level of sophistication.
I disagree. I happen to be building "enterprise
solutions". I know that not everyone else is but in my
experience, security needs quickly grow to require
sophisticated solutions, even in seemingly small webapps.
> I think trying to accommodate aspects of all security models into a
> single
> one is a lost cause. I think we should look for the places where
> security
> applies to Turbine and find a way for the core to use any model that a
> project wishes to use.
+1 I've tried to start that process above.
> From a simple password text file model all the way up
> to a sophisticated model like Scarab's. What we currently have is too
> complicated for most uses and we should allow application programmers to
> choose the model they wish to use.
Here I disagree in particular about the "too complicated" part.
In this area, the problem with what currently exists is a lack of
documentation and not one of complexity. And the TDK offers no
instructive example, so users are pointed at Scarab which isn't
using the default implementation anyway. Then add the misleading
name "TURBINE_GROUP" and all of it's associated confusion....
I favor adopting a more sophisticated model, provided we also
include sufficient documentation and examples. (And because I'm
sure *someone* will ask ;^) Yes, I am willing to contribute to
documentation once we agree on something.
> I think trying to accommodate aspects of all security models into a
> single
> one is a lost cause.
Agreed, which is why I like this suggestion from Santiago:
On Tuesday, January 15, 2002, at 04:55 AM, Santiago Gala wrote:
> Separating the service in this three components/subservices will help
> isolate clean interfaces between them (The work is partially done, as
> we have a UserManager in turbine, and also a AccessController). This
> will help clean any implementation we do, and will allow for easy
> interoperation of different implementations. It will also make audits
> simpler, since the code of each sub-component will be simpler and more
> focused.
I'm not sure how it will look in code, but I like the idea of
several specialized and loosely coupled security services.
Here's Santiago's three (I'll elaborate on this a bit below):
> 1- Authentication
> 2- AccessControl
> 3- User Management/Profiling
>
> 1 means giving a credential to the service and getting back a (set of)
> Principal/Subject, you name it.
> 2 means that, for a certain request and a certain authenticated User
> (Principal/Subject/whatever), you can derive a set of Permissions that
> are valid. Here is where things like Permission, Group, Role, ... belong
> 3 means ways to create, store, ... users and information related to
> users , like user preferences, etc.
I would like to expand on the AccessControl item in
particular. I'd like to see the system support either
user-centric or stuff-centric permissions.
Sometimes you want to build a cage around the crown
jewels (stuff-centric) and sometimes you want to
prevent people from entering a sensitive part of the
castle (user-centric). These are complementary but not
synonymous needs. And the AccessControl (or
Authorization) should support both modes.
I also like this list from Dan D
On Tuesday, January 15, 2002, at 12:38 PM, Dan Diephouse wrote:
> Permissions - read, write, delete, update...etc.
> Roles - Admin (has read,write,delete, update); User ( read, update) and
> so on.
> Group (or Application) - Project Management, Contact Database.
> ProjectGroup - Marketing Campaign for XXX, TV Ads for ABC Inc.
But we gotta clear up the "group" confusion:
Permissions
Roles - Admin, Editor, Contributor, User
Group - *
Project (or Module) - Project Management, Contact DB, Inventory...
Application - a collection of Projects (or Modules).
* Please! A "Group" must be a group of people. It is
completely counter-intuitive and confusing to use
"Group" to describe a collection of functional
elements, particularly in the context of user
authorization. This is the heart of the TURBINE_GROUP
confusion and one of the crucial things to be changed
by the new security framework.
Either use "group" to mean a group of people, or don't
use "group". (ProjectGroup is okay 'cos it's explicit
about what it's grouping.)
I would also prefer that the system allow permissions
to be attached to Roles or Groups or both. (This has
the potential to be confusing and will be another thing
that will require clear documentation).
Different people want to group people differently.
Some group by organizational units (Development,
Marketing, Finance), or by geographical region (US
West, US Central, EU North, Asia Pacific Rim,) or
whatever. Some prefer to assign Permissions along
these categories rather than by roles, or in
addition to roles within those groupings.
I've got more thoughts, but I should send this now and
see what you think before you get a complete system
implemented under my nose ;^)
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/15/02 7:09 AM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:
>> There are many different security models and I don't think it is
>> possible to
>> find a single model that is going to satisfy every situation,
>> it's just not going to happen.
>
> This is probably true, however...
I don't think you're going to be able to get around this fact and people are
going to have to hack the core to a large extent to make another model work.
The Jetspeeders are working on their security model which is going to be
portlet specific and we may or may not be able to merge the ideas into a
single model.
I'm am going to do some research on a pluggable system because I can't see a
single model working for all cases. I don't see any downside to allowing a
project to specify their own security model.
>
>> The security models used by Scarab and SourceCast are probably the most
>> sophisticated security model that any application would ever need, that
>> being the case I think it would be rare that many applications would need
>> that level of sophistication.
>>
>> I think trying to accommodate aspects of all security models into a single
>> one is a lost cause. I think we should look for the places where security
>> applies to Turbine and find a way for the core to use any model that a
>> project wishes to use. From a simple password text file model all
>> the way up
>> to a sophisticated model like Scarab's. What we currently have is too
>> complicated for most uses and we should allow application programmers to
>> choose the model they wish to use. This will also allow easier integration
>> into J2EE environments.
>
> I believe we have sort of done this with T2, which chose a simple
> role-based security model with the extension of grouping users into
> Groups to allow for a server serving more than one app (could this
> be called the role+1 security model? pun intended...).
This model may very well work for a lot of cases (I think a lot of people
have had difficulty with this model though -- evidence is in the archives)
but it can't work for all of them and really would like it if we didn't
force people into one security model.
>> I have no particular bias as to which security model is best,
>> they probably
>> all have benefits and drawbacks but I would like to take a stab
>> at the hooks
>> that would allow different models to be used. Some changes to RunData and
>> the addition of site policy mechanism I think can do the trick.
>> I'm working
>> on finishing the UML for a new scheduler and I'll try to make
>> some diagrams
>> for security model hooks.
>
> I believe a simple model, such as what I have proposed (but it doesn't
> have to be THAT one, as long as it is flexible enough), that provides
> extensible role-based security, fits your description, doesn't it?
Possibly but I honestly doubt it, I haven't look at your code yet but I will
look before commenting further. There's no reason why what you're working on
can't be the default, I would just prefer if it was not the only option.
>> 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: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> There are many different security models and I don't think it is
> possible to
> find a single model that is going to satisfy every situation,
> it's just not going to happen.
This is probably true, however...
> The security models used by Scarab and SourceCast are probably the most
> sophisticated security model that any application would ever need, that
> being the case I think it would be rare that many applications would need
> that level of sophistication.
>
> I think trying to accommodate aspects of all security models into a single
> one is a lost cause. I think we should look for the places where security
> applies to Turbine and find a way for the core to use any model that a
> project wishes to use. From a simple password text file model all
> the way up
> to a sophisticated model like Scarab's. What we currently have is too
> complicated for most uses and we should allow application programmers to
> choose the model they wish to use. This will also allow easier integration
> into J2EE environments.
I believe we have sort of done this with T2, which chose a simple
role-based security model with the extension of grouping users into
Groups to allow for a server serving more than one app (could this
be called the role+1 security model? pun intended...).
> I have no particular bias as to which security model is best,
> they probably
> all have benefits and drawbacks but I would like to take a stab
> at the hooks
> that would allow different models to be used. Some changes to RunData and
> the addition of site policy mechanism I think can do the trick.
> I'm working
> on finishing the UML for a new scheduler and I'll try to make
> some diagrams
> for security model hooks.
I believe a simple model, such as what I have proposed (but it doesn't
have to be THAT one, as long as it is flexible enough), that provides
extensible role-based security, fits your description, doesn't it?
> 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: First ideas for new security model
Posted by Jason van Zyl <jv...@zenplex.com>.
Hi,
Can I suggest that we take a different approach to this problem?
There are many different security models and I don't think it is possible to
find a single model that is going to satisfy every situation, it's just not
going to happen.
The security models used by Scarab and SourceCast are probably the most
sophisticated security model that any application would ever need, that
being the case I think it would be rare that many applications would need
that level of sophistication.
I think trying to accommodate aspects of all security models into a single
one is a lost cause. I think we should look for the places where security
applies to Turbine and find a way for the core to use any model that a
project wishes to use. From a simple password text file model all the way up
to a sophisticated model like Scarab's. What we currently have is too
complicated for most uses and we should allow application programmers to
choose the model they wish to use. This will also allow easier integration
into J2EE environments.
I have no particular bias as to which security model is best, they probably
all have benefits and drawbacks but I would like to take a stab at the hooks
that would allow different models to be used. Some changes to RunData and
the addition of site policy mechanism I think can do the trick. I'm working
on finishing the UML for a new scheduler and I'll try to make some diagrams
for security model hooks.
--
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: First ideas for new security model
Posted by Eric Dobbs <er...@dobbse.net>.
On Tuesday, January 15, 2002, at 09:59 AM, Jon Scott Stevens wrote:
> on 1/15/02 4:03 AM, "Gonzalo A. Diethelm" <go...@aditiva.com>
> wrote:
>
>> A User has Roles within an Application (System? Realm? FooBar?)
>
> A user has roles within a project within an application.
+1
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 1/15/02 4:03 AM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:
> A User has Roles within an Application (System? Realm? FooBar?)
A user has roles within a project within an application.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> >> A Session may o may not have a User.
> >>
> > This is problematic. I am experimenting now, and Jetspeed code
> > is/would be much simpler and cleaner if we could assume that every
> > request has a User, with its Groups, Roles, ACLs and permissions. One
> > way to achieve this is to have always a user (to have a explicit
> > Anonymous user configured) and have all request authenticated either
> > by a real user or by the "anon" user.
Yeah, this is what T2 does (I believe).
> > This simplifies and makes much more robust all the code, and has also
> > the added benefit that the default permissions can be configured
> > without having to change the code (they would be stored under the
> > anon/nobody user in the DB, LDAP,...).
Good point!
> > The concept is very similar to what happens at the OS level. You
> > perform any action as a certain user "Guest", "nobody",...
>
> Leonard and I have found the same to be true. Some of our sites do
> run with no "anonymous" user, but the code would be much cleaner if we
> did not have to support this configuration.
Ok, I think you guys make a good point. Let's change the basic rules
to the following:
A Role has Permissions.
A User has Roles within an Application (System? Realm? FooBar?)
A Session has exactly one User, which is "anonymous" by default.
--
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: First ideas for new security model
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Santiago Gala <sg...@hisitech.com> writes:
> Gonzalo A. Diethelm wrote:
>
>> A Session may o may not have a User.
>>
> This is problematic. I am experimenting now, and Jetspeed code
> is/would be much simpler and cleaner if we could assume that every
> request has a User, with its Groups, Roles, ACLs and permissions. One
> way to achieve this is to have always a user (to have a explicit
> Anonymous user configured) and have all request authenticated either
> by a real user or by the "anon" user.
>
> This simplifies and makes much more robust all the code, and has also
> the added benefit that the default permissions can be configured
> without having to change the code (they would be stored under the
> anon/nobody user in the DB, LDAP,...).
>
> The concept is very similar to what happens at the OS level. You
> perform any action as a certain user "Guest", "nobody",...
Leonard and I have found the same to be true. Some of our sites do
run with no "anonymous" user, but the code would be much cleaner if we
did not have to support this configuration.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Santiago Gala <sg...@hisitech.com>.
Gonzalo A. Diethelm wrote:
>>This is great stuff.
>>
>
>Thanks!
>
>>Please, if you start working on the DB backend,
>>use the Torque generated peers.
>>
>
>Absolutely, eat our own food!
>
>One clarification: someone asked me what had happened to Groups.
>>>From past discussions here on the list, I remember the name Group
>was confusing to a lot of people. What I call Application in my
>proposal corresponds to the idea of a Group:
>
> A Role has Permissions.
> A User has Roles within an Application (System? Realm? FooBar?)
>
Since I think I already understand the Group entity, I'm no longer
unhappy with the name ;)
>
> A Session may o may not have a User.
>
This is problematic. I am experimenting now, and Jetspeed code is/would
be much simpler and cleaner if we could assume that every request has a
User, with its Groups, Roles, ACLs and permissions. One way to achieve
this is to have always a user (to have a explicit Anonymous user
configured) and have all request authenticated either by a real user or
by the "anon" user.
This simplifies and makes much more robust all the code, and has also
the added benefit that the default permissions can be configured without
having to change the code (they would be stored under the anon/nobody
user in the DB, LDAP,...).
The concept is very similar to what happens at the OS level. You perform
any action as a certain user "Guest", "nobody",...
It could interfere with the UserManager backend by bringing unnecessary
synchronization, because of the setTemp()/setPerm() in the code, but I'm
looking into this.
>
>
>If anybody has better names for any of these things, speak up!
>
>> Henning
>>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Bert van Brakel <be...@yahoo.com>.
I'll throw my 2 cents worth in:
How about
interface SecurityService
{
boolean hasPermission (User, String );
boolean hasPermission( User, String, String );
boolean hasPermission( User, String, String, String );
boolean hasPermission( User, String, String, String, String,
String );
}
Where interface user has:
interface User{
String get/set identifier
String get/set password
}
Then it's up to the implementator to decide on what the strings mean in the
SecurityServic. You could have:
SecurityService.hasPermission ( User, "permission", "role", "group")
or SecurityService.hasPermission( User, "permission", role",
"projectgroup", "application")
or SecurityService.hasPermission( User, "group", "permission", "group",
"projectgroup") (if you want to get really screwy )
To avoid confusion we could use SecurityService.isAllowed( User,
String.....) instead of hasPermission....
Have it text based. Simple. That's the way I like it, even I can understand
that. I think 4 string values would be enough, but we could make the
SecurityService have more if we want. If you want to use only
hasPermission(User, String) then all the other methods just map to this one.
I think having it string based allows the most flexibility as we don't have
to use any particular object, except for User.
The implementing security service could test and cast the user object into
whetever they have used, and access their own security objects.
By using the simple User interface its upto the implementor to decide on
whether a unique identifier is a username or a uerid or whatever.
The only drwaback offcourse it that you can't get the compiler to check you
have things in the right order, but that's your problem!
Think simple :-)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Kelvin Tan <ke...@relevanz.com>.
FWIW, has anyone checked out http://csrc.nist.gov/rbac/? Goodly collection
of whitepapers and stuff on the topic.
<excerpt>
One of the most challenging problems in managing large networked systems is
the complexity of security administration. Today, security administration is
costly and prone to error because administrators usually specify access
control lists for each user on the system individually. Role based access
control (RBAC) is a technology that is attracting increasing attention,
particularly for commercial applications, because of its potential for
reducing the complexity and cost of security administration in large
networked applications.
With RBAC, security is managed at a level that corresponds closely to the
organization's structure. Each user is assigned one or more roles, and each
role is assigned one or more privileges that are permitted to users in that
role. Security administration with RBAC consists of determining the
operations that must be executed by persons in particular jobs, and
assigning employees to the proper roles. Complexities introduced by mutually
exclusive roles or role hierarchies are handled by the RBAC software, making
security administration easier.
</excerpt>
Regards,
Kelvin
----- Original Message -----
From: Gonzalo A. Diethelm <go...@aditiva.com>
To: Turbine Developers List <tu...@jakarta.apache.org>
Cc: <di...@eastnode.com>
Sent: Monday, January 21, 2002 8:22 PM
Subject: RE: First ideas for new security model
> > Dan Diephouse, could you summarize your ideas in a stand-alone posting?
> > We may be getting closer to a consensus, and it would be good to look
> > again at what you propose in full.
>
> Also, I think it would be good to keep in mind that it is probably
> a good idea that the design of the security system separates these
> concerns:
>
> 1. Authentication (log-in, log-out, password admin?)
> 2. Authorization (is this user allowed to do this)
> 3. Profiling (user preferences)
> 4. Administration (add, edit, remove users)
>
>
> --
> 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: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> > Um, I couldn't disagree more. The current Turbine security model is
> > limited in many aspects.
>
> I didn't say it wasn't limited. I said that it is a pretty
> functional system
> for webapps. Scarab (a very very complex webapp) uses it and it is fine.
What I personally don't like about the current model is:
* It is specifically tailored to Internet webapps.
* It is hard to adapt to different "back-end" security systems (NT,
LDAP, whatever).
* It provides ONE way of creating relationships between users and
permissions, through roles and groups; what if I want to use
a different set of relationships?
I think we need a pluggable (or "skinabble", to be in fashion) system
that allows to use Turbine's current model, but that it also makes it
easy for developers to switch to a totally different model. And, if
possible, with a default implementation that doesn't require a DB.
> -jon
--
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: First ideas for new security model
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 1/21/02 12:29 PM, "Dan Diephouse" <di...@eastnode.com> wrote:
> Um, I couldn't disagree more. The current Turbine security model is
> limited in many aspects.
I didn't say it wasn't limited. I said that it is a pretty functional system
for webapps. Scarab (a very very complex webapp) uses it and it is fine.
> So I can only group my users via the applications they
> are working on. Or I could group my users by the projects they are
> working on, but not both.
A user can live in multiple groups. A group could be an application or
project.
> Not to mention, I can't create user groupings
> - like referring to Jon, Dan, and Jane as the group "Staff Members."
They would all have the same Role ('Staff Members').
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Dan Diephouse <di...@eastnode.com>.
Um, I couldn't disagree more. The current Turbine security model is
limited in many aspects. It has only one grouping mechanism - Groups
(Or projects). So I can only group my users via the applications they
are working on. Or I could group my users by the projects they are
working on, but not both. Not to mention, I can't create user groupings
- like referring to Jon, Dan, and Jane as the group "Staff Members."
Please refer to my other message and other people's where I explain WHY
Turbine's security model doesn't work:
http://www.mail-archive.com/turbine-dev%40jakarta.apache.org/msg05102.html
- Dan Diephouse
Jon Scott Stevens wrote:
>$0.00
>
>What seems to be missing here and all of the conversations I have seen about
>this up until this point, is 'What' we want to secure.
>
>In other words, we know that we need to have some concept of 'users'...but
>once you have that, what are you actually securing? I think that should be
>what defines how the security system is built.
>
>Yes, we realize, we need #1 and #2...but if you think about #2 further, you
>need to realize that we need to also answer that question with joins against
>other data such as: "is the user part of a project and if so, what roles
>does the user have in that project"?
>
>API's like JAAS are great at securing access to source code. But, they
>really don't go beyond that without trying to munge them into something they
>aren't.
>
>Honestly, I don't even see why this conversation is happening. The Turbine
>security system is pretty good as it stands. Renaming Group -> Project and
>documenting the heck out of it would be the only changes I see as being
>necessary in order to have a pretty functional security system for webapps.
>
>$0.00.
>
>-jon
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Incze Lajos <in...@mail.matav.hu>.
> I don't like the need to create an additional class to wrap
> actions that are to be made secure. (Having written that
> complaint I suppose it's really just a matter of having the
> original objects implement the right interfaces.)
>
> My second complaint is that I don't exactly see how to use
> Subject.doAs() to control what gets displayed in the UI. It
> is very clear how that fits into Turbine actions, but
> doesn't seem to fit well in limiting what is displayed.
> (Someone correct me if you know how to make that work.)
>
> If those complaints can be addressed, then I think there may
> be good reason to consider JAAS for Turbine security.
>
>
> > Renaming Group -> Project and
> > documenting the heck out of it would be the only changes I see as being
> > necessary in order to have a pretty functional security system for
> > webapps.
>
> Here are the other things I'd like included:
>
> 1) Inheritance of permissions.
> I would follow the JAAS model of 'permission.implies(...)'.
> That would satisfy the use case Jason brought up. If you
> want a wepapp without security limits, just set default
> permissions that grant every user 'AllPermissions'.
>
> 2) Support for groups of users in addition to user roles.
> Permissions could be assigned by role (e.g. Developer) and
> by group (e.g. Denver Office). Both are reasonable ways
> assign permissions. "Denver Office" isn't a "role".
>
It can be interesting for you that almost the same discussion topic
was raised nowadays on the avalon-dev list and (suprise)
there are many similarities. Search for McCay's "AAA Security"
mail (which has nice design in it) and the thread following it.
incze
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Eric Dobbs <er...@dobbse.net>.
On Monday, January 21, 2002, at 12:29 PM, Jon Scott Stevens wrote:
> API's like JAAS are great at securing access to source code. But, they
> really don't go beyond that without trying to munge them into something
> they
> aren't.
I think you have the wrong API.
There are complaints to be made about JAAS, but I don't think
that's one of them. The rest of Java Security is good at
limiting how much damage a given program can do to your
system by verifying its origins and other measures.
JAAS does go beyond that by extending Java Security to also
enforce control over what a program is allowed to do when it
is run by a particular user.
I have two complaints about JAAS in the context of Turbine.
I don't like the need to create an additional class to wrap
actions that are to be made secure. (Having written that
complaint I suppose it's really just a matter of having the
original objects implement the right interfaces.)
My second complaint is that I don't exactly see how to use
Subject.doAs() to control what gets displayed in the UI. It
is very clear how that fits into Turbine actions, but
doesn't seem to fit well in limiting what is displayed.
(Someone correct me if you know how to make that work.)
If those complaints can be addressed, then I think there may
be good reason to consider JAAS for Turbine security.
> Renaming Group -> Project and
> documenting the heck out of it would be the only changes I see as being
> necessary in order to have a pretty functional security system for
> webapps.
Here are the other things I'd like included:
1) Inheritance of permissions.
I would follow the JAAS model of 'permission.implies(...)'.
That would satisfy the use case Jason brought up. If you
want a wepapp without security limits, just set default
permissions that grant every user 'AllPermissions'.
2) Support for groups of users in addition to user roles.
Permissions could be assigned by role (e.g. Developer) and
by group (e.g. Denver Office). Both are reasonable ways
assign permissions. "Denver Office" isn't a "role".
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 1/21/02 4:22 AM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:
>> Dan Diephouse, could you summarize your ideas in a stand-alone posting?
>> We may be getting closer to a consensus, and it would be good to look
>> again at what you propose in full.
>
> Also, I think it would be good to keep in mind that it is probably
> a good idea that the design of the security system separates these
> concerns:
>
> 1. Authentication (log-in, log-out, password admin?)
> 2. Authorization (is this user allowed to do this)
> 3. Profiling (user preferences)
> 4. Administration (add, edit, remove users)
>
$0.00
What seems to be missing here and all of the conversations I have seen about
this up until this point, is 'What' we want to secure.
In other words, we know that we need to have some concept of 'users'...but
once you have that, what are you actually securing? I think that should be
what defines how the security system is built.
Yes, we realize, we need #1 and #2...but if you think about #2 further, you
need to realize that we need to also answer that question with joins against
other data such as: "is the user part of a project and if so, what roles
does the user have in that project"?
API's like JAAS are great at securing access to source code. But, they
really don't go beyond that without trying to munge them into something they
aren't.
Honestly, I don't even see why this conversation is happening. The Turbine
security system is pretty good as it stands. Renaming Group -> Project and
documenting the heck out of it would be the only changes I see as being
necessary in order to have a pretty functional security system for webapps.
$0.00.
-jon
--
Standard rules apply: Ask any questions, and you get the job. ;-)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> Dan Diephouse, could you summarize your ideas in a stand-alone posting?
> We may be getting closer to a consensus, and it would be good to look
> again at what you propose in full.
Also, I think it would be good to keep in mind that it is probably
a good idea that the design of the security system separates these
concerns:
1. Authentication (log-in, log-out, password admin?)
2. Authorization (is this user allowed to do this)
3. Profiling (user preferences)
4. Administration (add, edit, remove users)
--
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: Security Models (was: First ideas for new security model)
Posted by Dan Diephouse <di...@eastnode.com>.
Gonzalo A. Diethelm wrote:
>>I will also be more than willing to help on it. I am currently working
>>on my custom database implementation that I can plug in and use as a
>>test framework for the new security model.
>>
>
>As soon as Jason sends his writeup, and I have a set of interfaces
>and/or classes defined, I'll post them to the list for you to start
>giving us feedback.
>
>Would you be willing to port Turbine's current security service to
>whatever abomination we come up with? Or is this part of your custom
>DB implementation?
>
Sure, I will port the current security service to the new framework once
you give me a set of interfaces and classes. I may not get to it
tomorrow, but I can do it Thursday. Once I get the old security service
ported I will start work on my own. My app currently depends on the old
service. I figure its I nice middle transition - T2 security, to T3's
new security frame with old security service, then to the final custom
security framework.
- Dan Diephouse
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Models (was: First ideas for new security model)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/22/02 12:27 PM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:
>> I will also be more than willing to help on it. I am currently working
>> on my custom database implementation that I can plug in and use as a
>> test framework for the new security model.
>
> As soon as Jason sends his writeup, and I have a set of interfaces
> and/or classes defined, I'll post them to the list for you to start
> giving us feedback.
I'll have the write up in tonight sometime so you will have for tomorrow.
>
> Would you be willing to port Turbine's current security service to
> whatever abomination we come up with? Or is this part of your custom
> DB implementation?
>
>> - Dan Diephouse
>
--
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: Security Models (was: First ideas for new security model)
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> I will also be more than willing to help on it. I am currently working
> on my custom database implementation that I can plug in and use as a
> test framework for the new security model.
As soon as Jason sends his writeup, and I have a set of interfaces
and/or classes defined, I'll post them to the list for you to start
giving us feedback.
Would you be willing to port Turbine's current security service to
whatever abomination we come up with? Or is this part of your custom
DB implementation?
> - Dan Diephouse
--
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: Security Models (was: First ideas for new security model)
Posted by Dan Diephouse <di...@eastnode.com>.
Gonzalo A. Diethelm wrote:
>>>* It would be very good if we could standardize on the names used for
>>>different entities in the model: I have used User, Credentials
>>>(password), Permissions, etc., others have used different terms.
>>>Is there a standard we can follow?
>>>
>>Sounds good.
>>
>
>Cool! Eric Dobbs suggested using JAAS terminology, which sounds ok.
>
>>We'll get a little more feedback on the list, then I would like
>>to write up
>>a little strategy and then it's all yours if you want it! Once we
>>agree on a
>>strategy if you and others want to implement it that would be
>>great. Then I
>>can move on to something else.
>>
>
>Deal.
>
I will also be more than willing to help on it. I am currently working
on my custom database implementation that I can plug in and use as a
test framework for the new security model.
- Dan Diephouse
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Models (was: First ideas for new security model)
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> > * It would be very good if we could standardize on the names used for
> > different entities in the model: I have used User, Credentials
> > (password), Permissions, etc., others have used different terms.
> > Is there a standard we can follow?
>
> Sounds good.
Cool! Eric Dobbs suggested using JAAS terminology, which sounds ok.
> We'll get a little more feedback on the list, then I would like
> to write up
> a little strategy and then it's all yours if you want it! Once we
> agree on a
> strategy if you and others want to implement it that would be
> great. Then I
> can move on to something else.
Deal.
> 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: Security Models (was: First ideas for new security model)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/21/02 4:14 PM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:
>> By using this method, someone could use any security mechanism
>> they wanted.
>> They may be able to start simple if they want, even using a
>> simple text file
>> and they can evolve their security model as they need to or move
>> to a model
>> written by another. It might even be nice to allow many models to
>> run in the
>> same application so that other systems could be integrated or allow
>> selective migration to other models. Maybe the SecurityManger could
>> manage many security models and map them to a portion of your application
>> using a policy or security region.
>
> This would be great!
>
>> Right now with the pipeline in place and functioning it would be
>> possible to
>> implement this system, and I think I could get the skeleton in there this
>> week.
>
> That would also be great! Three things:
>
> * It would be very good if we could standardize on the names used for
> different entities in the model: I have used User, Credentials
> (password), Permissions, etc., others have used different terms.
> Is there a standard we can follow?
Sounds good.
>
> +1, and my offer to help you with anything you need. Let me know.
We'll get a little more feedback on the list, then I would like to write up
a little strategy and then it's all yours if you want it! Once we agree on a
strategy if you and others want to implement it that would be great. Then I
can move on to something else.
>> 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: Security Models (was: First ideas for new security model)
Posted by Eric Dobbs <er...@dobbse.net>.
On Monday, January 21, 2002, at 02:14 PM, Gonzalo A. Diethelm wrote:
> * It would be very good if we could standardize on the names used for
> different entities in the model: I have used User, Credentials
> (password), Permissions, etc., others have used different terms.
> Is there a standard we can follow?
+1. I would vote for adopting JAAS's names even if we choose not
to use JAAS. I don't think their names are especially clear, but
there already exists lots of documentation explaining what the
names mean. Consider it another form of reuse.
> * It would be very good if Turbine's default implementation of the
> security model did not require a DB; this way, we would be lowering
> the requirements for new users to install Turbine.
+0
> * I think it is necessary to port Turbine's current security
> implementation,
> along with a couple more implementations long overdue (LDAP!) to
> this new security model.
+1
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Models (was: First ideas for new security model)
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> By using this method, someone could use any security mechanism
> they wanted.
> They may be able to start simple if they want, even using a
> simple text file
> and they can evolve their security model as they need to or move
> to a model
> written by another. It might even be nice to allow many models to
> run in the
> same application so that other systems could be integrated or allow
> selective migration to other models. Maybe the SecurityManger could
> manage many security models and map them to a portion of your application
> using a policy or security region.
This would be great!
> Right now with the pipeline in place and functioning it would be
> possible to
> implement this system, and I think I could get the skeleton in there this
> week.
That would also be great! Three things:
* It would be very good if we could standardize on the names used for
different entities in the model: I have used User, Credentials
(password), Permissions, etc., others have used different terms.
Is there a standard we can follow?
* It would be very good if Turbine's default implementation of the
security model did not require a DB; this way, we would be lowering
the requirements for new users to install Turbine.
* I think it is necessary to port Turbine's current security implementation,
along with a couple more implementations long overdue (LDAP!) to
this new security model.
> I think that it is painfully evident that trying to extend
> or modify the security mechanism we have doesn't work very well.
> People are
> always asking questions, the nomenclature is confusing, and nobody has
> really volunteered to write any documentation because it's a bit
> overwhelming.
Absolutely!
> I am ready to put in the necessary code to allow this flexibility
> if people agree.
+1, and my offer to help you with anything you need. Let me know.
> 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>
Security Models (was: First ideas for new security model)
Posted by Jason van Zyl <jv...@zenplex.com>.
Hi,
I too would like to make an attempt to explain as I can give some concrete
examples of how various disparate security models can be made to work in
Turbine.
What Dan is describing is basically the assigning of a role of a component
by using an interface, it could also be considered a somewhat degenerate
form of the Decorator pattern where the Decorator itself houses all the
functionality: I believe Dan's examples were SecurityManager, Credentials,
and User.
Typically the decorator pattern deals with giving a component additional
functionality by having that component share an interface, say <operations>,
with a set of Decorators that also implement the <operations> interface. So
you're adding functionality to the component dynamically instead of using
inheritance. What we're talking about here with the security is the
interface being empty, the decorator doing everything, and placing these
decorators into turbine's system dynamically.
Aside: Here's a couple references on the Decorator pattern if you're
interested: pg. 175 Design Patterns, pg. 243 Patterns in Java vol. 1. And
the clearest example I think I've seen is Bruce Eckel's Thinking in
Patterns, can't remember where it is but it's free on the net.
By using this method, someone could use any security mechanism they wanted.
They may be able to start simple if they want, even using a simple text file
and they can evolve their security model as they need to or move to a model
written by another. It might even be nice to allow many models to run in the
same application so that other systems could be integrated or allow
selective migration to other models. Maybe the the SecurityManger could
manage many security models and map them to a portion of your application
using a a policy or security region.
A case in point that I can think of is Scarab and Helm (Dan and Jon can
correct me if I'm wrong). Right now they use different models but as
SourceCast evovles they may eventually want to use the same model, or Helm
might want to use Turbine. With the system outlined above, Helm could run
with its security model and Scarab could run with its own and they could
gradually be merged as desired because both models will work simultaneously.
I think all the models presented are valid, I'm not trying to sit on the
fence: I think that security models that organizations wish to implement are
not all going to fall under the same umbrella.
Right now with the pipeline in place and functioning it would be possible to
implement this system, and I think I could get the skeleton in there this
week.
The classic pipeline currently has a DefaultACLCreationValve where the ACL
based on the fulcrum security service is built up and placed into rundata.
So a valve could be made to accompany a security model implementation, you
specify this valve in an XML file and you can push whatever want into
rundata.
People using the push model can make a base Module that can provide
convenience methods for dealing with their particular security model, and
people using pull can trying using a site policy that I'm going to try and
whip up so that various security measures can be applied to regions of the
site. Again what I would like to do might be specific to my needs and need
not be forced on people not wishing to use it.
I'm hoping that a selection of models will be made available on the turbine
page. People can then choose what best suits there needs and either use the
provided models directly or extend them to fit particular requirements. So
we could have a ClassicSecurityModel, a RBACSecurityModel or whatever.
So if people agree with general sentitment than I believe within the week I
could have the mechanism in place that would allow people to experiment with
their own models. I think that it is painfully evident that trying to extend
or modify the security mechanism we have doesn't work very well. People are
always asking questions, the nomenclature is confusing, and nobody has
really volunteered to write any documentation because it's a bit
overwhelming.
I am ready to put in the necessary code to allow this flexibility if people
agree.
--
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: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
> Sent: Friday, January 18, 2002 23:53 PM
>
> On 1/18/02 8:11 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>
> > So far I like the use of the Decorator pattern that Dan D. suggests
> > below the best.
>
> I too believe this is the only real viable solution and the only one that
> I'm really in favour of.
Dan Diephouse, could you summarize your ideas in a stand-alone posting?
We may be getting closer to a consensus, and it would be good to look
again at what you propose in full. 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: First ideas for new security model
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/18/02 8:11 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> So far I like the use of the Decorator pattern that Dan D. suggests
> below the best.
I too believe this is the only real viable solution and the only one that
I'm really in favour of. As I've mentioned in previous posts: there's no
reason why we can't have some default implementations, but I don't think
there's any way we're going to come up with a security scheme that will
accommodate every scenerio. The Strategy pattern coupled with the Decorator
pattern is a great solutions.
The valves are pluggable now in Turbine 3.x and right now we have a
DefaultACLCreationValve (bad name, I know)
And this is where someone can push whatever they want into RunData, couple
that with a customized base Module with convenience methods for your
particular security setup and you're off to the races. Or a SitePolicy which
I'm going to try and whip up.
This setup is totally flexible and will allow us to build up a small
collection of implementations that can either be used in their entirety or
will be a great place for people start.
+1
> Dan Diephouse <di...@eastnode.com> writes:
>
>> Gonzalo A. Diethelm wrote:
>>
>>> These are all good points. That got me started thinking that perhaps
>>> we ARE trying to do too much with Turbine's security system. Perhaps
>>> we should just focus on answering the following questions:
>>>
>>> * Are these credentials valid for this user?
>>> * Change the credentials for this user.
>>> * Does this user have this capability?
>>>
>> Question: Don't those depend on the security scheme? Let me
>> explain. Consider "Are these credentials valid for this user?" The
>> only way to test that is to do something like
>> data.getACL().hasPermission(). But, if I don't have permissions in my
>> scheme, I'm screwed. Once again there is no standard way to change
>> credentials. I think the only thing Turbine needs to worry about is
>> the User object and associating it with the session.
>>
>> I suppose we need something like this.
>>
>> interface Credentials {}
>> interface User {
>> getName() // Or get Id, or something...
>> }
>> interface SecurityManager {}
>>
>> Then in the rundata object, instead of a getACL(), we have
>> getCredentials(). And on go on my merry way using my own security
>> scheme I specified in my TR.props,
>>
>> security.credentials.class=com.somewhere.project.security.CustomCredentials
>> security.manager.class=com.somewhere.project.security.CustomSecurityManager
>> security.user.class=com.somewhere.project.om.TorqueUser
>>
>> Notice there are no standard methods in the interface except getName()
>> in the User object. It could also have the getCredentials method if
>> you wanted. We could then distribute custom security implementations.
>> Are there other places where the security system is used that I'm not
>> thinking of? We really don't have much to worry about. Just the
>> RunData object. - Dan Diephouse
>
> --
> 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: First ideas for new security model
Posted by Daniel Rall <dl...@finemaltcoding.com>.
So far I like the use of the Decorator pattern that Dan D. suggests
below the best.
Dan Diephouse <di...@eastnode.com> writes:
> Gonzalo A. Diethelm wrote:
>
>>These are all good points. That got me started thinking that perhaps
>>we ARE trying to do too much with Turbine's security system. Perhaps
>>we should just focus on answering the following questions:
>>
>>* Are these credentials valid for this user?
>>* Change the credentials for this user.
>>* Does this user have this capability?
>>
> Question: Don't those depend on the security scheme? Let me
> explain. Consider "Are these credentials valid for this user?" The
> only way to test that is to do something like
> data.getACL().hasPermission(). But, if I don't have permissions in my
> scheme, I'm screwed. Once again there is no standard way to change
> credentials. I think the only thing Turbine needs to worry about is
> the User object and associating it with the session.
>
> I suppose we need something like this.
>
> interface Credentials {}
> interface User {
> getName() // Or get Id, or something...
> }
> interface SecurityManager {}
>
> Then in the rundata object, instead of a getACL(), we have
> getCredentials(). And on go on my merry way using my own security
> scheme I specified in my TR.props,
>
> security.credentials.class=com.somewhere.project.security.CustomCredentials
> security.manager.class=com.somewhere.project.security.CustomSecurityManager
> security.user.class=com.somewhere.project.om.TorqueUser
>
> Notice there are no standard methods in the interface except getName()
> in the User object. It could also have the getCredentials method if
> you wanted. We could then distribute custom security implementations.
> Are there other places where the security system is used that I'm not
> thinking of? We really don't have much to worry about. Just the
> RunData object. - Dan Diephouse
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> >* Are these credentials valid for this user?
> >* Change the credentials for this user.
> >* Does this user have this capability?
> >
> Question: Don't those depend on the security scheme? Let me explain.
> Consider "Are these credentials valid for this user?" The only way to
> test that is to do something like data.getACL().hasPermission(). But,
> if I don't have permissions in my scheme, I'm screwed. Once again there
> is no standard way to change credentials.
Just to clarify, I understand "user credentials" to mean "user name
and password", and "are these credentials valid for this user?" to
me means "is this usr/pwd valid?". Likewise, "change the credentials
for this user" means "change this user's password", and finally (and
MOST importantly), "does this user have this capability?" means "can
this user perform this operation?". Sorry for the confusion.
> I think the only thing Turbine needs to worry about is the User object
> and associating it with the session.
>
> I suppose we need something like this.
>
> interface Credentials {}
> interface User {
> getName() // Or get Id, or something...
> }
> interface SecurityManager {}
I would do something like this:
interface Credentials {}
interface Permission {}
interface PermissionSet {}
interface User {
getName(); // Or get Id, or something...
}
interface SecurityManager {
boolean validateUserCredentials(User user, Credentials credentials);
boolean changeUserCredentials(User user, Credentials credentials);
boolean userHasPermissions(User user, PermissionSet ps);
}
> Then in the rundata object, instead of a getACL(), we have
> getCredentials(). And on go on my merry way using my own security
> scheme I specified in my TR.props,
>
> security.credentials.class=com.somewhere.project.security.CustomCr
> edentials
> security.manager.class=com.somewhere.project.security.CustomSecuri
> tyManager
> security.user.class=com.somewhere.project.om.TorqueUser
>
> Notice there are no standard methods in the interface except getName()
> in the User object. It could also have the getCredentials method if you
> wanted. We could then distribute custom security implementations.
I believe what you are talking about is the same as what I said, modulo
the naming differences.
> Are there other places where the security system is used that I'm not
> thinking of? We really don't have much to worry about. Just the
> RunData object.
>
> - Dan Diephouse
Opinions, anyone else?
--
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: First ideas for new security model
Posted by Dan Diephouse <di...@eastnode.com>.
Gonzalo A. Diethelm wrote:
>These are all good points. That got me started thinking that perhaps
>we ARE trying to do too much with Turbine's security system. Perhaps
>we should just focus on answering the following questions:
>
>* Are these credentials valid for this user?
>* Change the credentials for this user.
>* Does this user have this capability?
>
Question: Don't those depend on the security scheme? Let me explain.
Consider "Are these credentials valid for this user?" The only way to
test that is to do something like data.getACL().hasPermission(). But,
if I don't have permissions in my scheme, I'm screwed. Once again there
is no standard way to change credentials.
I think the only thing Turbine needs to worry about is the User object
and associating it with the session.
I suppose we need something like this.
interface Credentials {}
interface User {
getName() // Or get Id, or something...
}
interface SecurityManager {}
Then in the rundata object, instead of a getACL(), we have
getCredentials(). And on go on my merry way using my own security
scheme I specified in my TR.props,
security.credentials.class=com.somewhere.project.security.CustomCredentials
security.manager.class=com.somewhere.project.security.CustomSecurityManager
security.user.class=com.somewhere.project.om.TorqueUser
Notice there are no standard methods in the interface except getName()
in the User object. It could also have the getCredentials method if you
wanted. We could then distribute custom security implementations.
Are there other places where the security system is used that I'm not
thinking of? We really don't have much to worry about. Just the
RunData object.
- Dan Diephouse
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> In my application we have been using T2 "groups" as what I think you are
> referring to as ProjectGroups, instead of "groups" as methods to
> restrict access per application. Under T2 I have deduced that this
> kind of scheme was the intent:
[snip of a long and interesting description of alternate security needs]
These are all good points. That got me started thinking that perhaps
we ARE trying to do too much with Turbine's security system. Perhaps
we should just focus on answering the following questions:
* Are these credentials valid for this user?
* Change the credentials for this user.
* Does this user have this capability?
Period! Maybe just provide those services in a pluggable way within
Turbine, and be done with it. This means leaving out of Turbine the
following concepts:
* The abstraction for how users and permissions are grouped (permissions
as part of roles, users belonging to groups, etc.), given that the
grouping can be very different for different apps.
* The methods to administer that grouping.
* Where and how the security information is stored (DB, LDAP, NT, etc.).
In favor of this position, let me remind you that JAAS is a role-based
abstraction. Well, what if you really DO NOT want or need roles at all
within your app? I LIKE roles, but I certainly think there might be apps
where role-based security is not the answer.
Just trying to be open minded (and playing devil's advocate),
--
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: First ideas for new security model
Posted by Dan Diephouse <di...@eastnode.com>.
Gonzalo A. Diethelm wrote:
>>I do prefer Module to Application, as Application
>>doesn't make me think "grouping".
>>
>>In Helm, we have both UserGroup and ProjectGroup entities
>>(ProjectGroups are probably near the equivalent of nested Scarab
>>Modules).
>>
>>Gonzalo, I haven't looked at the code yet, but from your description
>>don't see any interfaces for user or project groups (necessary for
>>finer grained permissioning). Is there any particular reason not to
>>include interfaces for these things (preferably ones which do not have
>>to be used if the user's application does not need'em)?
>>
>
>What I called "Application" is what a Group is today in Turbine 2,
>and I believe it would be akin to your UserGroup. I didn't think
>about adding ProjectGroup because there was no such thing in T2,
>and that was my starting point. What would be the exact semantics
>for ProjectGroup? Where does it fit in:
>
> A Role has Permissions.
> A User has Roles within a UserGroup.
> A Session may o may not have a User.
>
In my application we have been using T2 "groups" as what I think you are
referring to as ProjectGroups, instead of "groups" as methods to
restrict access per application. Under T2 I have deduced that this
kind of scheme was the intent:
Permissions - read, write, delete, update...etc.
Roles - Admin (has read,write,delete, update); User ( read, update) and
so on.
Group - Contact Database, Schedule, WebSite Mangement System.
So T2 was designed so there were roles that people can have under
specific applications or "groups." But, the ProjectGroup-ing arises
when we not only have different applications, but these applications
have different projects underneath them. For example say I have a
Project Managment application with several different projects in it.
Then we have:
Permissions - read, write, delete, update...etc.
Roles - Admin (has read,write,delete, update); User ( read, update) and
so on.
Group (or Application) - Project Management, Contact Database.
ProjectGroup - Marketing Campaign for XXX, TV Ads for ABC Inc.
Then different people can have different permissions in different
projects or no permissions in some projects. This making sense at all?
But the problems don't end here I believe. Because as has been said
many times over there is not a one size fits-all security mechanism...
Not all people are going to have projects, and not all people will want
an application grouping mechanism. Jetspeed is just one counter-example.
So I would just like to put my vote in for a pluggable architecture -
rather a hookable architecture. We could distribute a couple different
security implementations - ClassicTurbine, Portlet Security, Project
Security. All we do is put hooks in the RunData object to the security
system. So then if I'm running the ClassicTurbine SecuritySystem I do
(for lack of a better name I have chose SecuritySystem. Its equivalent
to the ACL Object in T2):
if (data.getSecuritySystem().hasPermission("read", "application"))...do
something
But, If I had my project security system setup I would do:
if (data.getSecuritySystem().hasPermission("read", "application",
"projectid"))...do something
Notice I am not promoting an interface that has a consistent way of
checking for permissions across all implementations. Each API is going
to be different for each system. I think the best way to go about it is
to put hooks in the existing code to reference whatever security system
we want. So while the security system would be "pluggable", you can't
readily replace one with the other unless you change your whole
codebase. This is because there are no defined methods to check for
permissions in the SecuritySystem interface. There is only a way to
retrieve the SecuritySystem object.
I am very willing to help on this project, especially since I have to do
something about it anyways for my application. :)
- Dan Diephouse
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Daniel Rall <dl...@finemaltcoding.com>.
I drew the User/UserGroup, Project/ProjectGroup relationship wrong --
it's many to many.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Gonzalo A. Diethelm" <go...@aditiva.com> writes:
>> In Helm, we have both UserGroup and ProjectGroup entities
>> (ProjectGroups are probably near the equivalent of nested Scarab
>> Modules).
>>
>> Gonzalo, I haven't looked at the code yet, but from your description
>> don't see any interfaces for user or project groups (necessary for
>> finer grained permissioning). Is there any particular reason not to
>> include interfaces for these things (preferably ones which do not have
>> to be used if the user's application does not need'em)?
>
> What I called "Application" is what a Group is today in Turbine 2,
> and I believe it would be akin to your UserGroup. I didn't think
> about adding ProjectGroup because there was no such thing in T2,
> and that was my starting point. What would be the exact semantics
> for ProjectGroup? Where does it fit in:
>
> A Role has Permissions.
> A User has Roles within a UserGroup.
> A Session may o may not have a User.
In T2, Group approximates a Helm Project. The schema looks like this:
UserGroup ProjectGroup
1 1
\ /
n n
User n n Project
n
Role
1
|
n
Permission
1
1 1
Action Resource
Where there are grouping of 3, there is a three way join (but I was
too lazy to draw it, heh).
The splitting of Permission into Action and Resource allows for VERY
fined grained control, but may be overkill.
Providing user and project/module/appliction/whatever-you-wann-call'em
groupings on top of the existing Turbine security scheme allows
arbitrarily complex permissioning schemes to be implemented easily.
Programmatically, UserGroup inherits from User and ProjectGroup from
Project -- this simplifies the schema.
Daniel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> > > One clarification: someone asked me what had happened to Groups.
> >> From past discussions here on the list, I remember the name Group
> >> was confusing to a lot of people. What I call Application in my
> >> proposal corresponds to the idea of a Group:
> >>
> >> A Role has Permissions.
> >> A User has Roles within an Application (System? Realm? FooBar?)
> >> A Session may o may not have a User.
> >>
> >> If anybody has better names for any of these things, speak up!
> >
> > I would prefer that a User has Roles within a Module.
> > Or if you need to be more explicit, perhaps WebModule.
>
> WebModule? Bleh.
Ditto.
> I do prefer Module to Application, as Application
> doesn't make me think "grouping".
>
> In Helm, we have both UserGroup and ProjectGroup entities
> (ProjectGroups are probably near the equivalent of nested Scarab
> Modules).
>
> Gonzalo, I haven't looked at the code yet, but from your description
> don't see any interfaces for user or project groups (necessary for
> finer grained permissioning). Is there any particular reason not to
> include interfaces for these things (preferably ones which do not have
> to be used if the user's application does not need'em)?
What I called "Application" is what a Group is today in Turbine 2,
and I believe it would be akin to your UserGroup. I didn't think
about adding ProjectGroup because there was no such thing in T2,
and that was my starting point. What would be the exact semantics
for ProjectGroup? Where does it fit in:
A Role has Permissions.
A User has Roles within a UserGroup.
A Session may o may not have a User.
> Daniel
--
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: First ideas for new security model
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Eric Dobbs <er...@dobbse.net> writes:
> On Tuesday, January 8, 2002, at 08:10 AM, Gonzalo A. Diethelm wrote:
> > One clarification: someone asked me what had happened to Groups.
>> From past discussions here on the list, I remember the name Group
>> was confusing to a lot of people. What I call Application in my
>> proposal corresponds to the idea of a Group:
>>
>> A Role has Permissions.
>> A User has Roles within an Application (System? Realm? FooBar?)
>> A Session may o may not have a User.
>>
>> If anybody has better names for any of these things, speak up!
>
> I would prefer that a User has Roles within a Module.
> Or if you need to be more explicit, perhaps WebModule.
WebModule? Bleh. I do prefer Module to Application, as Application
doesn't make me think "grouping".
In Helm, we have both UserGroup and ProjectGroup entities
(ProjectGroups are probably near the equivalent of nested Scarab
Modules).
Gonzalo, I haven't looked at the code yet, but from your description
don't see any interfaces for user or project groups (necessary for
finer grained permissioning). Is there any particular reason not to
include interfaces for these things (preferably ones which do not have
to be used if the user's application does not need'em)?
Daniel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Eric Dobbs <er...@dobbse.net>.
On Tuesday, January 8, 2002, at 08:10 AM, Gonzalo A. Diethelm wrote:
> One clarification: someone asked me what had happened to Groups.
> From past discussions here on the list, I remember the name Group
> was confusing to a lot of people. What I call Application in my
> proposal corresponds to the idea of a Group:
>
> A Role has Permissions.
> A User has Roles within an Application (System? Realm? FooBar?)
> A Session may o may not have a User.
>
> If anybody has better names for any of these things, speak up!
I would prefer that a User has Roles within a Module.
Or if you need to be more explicit, perhaps WebModule.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> This is great stuff.
Thanks!
> Please, if you start working on the DB backend,
> use the Torque generated peers.
Absolutely, eat our own food!
One clarification: someone asked me what had happened to Groups.
>>From past discussions here on the list, I remember the name Group
was confusing to a lot of people. What I call Application in my
proposal corresponds to the idea of a Group:
A Role has Permissions.
A User has Roles within an Application (System? Realm? FooBar?)
A Session may o may not have a User.
If anybody has better names for any of these things, speak up!
> Henning
--
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: Minor problems:
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Gonzalo A. Diethelm" <go...@aditiva.com> writes:
> Testsuite: org.apache.turbine.pipeline.TestPipelineMapper
> Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.62 sec
> ------------- Standard Output ---------------
> Warning: Error occurred using JAXP to load a SAXParser. Will use Aelfred
> instead
> setName(TurbineClassicPipeline)
> ------------- ---------------- ---------------
> ------------- Standard Error -----------------
> java.io.FileNotFoundException: /./default-action-valve.xml
> (The system cannot find the file specified)
> at java.io.FileInputStream.open(Native Method)
Gonzalo, I've updated the build and the tests (you'll need to rebuild
jakarta-turbine-stratum, I've added classpath/JAR loading of XML data
files to it). Please let us know if tonight changes resolves this
problem.
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Minor problems:
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> 1. Can't compile Fulcrum:
Daniel helped me out with this, and now it's working (it needed to have
a cvs checkout of torque side by side).
> 2. One of the tests for Turbine gives an error:
>
> Testcase: testPipelineMapping took 0 sec
> Caused an ERROR
> org/dom4j/Branch
> java.lang.NoClassDefFoundError: org/dom4j/Branch
> at
> org.apache.turbine.pipeline.TestPipelineMapper.testPipelineMapping
> (TestPipelineMapper.java:127)
> at java.lang.reflect.Method.invoke(Native Method)
> ...
This was because I had not defined the dom4j.jar property. With
that in place, now I get the following messages:
Testsuite: org.apache.turbine.pipeline.TestPipelineMapper
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.62 sec
------------- Standard Output ---------------
Warning: Error occurred using JAXP to load a SAXParser. Will use Aelfred
instead
setName(TurbineClassicPipeline)
------------- ---------------- ---------------
------------- Standard Error -----------------
java.io.FileNotFoundException: /./default-action-valve.xml
(The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Minor problems:
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
I have a fresh cvs checkout of Turbine-3 and Fulcrum. Problems:
1. Can't compile Fulcrum:
BUILD FAILED
D:\gonzo\head\jakarta-turbine-fulcrum\build-om.xml:68:
Resource not found. For more information consult the velocity log,
or invoke ant with the -debug flag.
and velocity.log says:
ResourceManager : unable to find resource 'om/Control.vm'
in any resource loader.
2. One of the tests for Turbine gives an error:
Testcase: testPipelineMapping took 0 sec
Caused an ERROR
org/dom4j/Branch
java.lang.NoClassDefFoundError: org/dom4j/Branch
at org.apache.turbine.pipeline.TestPipelineMapper.testPipelineMapping
(TestPipelineMapper.java:127)
at java.lang.reflect.Method.invoke(Native Method)
...
Thanks for any help,
--
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: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
We are having an interesting discussion on IRC regarding security.
share.whichever.com, #turbine.
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
> -----Original Message-----
> From: henning@forge.intermeta.de [mailto:henning@forge.intermeta.de]On
> Behalf Of Henning P. Schmiedehausen
> Sent: Tuesday, January 08, 2002 10:52 AM
> To: turbine-dev@jakarta.apache.org
> Subject: Re: First ideas for new security model
>
>
> "Gonzalo A. Diethelm" <go...@aditiva.com> writes:
>
> >I'm attaching my first ideas on the new security model. The archive
> >is supposed to be expanded under org.apache.fulcrum.security.
>
> >[Jason, I'm sending this to your personal address in case the list
> >doesn't like attachments].
>
> This is great stuff. Please, if you start working on the DB backend,
> use the Torque generated peers.
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
> D-91054 Buckenhof Fax.: 09131 / 50654-20
>
> --
> 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: First ideas for new security model
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Gonzalo A. Diethelm" <go...@aditiva.com> writes:
>I'm attaching my first ideas on the new security model. The archive
>is supposed to be expanded under org.apache.fulcrum.security.
>[Jason, I'm sending this to your personal address in case the list
>doesn't like attachments].
This is great stuff. Please, if you start working on the DB backend,
use the Torque generated peers.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Santiago Gala <sg...@hisitech.com>.
Gonzalo A. Diethelm wrote:
(...)
>>>I'm sure this is the case. In fact, I think we should seriously
>>>examine JAAS to see if we would not be better off simply dropping
>>>Turbine's security model and adopting JAAS.
>>>
>>+1 on dropping the current Turbine security model for 3.0 and above
>>
>
>I'm not sure yet this is the wisest move; I think we have to EXAMINE
>JAAS and come up with a decision.
>
I agree.
>
>>remember JAAS is =>JDK 1.3 only.
>>but +1 on dropping support for JDK < 1.3 for the new security framework,
>>people that want to use the new security framework will just have
>>to upgrade
>>to JDK 1.3, we need to move on.
>>
>
>I suppose setting 1.3 as a minimum would be Ok.
>
>>Besides people need to use a policy file for security settings.
>>And I've been unable to find out how the heck I can dynamically add users
>>without restarting the application, it should be possible though.
>>
>
>I think just this one aspect would absolutely rule JAAS out. This
>is exactly the reason why Turbine did not use container-based security.
>
>>Take a look at how they do it over in jboss land
>>http://www.jboss.org/online-manual/HTML/ch09s08.html, not much doco, but
>>download their source code, there was also a good JAAS framework
>>in Enhydra,
>>if you can dig up the enterprise source code somewhere.
>>
>
>It looks interesting, it seems they defined a couple of generic
>classes/interfaces, and their reference implementation uses JAAS
>but they are NOT tied to JAAS; in fact, they say:
>
> These interfaces can be used to integrate any
> security infrastructure.
>
But, ... I think they use java.security.Permission, and I'm sure they
use java.security.Principal
I mean thare are two issues here:
- Our SecurityManager is a standard java2 SecurityManager, and then we
map our classes (User->Roles->Principal) any way we want, but we have
the java.security.Principal and java.security.Permission implementation
built upon java2 APIs (This is jdk1.2), or we implement our own security
stuff from the root.
- We move to the javax.security.auth (JAAS) API for authentication, or
we have our own authentication.
While the second bullet is more controversial, I think that the first
one is a must. If we don't use Principal and Permission from the java
API we will not interoperate with J2EE environments.
>
>>I tried once to figure out a new security model for Turbine, but I came to
>>realise that one couldn't make one that could satisfy everybody: easy to
>>use/speed/flexibility/based on standards.
>>
>
>This may be the case; at least, we have to give it a try!
>
I think that holding to the standard classes for Permission and
Principal will not have speed impacts (unless we start a
SecurityManager). We could have alternative AccessControl checks in the
security service using those classes for speedier/smaller/no checks.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Santiago Gala <sg...@hisitech.com>.
Kasper Nielsen wrote:
>what about a joint venture with commons/avalon/other apache projects im sure
>people have lots of inputs/ideas for a security framework, I see no reason
>why it should be coupled to fulcrum.
>
In fact, I have spent some time grepping Tomcat-4.1 cvs sources for
"doAs", "SubjectDomain", ... looking for the security implementation there.
This came because I saw the light tonight ;) in that THE WAY of having a
security implementation would be to have tomcat call the servlet service
call with a Subject.doAs( currentSubject, requestAction ), (or
doAsPrivileged, to also enforce code base permissions) so that
declarative security would hold independent of the framework, as long as
it is authenticated by the servlet container or a default run-as
anonymous user exists in the container.
The Servlet Spec specifies the run-as element to do this kind of work,
when no authenticated user exists. Earlier (SRV 12.7) it says:
A security identity, or principal, must always be provided for use in
a call to an
enterprise bean. The default mode in calls to enterprise beans from
web applications
is for the security identity of a web user to be propagated to the
EJBTM container.
As far as I see it, tomcat should use doAs to enforce this. I wonder
what tomcat people thinks about this, so I cc: Craig to see... ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Kasper Nielsen <ne...@kav.dk>.
what about a joint venture with commons/avalon/other apache projects im sure
people have lots of inputs/ideas for a security framework, I see no reason
why it should be coupled to fulcrum.
- Kasper
----- Original Message -----
From: "Gonzalo A. Diethelm" <go...@aditiva.com>
To: "Turbine Developers List" <tu...@jakarta.apache.org>
Sent: Wednesday, January 09, 2002 9:04 PM
Subject: RE: First ideas for new security model
> > I don't get what the session interface is for?
>
> Session management: a session holds zero or one (authenticated) user.
>
> > > I'm not familiar with this "implies" concept.
> > an example
> >
> > HaveRootPermission.implies -> HaveReadWriteAccessPermission implies ->
> > HaveReadPermission implies ....
>
> Ok, a hierarchy of permissions. Of course, this concept could also
> be applied to roles, right?
>
> > > I'm sure this is the case. In fact, I think we should seriously
> > > examine JAAS to see if we would not be better off simply dropping
> > > Turbine's security model and adopting JAAS.
> >
> > +1 on dropping the current Turbine security model for 3.0 and above
>
> I'm not sure yet this is the wisest move; I think we have to EXAMINE
> JAAS and come up with a decision.
>
> > remember JAAS is =>JDK 1.3 only.
> > but +1 on dropping support for JDK < 1.3 for the new security framework,
> > people that want to use the new security framework will just have
> > to upgrade
> > to JDK 1.3, we need to move on.
>
> I suppose setting 1.3 as a minimum would be Ok.
>
> > Besides people need to use a policy file for security settings.
> > And I've been unable to find out how the heck I can dynamically add
users
> > without restarting the application, it should be possible though.
>
> I think just this one aspect would absolutely rule JAAS out. This
> is exactly the reason why Turbine did not use container-based security.
>
> > Take a look at how they do it over in jboss land
> > http://www.jboss.org/online-manual/HTML/ch09s08.html, not much doco, but
> > download their source code, there was also a good JAAS framework
> > in Enhydra,
> > if you can dig up the enterprise source code somewhere.
>
> It looks interesting, it seems they defined a couple of generic
> classes/interfaces, and their reference implementation uses JAAS
> but they are NOT tied to JAAS; in fact, they say:
>
> These interfaces can be used to integrate any
> security infrastructure.
>
> > I tried once to figure out a new security model for Turbine, but I came
to
> > realise that one couldn't make one that could satisfy everybody: easy to
> > use/speed/flexibility/based on standards.
>
> This may be the case; at least, we have to give it a try!
>
> > - Kasper
>
>
> --
> 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: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> I don't get what the session interface is for?
Session management: a session holds zero or one (authenticated) user.
> > I'm not familiar with this "implies" concept.
> an example
>
> HaveRootPermission.implies -> HaveReadWriteAccessPermission implies ->
> HaveReadPermission implies ....
Ok, a hierarchy of permissions. Of course, this concept could also
be applied to roles, right?
> > I'm sure this is the case. In fact, I think we should seriously
> > examine JAAS to see if we would not be better off simply dropping
> > Turbine's security model and adopting JAAS.
>
> +1 on dropping the current Turbine security model for 3.0 and above
I'm not sure yet this is the wisest move; I think we have to EXAMINE
JAAS and come up with a decision.
> remember JAAS is =>JDK 1.3 only.
> but +1 on dropping support for JDK < 1.3 for the new security framework,
> people that want to use the new security framework will just have
> to upgrade
> to JDK 1.3, we need to move on.
I suppose setting 1.3 as a minimum would be Ok.
> Besides people need to use a policy file for security settings.
> And I've been unable to find out how the heck I can dynamically add users
> without restarting the application, it should be possible though.
I think just this one aspect would absolutely rule JAAS out. This
is exactly the reason why Turbine did not use container-based security.
> Take a look at how they do it over in jboss land
> http://www.jboss.org/online-manual/HTML/ch09s08.html, not much doco, but
> download their source code, there was also a good JAAS framework
> in Enhydra,
> if you can dig up the enterprise source code somewhere.
It looks interesting, it seems they defined a couple of generic
classes/interfaces, and their reference implementation uses JAAS
but they are NOT tied to JAAS; in fact, they say:
These interfaces can be used to integrate any
security infrastructure.
> I tried once to figure out a new security model for Turbine, but I came to
> realise that one couldn't make one that could satisfy everybody: easy to
> use/speed/flexibility/based on standards.
This may be the case; at least, we have to give it a try!
> - Kasper
--
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: First ideas for new security model
Posted by Kasper Nielsen <ne...@kav.dk>.
> My idea is that you should be able to extend any of the entities
> (Permission, Role, User, Application, Session) and factories, and
> then define your appropriate classes in the props file. Of course,
> for this to work Turbine/Fulcrum should ONLY manipulate these objects
> through their interfaces.
I don't get what the session interface is for?
>
> I'm not familiar with this "implies" concept.
an example
HaveRootPermission.implies -> HaveReadWriteAccessPermission implies ->
HaveReadPermission implies ....
> > - Someone (SecurityManager?) checks the Permissions against the current
> > Principal (User,Session?) in the running thread (and/or codebase) and
> > returns silently or throws a SecurityException
>
> Yes.
>
> > OTOH, I think there are very deep issues difficult to track.
>
> I'm sure this is the case. In fact, I think we should seriously
> examine JAAS to see if we would not be better off simply dropping
> Turbine's security model and adopting JAAS.
+1 on dropping the current Turbine security model for 3.0 and above
> This is a very good and strong point. Maybe we could use a point by point
> comparison of JAAS and Turbine's current security model, to see how they
> fare in terms of FUNCTIONALITY alone. Even more: is it possible to
> reimplement
> Turbine's current security model using JAAS underneath?
remember JAAS is =>JDK 1.3 only.
but +1 on dropping support for JDK < 1.3 for the new security framework,
people that want to use the new security framework will just have to upgrade
to JDK 1.3, we need to move on.
One problem I see with JAAS is that we need to use a security manager, which
I think will slow down the execution of Turbine. I know that it takes at
least twice the time to start Tomcat up if you use a security manager.
Besides people need to use a policy file for security settings.
And I've been unable to find out how the heck I can dynamically add users
without restarting the application, it should be possible though.
Take a look at how they do it over in jboss land
http://www.jboss.org/online-manual/HTML/ch09s08.html, not much doco, but
download their source code, there was also a good JAAS framework in Enhydra,
if you can dig up the enterprise source code somewhere.
I tried once to figure out a new security model for Turbine, but I came to
realise that one couldn't make one that could satisfy everybody: easy to
use/speed/flexibility/based on standards.
- Kasper
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Santiago Gala <sg...@hisitech.com>.
Gonzalo A. Diethelm wrote:
>Santiago, thanks for your comments.
>
We are anxious to help see a Security Manager that we can use in
Jetspeed. I will participate in the design and development effort, and I
think we can find more volunteers coming from the Jetspeed community.
>
>
>>With the current turbine-2 model, we would be forced to use things like
>>Permission("PSML-/user/admin-read"), or
>>Permission("Portlet-Slashdot-edit"). Coding that much semantics in
>>Strings sucks. Maybe there are alternative solutions, but I can't see
>>them. Please, enlighten me ;)
>>
>
>I thought of doing something like this:
>
>public class JetspeedPermission
> extends FulcrumPermission // or implements Permission
>{
> private String portlet_;
> private String mode_;
>
> Permission(String id)
> {
> super(id);
> portlet_ = getPortlet(id);
> mode_ = getMode(id);
> }
>
> Permission(String portlet, String mode)
> {
> super(makeId(portlet, mode)); // build a unique id, pass it up
> portlet_ = portlet;
> mode_ = mode;
> }
> // ...
>}
>
It looks feasible. I think we could work with this kind of setup.
>
>>It looks like your proposal allows for things like:
>>
>>- specifying our factory.
>>
>
>... and your entities.
>
Yes, the next point implied (I was thinking about) returning a new
PortletPermission("Slashdot","read")
>
>>- calling our factory for new Permission("Portlet", "Slashdot", "read")
>>- Our factory retrieves the id automagically, instantiates the
>>Permission, and returns it.
>>
>
>Yes, something like this.
>
>>(I think the implies() or similar method is missing to have semantics
>>such as Permission("Portlet", "RSS", "read") implies
>>Permission("Portlet", "Slashdot", "read"), or Permission("Portlet",
>>"RSS", "*") implies Permission("Portlet", "RSS", "read").
>>
>
>I'm not familiar with this "implies" concept.
>
It is handy for things like specifying that a user has
FilePermission("/usr/local/*", "read" ), and then having checks on
FilePermission( aFile.toString(), "read" ). If aFile is beneath
/usr/local, the check will succeed, if not, it will fail, as the manager
will check if any of the User permissions imply the one checked. Also,
AllPermission.implies( aPermission ) is always true.
They use it heavily in java2, because it is not reasonable having to
specify a different permission, for instance, for each tcp port. So they
have SocketPermission("1024-*", "listen") or something similar. When you
ask for new ServerSocket(1056), the implementation builds a
SocketPermission( "1056", "listen" ) and asks the SecurityManager. The
SecurityManager looks at the PermissionCollection in the codebase
(java2) or codebase/Principal (jaas), and sees if the existing
permissions imply the asked one. I'm quoting from memory, so forgive if
the description is not precise. If you have java.security.AllPermission,
then you don't need any other Permission, as implies returns true. ;)
>
>>- Someone (SecurityManager?) checks the Permissions against the current
>>Principal (User,Session?) in the running thread (and/or codebase) and
>>returns silently or throws a SecurityException
>>
>
>Yes.
>
Here, it would be important to know if turbine wants to have permissions
associated only with Users (Principal or Subject in jaas jargon), or
also with code bases (elements of the modules path, for instance). The
codebase concept could maybe be extended to velocity templates paths,
but I'm not sure how. This could tackle the velocity version of the
killer jsp I quote further down.
>
>>OTOH, I think there are very deep issues difficult to track.
>>
>
>I'm sure this is the case. In fact, I think we should seriously
>examine JAAS to see if we would not be better off simply dropping
>Turbine's security model and adopting JAAS.
>
Even then, there would be substantial job. For instance, to specify that
only users with the role admin can see a given navigation, a check
should be placed somewhere that would retrieve the permission associated
with the required navigation from the policy and compare it to the
actual permissions for the current User.
If you want to restrict permissions to a service, a check should be
placed everytime the service is requested. And so on and so forth.
>
>>For instance, I think that java2 java.security.Permission is a class
>>
>instead
>
>>of an interface so that getName() implementation can be made final, and
>>malicious code cannot do things like creating a new Permission, and
>>changing the getName to return the name of a different permission...
>>
>
>I didn't even consider this kind of scenario...
>
>>I think that having Permission interfaces can be dangerous in itself. This
>>is one of the reasons why I push for the use of java.security.* classes.
>>I don't think we have the resources to audit the design as they have
>>already done. A lot of deep issues can be laying around, waiting to byte
>>us. I think it is best, in terms of design economy, to trust the java2
>>security model instead of reinventing a particularly tricky wheel.
>>
>
>This is a very good and strong point. Maybe we could use a point by point
>comparison of JAAS and Turbine's current security model, to see how they
>fare in terms of FUNCTIONALITY alone. Even more: is it possible to
>reimplement
>Turbine's current security model using JAAS underneath?
>
>>Elaborating on the Permission interface issues, I could create a
>>Permission to be checked, and change the id to a different Permission
>>after it has been stored in a PermissionSet, or something similar...
>>
>
>Again, I didn't even explore these possibilities. Question: do we really
>care about these kinds of scenarios, taking into consideration that the
>scope of Turbine if for server-based apps? (honest question).
>
Yes, it is a good question. Short term, I think we can skip these
issues. In the long term, and given that in the web services and portlet
scenario a vendor can supply portlets or servlets to get executed in
your container, it should be taken into account. Maybe not so much for
turbine, but clearly for Jetspeed. I don't know about other apps using
turbine.
Let's use tomcat as an example. Under tomcat 3.1 and beneath, all
servlets and jsp pages have the same permissions as tomcat. I think
beginning in tomcat-3.2.X, you can run it with "-security", and then a
SecurityManager will be started, and a policy file will be used to limit
permissions on different servlets, jsp pages or directories. In
tomcat-4 the policies are better polished. I bet that in the future,
running tomcat with security manager will be the default.
If a ISP uses a servlet container to host servlets provided by different
customers, security starts being important. As the example in tomcat-4
docs says, a jsp page like <% System.exit(); %> can be really harmful.
If someone can put it under your jsp directory, your server is done.
As I said, in a pure turbine application you usually have control over
the whole code base. This is no longer true as/if Jetspeed evolves, and
the portlet application file "market" develops. You could buy/download a
calendaring portlet app from a third party vendor.
>
>My ideas do not go beyond an initial architecture. Your comments are
>more than welcome; hopefully we will all come up with a decision that
>will help all the Turbine/Fulcrum-based projects.
>
I'm pointing to several issues. The issue about "quality" of the APIs is
rather long term, but I'm trying to make different points:
- It is difficult to write a strong security framework. If it was
possible to reuse one, it is better. I'm not sure, though, of the
performance or other issues of the java2 security model.
- If our Security framework is a shallow layer on top of JAXP/java 2
security, other people maintain (better or worse) most of the code. So
we can concentrate on other important work, like where are security
checks to be placed (tricky for Jetspeed), which granularity of
permissions do we need, etc.
- The Servlet API already has some security elements, and tomcat has
already a SecurityManager in place.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
Santiago, thanks for your comments.
> It would be interesting if the model would allow for applications
> subclassing Permissions. For instance, in Jetspeed we would possibly
> need PortletPermission(String portlet, String mode), PSMLPermission(
> String resource, String mode) or similar classes. These should be
> propagated cleanly by turbine. We could use a similar model to
> java.security, having a implies(Permission) method to test for equality.
My idea is that you should be able to extend any of the entities
(Permission, Role, User, Application, Session) and factories, and
then define your appropriate classes in the props file. Of course,
for this to work Turbine/Fulcrum should ONLY manipulate these objects
through their interfaces.
> With the current turbine-2 model, we would be forced to use things like
> Permission("PSML-/user/admin-read"), or
> Permission("Portlet-Slashdot-edit"). Coding that much semantics in
> Strings sucks. Maybe there are alternative solutions, but I can't see
> them. Please, enlighten me ;)
I thought of doing something like this:
public class JetspeedPermission
extends FulcrumPermission // or implements Permission
{
private String portlet_;
private String mode_;
Permission(String id)
{
super(id);
portlet_ = getPortlet(id);
mode_ = getMode(id);
}
Permission(String portlet, String mode)
{
super(makeId(portlet, mode)); // build a unique id, pass it up
portlet_ = portlet;
mode_ = mode;
}
// ...
}
> It looks like your proposal allows for things like:
>
> - specifying our factory.
... and your entities.
> - calling our factory for new Permission("Portlet", "Slashdot", "read")
> - Our factory retrieves the id automagically, instantiates the
> Permission, and returns it.
Yes, something like this.
> (I think the implies() or similar method is missing to have semantics
> such as Permission("Portlet", "RSS", "read") implies
> Permission("Portlet", "Slashdot", "read"), or Permission("Portlet",
> "RSS", "*") implies Permission("Portlet", "RSS", "read").
I'm not familiar with this "implies" concept.
> - Someone (SecurityManager?) checks the Permissions against the current
> Principal (User,Session?) in the running thread (and/or codebase) and
> returns silently or throws a SecurityException
Yes.
> OTOH, I think there are very deep issues difficult to track.
I'm sure this is the case. In fact, I think we should seriously
examine JAAS to see if we would not be better off simply dropping
Turbine's security model and adopting JAAS.
> For instance, I think that java2 java.security.Permission is a class
instead
> of an interface so that getName() implementation can be made final, and
> malicious code cannot do things like creating a new Permission, and
> changing the getName to return the name of a different permission...
I didn't even consider this kind of scenario...
> I think that having Permission interfaces can be dangerous in itself. This
> is one of the reasons why I push for the use of java.security.* classes.
> I don't think we have the resources to audit the design as they have
> already done. A lot of deep issues can be laying around, waiting to byte
> us. I think it is best, in terms of design economy, to trust the java2
> security model instead of reinventing a particularly tricky wheel.
This is a very good and strong point. Maybe we could use a point by point
comparison of JAAS and Turbine's current security model, to see how they
fare in terms of FUNCTIONALITY alone. Even more: is it possible to
reimplement
Turbine's current security model using JAAS underneath?
> Elaborating on the Permission interface issues, I could create a
> Permission to be checked, and change the id to a different Permission
> after it has been stored in a PermissionSet, or something similar...
Again, I didn't even explore these possibilities. Question: do we really
care about these kinds of scenarios, taking into consideration that the
scope of Turbine if for server-based apps? (honest question).
> Thus having non-inmutable Permissions implies that they should not be
> cached anywhere in the system. The same goes on with User (I could
> impersonate any user by calling setId() on the current User...)
>
> These are random thougths. I hope you will tell me if I am way off base,
> if you think about different use cases, or if I have missed
> something here.
My ideas do not go beyond an initial architecture. Your comments are
more than welcome; hopefully we will all come up with a decision that
will help all the Turbine/Fulcrum-based projects.
> Regards, Santiago
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: First ideas for new security model
Posted by Santiago Gala <sg...@hisitech.com>.
Gonzalo A. Diethelm wrote:
>I'm attaching my first ideas on the new security model. The archive
>is supposed to be expanded under org.apache.fulcrum.security.
>
>[Jason, I'm sending this to your personal address in case the list
>doesn't like attachments].
>
>These are my ideas up to now:
>
>* Five interfaces Permission, Role, User, Application and Session
> (package entity). These have no data except for a unique String
> id, and each has some basic operations related to security queries.
> There are no administrative functions at this level.
>
It would be interesting if the model would allow for applications
subclassing Permissions. For instance, in Jetspeed we would possibly
need PortletPermission(String portlet, String mode), PSMLPermission(
String resource, String mode) or similar classes. These should be
propagated cleanly by turbine. We could use a similar model to
java.security, having a implies(Permission) method to test for equality.
With the current turbine-2 model, we would be forced to use things like
Permission("PSML-/user/admin-read"), or
Permission("Portlet-Slashdot-edit"). Coding that much semantics in
Strings sucks. Maybe there are alternative solutions, but I can't see
them. Please, enlighten me ;)
It looks like your proposal allows for things like:
- specifying our factory.
- calling our factory for new Permission("Portlet", "Slashdot", "read")
- Our factory retrieves the id automagically, instantiates the
Permission, and returns it.
(I think the implies() or similar method is missing to have semantics
such as Permission("Portlet", "RSS", "read") implies
Permission("Portlet", "Slashdot", "read"), or Permission("Portlet",
"RSS", "*") implies Permission("Portlet", "RSS", "read").
- Someone (SecurityManager?) checks the Permissions against the current
Principal (User,Session?) in the running thread (and/or codebase) and
returns silently or throws a SecurityException
OTOH, I think there are very deep issues difficult to track. For
instance, I think that java2 java.security.Permission is a class instead
of an interface so that getName() implementation can be made final, and
malicious code cannot do things like creating a new Permission, and
changing the getName to return the name of a different permission... I
think that having Permission interfaces can be dangerous in itself. This
is one of the reasons why I push for the use of java.security.* classes.
I don't think we have the resources to audit the design as they have
already done. A lot of deep issues can be laying around, waiting to byte
us. I think it is best, in terms of design economy, to trust the java2
security model instead of reinventing a particularly tricky wheel.
Elaborating on the Permission interface issues, I could create a
Permission to be checked, and change the id to a different Permission
after it has been stored in a PermissionSet, or something similar...
Thus having non-inmutable Permissions implies that they should not be
cached anywhere in the system. The same goes on with User (I could
impersonate any user by calling setId() on the current User...)
These are random thougths. I hope you will tell me if I am way off base,
if you think about different use cases, or if I have missed something here.
Regards, Santiago
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: First ideas for new security model
Posted by Kasper Nielsen <ne...@kav.dk>.
I think we will run into the same problems again.
People want to do something/integrate with something that just isn't
possible/easy to do with the interfaces we have made.
Like integrating with JAAS (which we should do anyway), windows NT
domains/.... what ever.
So how about generating all the security classes/interfaces/services using
the TDK.
So if all people needed was a security model with users (no roles, no
domains, nothing else) they would set a variable in newapp.properties
SecurityModel=UserOnly
and when compiling your application for the first time, all the needed
classes/services/sql scripts would be created.
(you would get a )
com.somedomain.appname.security.SecurityService
com.somedomain.appname.security.User
com.somedomain.appname.security.DBUser
.....................
There is really no need to have 4 tables in your database if all �ou need is
one.
By setting it
SecurityModel=UserRole
you would get an additional role table and the Security service would have
additional methods, and so on.
you would get a hold of a user object this way (could be put in a static
method)
SecurityService service=(SecurityService)
someregistry.lookup("securityservice");
User user=service.getUser(rundata); or service.getUser(some HttpSession)
this way it could be easily used in other servlet applications.
Even if we don't use the 'user' generated security service, I would prefer
if turbine wasn't directly coupled to the security implementation like it is
now (some rundata).getUser(), but forcing people to look up the service.
- Kasper
----- Original Message -----
From: "Gonzalo A. Diethelm" <go...@aditiva.com>
To: "Turbine Developers List" <tu...@jakarta.apache.org>
Sent: Tuesday, January 08, 2002 1:52 PM
Subject: First ideas for new security model
> I'm attaching my first ideas on the new security model. The archive
> is supposed to be expanded under org.apache.fulcrum.security.
>
> [Jason, I'm sending this to your personal address in case the list
> doesn't like attachments].
>
> These are my ideas up to now:
>
> * Five interfaces Permission, Role, User, Application and Session
> (package entity). These have no data except for a unique String
> id, and each has some basic operations related to security queries.
> There are no administrative functions at this level.
>
> * Five classes Fulcrum{Permission,Role,User,Application,Session}
> (package entity.fulcrum), that have a basic implementation of the
> above interfaces.
>
> * Five interfaces {Permission,Role,User,Application,Session}Factory
> (package factory). These define the operations to load, save and
> remove their respective objects from a back-end.
>
> * Five classes Fulcrum{Permission,Role,User,Application,Session}Factory
> (package factory.fulcrum), that have a basic (mostly comments)
> implementation of the above interfaces.
>
> * The idea is that Fulcrum code uses ONLY the Permission, Role, User,
> Application and Session interfaces, NEVER referring to a concrete
> extension of them.
>
> * I include a sample properties file where the programmer will specify
> what concrete entity and factory classes she whishes to use.
>
> * There is a SecurityManager class, a facade for all the factory classes
> that reads the configuration file and uses the configured factories to
> manipulate security objects.
>
> * A programmer could create new classes implementing the basic interfaces
> if she wanted to have:
>
> a) Security objects with other information.
> b) Different back-ends.
>
> I'm sure there are a lot of loose ends, but I really wanted to send this
> to the list ASAP, for its discussion and trashing. In particular, I think
> it could be useful to define more administrative functions in the factory
> interfaces, trying to foresee massive operations that could be implemented
> more efficiently directly by the factory.
>
> 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
A new ZIP archive with the same files, but this time it compiles,
so at least the ugliest warts have been cleaned up (not that it
does anything yet!). You can just disregard the previous version.
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
> -----Original Message-----
> From: Gonzalo A. Diethelm [mailto:gonzalo.diethelm@aditiva.com]
> Sent: Tuesday, January 08, 2002 09:52 AM
> To: Turbine Developers List
> Subject: First ideas for new security model
>
>
> I'm attaching my first ideas on the new security model. The archive
> is supposed to be expanded under org.apache.fulcrum.security.
>
> [Jason, I'm sending this to your personal address in case the list
> doesn't like attachments].
>
> These are my ideas up to now:
>
> * Five interfaces Permission, Role, User, Application and Session
> (package entity). These have no data except for a unique String
> id, and each has some basic operations related to security queries.
> There are no administrative functions at this level.
>
> * Five classes Fulcrum{Permission,Role,User,Application,Session}
> (package entity.fulcrum), that have a basic implementation of the
> above interfaces.
>
> * Five interfaces {Permission,Role,User,Application,Session}Factory
> (package factory). These define the operations to load, save and
> remove their respective objects from a back-end.
>
> * Five classes Fulcrum{Permission,Role,User,Application,Session}Factory
> (package factory.fulcrum), that have a basic (mostly comments)
> implementation of the above interfaces.
>
> * The idea is that Fulcrum code uses ONLY the Permission, Role, User,
> Application and Session interfaces, NEVER referring to a concrete
> extension of them.
>
> * I include a sample properties file where the programmer will specify
> what concrete entity and factory classes she whishes to use.
>
> * There is a SecurityManager class, a facade for all the factory classes
> that reads the configuration file and uses the configured factories to
> manipulate security objects.
>
> * A programmer could create new classes implementing the basic interfaces
> if she wanted to have:
>
> a) Security objects with other information.
> b) Different back-ends.
>
> I'm sure there are a lot of loose ends, but I really wanted to send this
> to the list ASAP, for its discussion and trashing. In particular, I think
> it could be useful to define more administrative functions in the factory
> interfaces, trying to foresee massive operations that could be implemented
> more efficiently directly by the factory.
>
> Best regards,
>
>
> --
> Gonzalo A. Diethelm
> gonzalo.diethelm@aditiva.com
>
Re: First ideas for new security model
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/8/02 7:52 AM, "Gonzalo A. Diethelm" <go...@aditiva.com>
wrote:
> I'm attaching my first ideas on the new security model. The archive
> is supposed to be expanded under org.apache.fulcrum.security.
>
> [Jason, I'm sending this to your personal address in case the list
> doesn't like attachments].
>
Thanks, I'm in transit at the moment and pretty sick but I'll look at the
code when I get home on the 14th.
--
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>
First ideas for new security model
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
I'm attaching my first ideas on the new security model. The archive
is supposed to be expanded under org.apache.fulcrum.security.
[Jason, I'm sending this to your personal address in case the list
doesn't like attachments].
These are my ideas up to now:
* Five interfaces Permission, Role, User, Application and Session
(package entity). These have no data except for a unique String
id, and each has some basic operations related to security queries.
There are no administrative functions at this level.
* Five classes Fulcrum{Permission,Role,User,Application,Session}
(package entity.fulcrum), that have a basic implementation of the
above interfaces.
* Five interfaces {Permission,Role,User,Application,Session}Factory
(package factory). These define the operations to load, save and
remove their respective objects from a back-end.
* Five classes Fulcrum{Permission,Role,User,Application,Session}Factory
(package factory.fulcrum), that have a basic (mostly comments)
implementation of the above interfaces.
* The idea is that Fulcrum code uses ONLY the Permission, Role, User,
Application and Session interfaces, NEVER referring to a concrete
extension of them.
* I include a sample properties file where the programmer will specify
what concrete entity and factory classes she whishes to use.
* There is a SecurityManager class, a facade for all the factory classes
that reads the configuration file and uses the configured factories to
manipulate security objects.
* A programmer could create new classes implementing the basic interfaces
if she wanted to have:
a) Security objects with other information.
b) Different back-ends.
I'm sure there are a lot of loose ends, but I really wanted to send this
to the list ASAP, for its discussion and trashing. In particular, I think
it could be useful to define more administrative functions in the factory
interfaces, trying to foresee massive operations that could be implemented
more efficiently directly by the factory.
Best regards,
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
Re: 2.2 Plan
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/5/02 7:37 AM, "Henning P. Schmiedehausen" <hp...@intermeta.de> wrote:
> If you don't want to read such words, please use a Killfile.
> X-Copyright: (C) 1996-2002 Henning Schmiedehausen
> X-No-Archive: yes
> X-Newsreader: NN version 6.5.1 (NOV)
>
> Jason van Zyl <jv...@zenplex.com> writes:
>
>>> ask myself why the Torque class must know about threads running in the
>>> DatabaseMap classes.
>
>> I could hand you a list as long as my arm, so what? Document them and post
>> tests and fixes.
>
> Could you please send this to me? Even if it is just a list of "nice
> to haves". I'm really looking for stuff like this!
I will gather them all together and post a link to the list in preparation
for the informal meeting next week. I think if we can all agree on the
design than we can all pitch in to improve Torque. I think SA's papers are
at least the best place to start. You appear interested, Fedor is
interested, I'm definitely interested and so is Martin. I think we could
clean up Torque in a matter of a couple months.
There is also this code that was donated to apache which has some code that
we might want to lift:
http://www.apache.org/~jvanzyl/dbo.zip
It is a partial SA implementation. And though the author's name escapes me
at the moment I would imagine we would be interested in helping too.
Anyway, I will get those notes together.
--
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: 2.2 Plan
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
If you don't want to read such words, please use a Killfile.
X-Copyright: (C) 1996-2002 Henning Schmiedehausen
X-No-Archive: yes
X-Newsreader: NN version 6.5.1 (NOV)
Jason van Zyl <jv...@zenplex.com> writes:
>> ask myself why the Torque class must know about threads running in the
>> DatabaseMap classes.
>I could hand you a list as long as my arm, so what? Document them and post
>tests and fixes.
Could you please send this to me? Even if it is just a list of "nice
to haves". I'm really looking for stuff like this!
>
>> Ok, I know that bullshit talks and code walks. But I'm _so_ unhappy
>> with the current state of the OM system of Torque/Turbine _and_ I have
>> almost a week of time coming up, that I will work on a prototype of a
>> "Torque next generation" the next week.
>Please read Scott Ambler's papers before you go off designing something on
>your own. Time would be best spent understanding his design as I believe
>it's sound and well documented and will provide something better than what
>we currently have.
I know the papers, I think I understood them ( :-) ) and I will follow
his basic ideas.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 2.2 Plan
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/4/02 1:04 PM, "John McNally" <jm...@collab.net> wrote:
>
>> My intention is not "being compatible to Torque" but "keeping the
>> style of the Turbine OM system alive while attacking the inadequacies
>> and shortcomings of the current system. I HATE THE STATIC PEERS FROM
>> THE VERY BOTTOM OF MY HEART. Yet I will keep facade classes for the
>> people who want to use it.
>
> This feeling is shared by a good number of people. I started on
> changing it a couple times, but have not had time to every complete it.
> Glad you are volunteering to take it on.
The thing to remember, the thing which stopped me from a rewrite, is that it
works. Maybe everything is not as decoupled as we would like but the code
serves a lot of people and the majority of the time most people don't have
see a lot of the more esoteric portions of torque.
I think by defining some clear interfaces for persistent objects (which John
has started), and closing off some of the internals that people can move
forward without much pain.
>
>> Ideas I will work on from the README.txt
>>
>> --- cut ---
>> o Torque should be fully functional on its own, but right now
>> it doesn't work as a persistence layer without the DBService
>> in Fulcrum. The classes should be moved from Fulcrum into
>> this repository and Torque should be made to work on its own
>> and be embeddable in applications. The DBService in Fulcrum
>> should be a wrapper around Torque.
>
> I thought jason has already taken care of this, but maybe there is still
> a little work to do.
This is done, the Torque testbed is a demonstration of this.
>>
>> o Separate the connection pool and make it pluggable
>> so that torque can easily be integrated into other application
>> that already use PoolMan, or the commons connection pool, or
>> the struts connection pool or whatever
>
> I have been working on this and most of the code in the JDBC2POOL_BRANCH
> tag of torque. The pool has been updated to jdbc2 compliance with an
> adapter for non-jdbc2 driver implementations. The main issue still left
> to be worked out is setting jndi properties for the initial context.
>
> john mcnally
>
> --
> 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: 2.2 Plan
Posted by John McNally <jm...@collab.net>.
> My intention is not "being compatible to Torque" but "keeping the
> style of the Turbine OM system alive while attacking the inadequacies
> and shortcomings of the current system. I HATE THE STATIC PEERS FROM
> THE VERY BOTTOM OF MY HEART. Yet I will keep facade classes for the
> people who want to use it.
This feeling is shared by a good number of people. I started on
changing it a couple times, but have not had time to every complete it.
Glad you are volunteering to take it on.
> Ideas I will work on from the README.txt
>
> --- cut ---
> o Torque should be fully functional on its own, but right now
> it doesn't work as a persistence layer without the DBService
> in Fulcrum. The classes should be moved from Fulcrum into
> this repository and Torque should be made to work on its own
> and be embeddable in applications. The DBService in Fulcrum
> should be a wrapper around Torque.
I thought jason has already taken care of this, but maybe there is still
a little work to do.
>
> o Separate the connection pool and make it pluggable
> so that torque can easily be integrated into other application
> that already use PoolMan, or the commons connection pool, or
> the struts connection pool or whatever
I have been working on this and most of the code in the JDBC2POOL_BRANCH
tag of torque. The pool has been updated to jdbc2 compliance with an
adapter for non-jdbc2 driver implementations. The main issue still left
to be worked out is setting jndi properties for the initial context.
john mcnally
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 2.2 Plan
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/4/02 12:52 PM, "Henning P. Schmiedehausen" <hp...@intermeta.de> wrote:
> If you don't want to read such words, please use a Killfile.
> X-Copyright: (C) 1996-2002 Henning Schmiedehausen
> X-No-Archive: yes
> X-Newsreader: NN version 6.5.1 (NOV)
>
> Jason van Zyl <jv...@zenplex.com> writes:
>
>> Hi,
>
>> All users that have responded on the list want to wait for the decoupled
>> versions of torque and fulcrum to be available for use in 2.x before we
>> release. We have discussed this briefly in IRC but how about the following
>> for a plan.
>
> Hm,
>
> I pulled some changes from the 2.2 code because of compatibility
> issues. So I want to know how exactly this changeover from 2.1 to 2.2
> + fulcrum + torque will happen. At least the base classes of the whole
> om system will change from org.apache.turbine to org.apache.torque,
> wouldn't it? Same goes to the service environment.
By default the couple versions of the services framework and torque will be
used. You will have to specify the use the decoupled versions. If you are
ready to move forward then you can, and is highly recommended, if not than
things will work as before.
> We pulled the interface changes from T2.2beta because some users had
> to recompile.
No, not because they had to recompile but that it wouldn't compile. I
wouldn't have minded recompiling but your changes didn't work without code
changes.
>If I use T2 + Fulcrum + Torque with one of my projects,
> I have major _rewrites_ of my code to get it to run.
You do not have to use Fulcrum or Torque if you don't want.
> or am I seeing something wrong here? Will we keep code in both Torque
> and T2? If yes, the I really see no point in using them.
We will keep both versions around for compatibility but it will definitely
be recommended that people move forward as many people aren't going to be
contributing toward the coupled versions of the tools.
This will allow users to move forward if they want and we can figure out
some migration strategies for people who want to wait. At the very least
there will be issues dealt with on the mailing list to help people move
forward.
>> i) Introduction of lifecycle interfaces in org.apache.stratum.lifecycle.
>
> [...]
>
> I always see postings about "that we will have now, that we will make
> new, that will change...". But the last released TDK is what? six
> months old?
We haven't released but lots has been going on. I don't care that we haven't
released. It would be nice and it will be more frequent but probably not
during all these changes.
> And I have the "fun" of working with the Torque code today
> a little and honestly, it makes me wanting to throw up. Look at this:
>
> --- cut ---
> [...]
> private static String getDatabaseProperty(String db, String prop)
> {
> return configuration.getString( new StringBuffer("database.")
> .append(db)
> .append('.')
> .append(prop)
> .toString(), "" );
> }
> [...]
> private static final String getProperty(String dbName, String prop)
> {
> return ("database." + dbName + '.' + prop);
> }
> [...]
> --- cut ---
>
> What is wrong with this picture? And this is not exactly in an unimportant
> piece of Torque but in o.a.t.Torque.java
>
> I can point out some race conditions, some unclear code and I still
> ask myself why the Torque class must know about threads running in the
> DatabaseMap classes.
I could hand you a list as long as my arm, so what? Document them and post
tests and fixes.
> Ok, I know that bullshit talks and code walks. But I'm _so_ unhappy
> with the current state of the OM system of Torque/Turbine _and_ I have
> almost a week of time coming up, that I will work on a prototype of a
> "Torque next generation" the next week.
Please read Scott Ambler's papers before you go off designing something on
your own. Time would be best spent understanding his design as I believe
it's sound and well documented and will provide something better than what
we currently have.
> BTW: I'd like to reserve "Turbine-Twister" for this. ;-) (Twister
> seems to be almost the only synonym that Webster gave me for
> "Torque". )
>
> My intention is not "being compatible to Torque" but "keeping the
> style of the Turbine OM system alive while attacking the inadequacies
> and shortcomings of the current system. I HATE THE STATIC PEERS FROM
> THE VERY BOTTOM OF MY HEART. Yet I will keep facade classes for the
> people who want to use it.
Yes, it's been discussed. I'm sure many of us have the same dislikes that
you have.
> I currently have about 10% of the code ready and I tackled some of the
> heavier stuff first (Torque, Criteria, BasePeer). I will basically
> keep the Transformation stuff as it is but (of course) tackle the
> templates.
Again, I urge you to read Scott Ambler's papers. I myself am not really
looking anything else and I hope we can incorporate his designs with what we
have. I have refrained myself from starting from scratch.
> Ideas I will work on from the README.txt
>
> --- cut ---
> o Torque should be fully functional on its own, but right now
> it doesn't work as a persistence layer without the DBService
> in Fulcrum.
It is now. And the DBService will go away. At least I want it to.
> The classes should be moved from Fulcrum into
> this repository and Torque should be made to work on its own
> and be embeddable in applications. The DBService in Fulcrum
> should be a wrapper around Torque.
It's what it is now. This has been done too.
> o Separate the connection pool and make it pluggable
> so that torque can easily be integrated into other application
> that already use PoolMan, or the commons connection pool, or
> the struts connection pool or whatever
> --- cut ---
>
> I have also some notes already written down:
You should come to IRC as we talk about these things a lot there. Possibly
more than we should but all these things have been discussed. We were just
talking about it now actually.
--
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: 2.2 Plan
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
If you don't want to read such words, please use a Killfile.
X-Copyright: (C) 1996-2002 Henning Schmiedehausen
X-No-Archive: yes
X-Newsreader: NN version 6.5.1 (NOV)
Jason van Zyl <jv...@zenplex.com> writes:
>Hi,
>All users that have responded on the list want to wait for the decoupled
>versions of torque and fulcrum to be available for use in 2.x before we
>release. We have discussed this briefly in IRC but how about the following
>for a plan.
Hm,
I pulled some changes from the 2.2 code because of compatibility
issues. So I want to know how exactly this changeover from 2.1 to 2.2
+ fulcrum + torque will happen. At least the base classes of the whole
om system will change from org.apache.turbine to org.apache.torque,
wouldn't it? Same goes to the service environment.
We pulled the interface changes from T2.2beta because some users had
to recompile. If I use T2 + Fulcrum + Torque with one of my projects,
I have major _rewrites_ of my code to get it to run.
or am I seeing something wrong here? Will we keep code in both Torque
and T2? If yes, the I really see no point in using them.
>i) Introduction of lifecycle interfaces in org.apache.stratum.lifecycle.
[...]
I always see postings about "that we will have now, that we will make
new, that will change...". But the last released TDK is what? six
months old? And I have the "fun" of working with the Torque code today
a little and honestly, it makes me wanting to throw up. Look at this:
--- cut ---
[...]
private static String getDatabaseProperty(String db, String prop)
{
return configuration.getString( new StringBuffer("database.")
.append(db)
.append('.')
.append(prop)
.toString(), "" );
}
[...]
private static final String getProperty(String dbName, String prop)
{
return ("database." + dbName + '.' + prop);
}
[...]
--- cut ---
What is wrong with this picture? And this is not exactly in an unimportant
piece of Torque but in o.a.t.Torque.java
I can point out some race conditions, some unclear code and I still
ask myself why the Torque class must know about threads running in the
DatabaseMap classes.
Ok, I know that bullshit talks and code walks. But I'm _so_ unhappy
with the current state of the OM system of Torque/Turbine _and_ I have
almost a week of time coming up, that I will work on a prototype of a
"Torque next generation" the next week.
BTW: I'd like to reserve "Turbine-Twister" for this. ;-) (Twister
seems to be almost the only synonym that Webster gave me for
"Torque". )
My intention is not "being compatible to Torque" but "keeping the
style of the Turbine OM system alive while attacking the inadequacies
and shortcomings of the current system. I HATE THE STATIC PEERS FROM
THE VERY BOTTOM OF MY HEART. Yet I will keep facade classes for the
people who want to use it.
I currently have about 10% of the code ready and I tackled some of the
heavier stuff first (Torque, Criteria, BasePeer). I will basically
keep the Transformation stuff as it is but (of course) tackle the
templates.
Ideas I will work on from the README.txt
--- cut ---
o Torque should be fully functional on its own, but right now
it doesn't work as a persistence layer without the DBService
in Fulcrum. The classes should be moved from Fulcrum into
this repository and Torque should be made to work on its own
and be embeddable in applications. The DBService in Fulcrum
should be a wrapper around Torque.
o Separate the connection pool and make it pluggable
so that torque can easily be integrated into other application
that already use PoolMan, or the commons connection pool, or
the struts connection pool or whatever
--- cut ---
I have also some notes already written down:
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: 2.2 Plan
Posted by Martin Poeschl <mp...@marmot.at>.
Jason van Zyl wrote:
> Hi,
>
> All users that have responded on the list want to wait for the decoupled
> versions of torque and fulcrum to be available for use in 2.x before we
> release. We have discussed this briefly in IRC but how about the following
> for a plan.
>
> i) Introduction of lifecycle interfaces in org.apache.stratum.lifecycle.
> These are direct copies of Avalon's lifecycle interfaces as I see no point
> making signatures that aren't compatible, we may never use Avalon but I
> could definitely see some of their lifecycle interfaces moving into the
> commons eventually.
>
> ii) Make Torque and Fulcrum implement these lifecycle interfaces so that
> they can be manipulated in the same fashion with respect to configuration
> and initialization.
>
> iii) Code would be added to both t3 and t2 so that subsystems implementing
> these lifecycle interfaces can be dealt with. The result will be the
> pluggability of large subsystems like services frameworks and persistence
> frameworks. So someone could use another services framework or persistence
> tool with t3 a lot more easily. The upshot is also that Torque will be used
> directly and we'll get rid of the DatabaseService all together.
>
> Martin is willing to work on the Turbine code, and I can work on the Fulcrum
> code and making the necessary changes to the turbine code.
>
> This is the only way I can see to allow us to use the decoupled codebases in
> both t2 and t3.
>
> In Tambora, as I imagine with many 2.x projects, we want to help contribute
> toward the decoupled code bases but we can't move away from 2.x for a while
> so Martin and myself can definitely put some time into this as it is
> important for Tambora. In a brief chat with Martin we decided that we could
> get most of the work and testing done in three weeks if we start today.
>
> I think as soon as we can get rid of the couple code bases the better and it
> appears that users are willing to wait, as they've waited this long already.
>
> So I'm an obvious
>
> +1
+1
martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: 2.2 Plan
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> All users that have responded on the list want to wait for the decoupled
> versions of torque and fulcrum to be available for use in 2.x before we
> release. We have discussed this briefly in IRC but how about the following
> for a plan.
[snip]
+1, great plan!
> 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>