You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2003/01/07 13:05:53 UTC
Re: TurbineUser - Extending it? Maybe you should not have to.
Rodney Schneider <ro...@actf.com.au> writes:
>... and diving head first into one of the longest standing issues in
>Turbine land -- the notorious Security Service.
>> I think that Henning makes some great headway on this issue with his
>> version of the security service. With his version of the security
>> service, the column names could change.
>I agree that Henning's security service is a good intermediate solution
>until a new improved security service arrives. It is the best solution
>I have seen that uses the current user, group, role and permission
>scheme.
After I got _that_ much credit, I'll try to get it into the turbine-2
and fulcrum CVS tonight so everyone can check out for themselves. No,
don't panic, I will _not_ remove the existing DB services, I will call
this "TorqueSecurityService", so you can switch back and forth. I was
thinking about this for quite some time and this might be as good as
any other time.
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: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by Stephen Haberman <st...@beachead.com>.
On Fri, Jan 10, 2003 at 11:57:31AM -0800, David Worms wrote:
> Sorry, I wasn't clear enough, I was mentioning an <b>object</b>
> in-memory database implementation.
Ah, cool. Actually, now that I look at it, that's very cool. Their
website is pretty convincing; I'll have to download it sometime and
see if it lives up to their hype.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by David Worms <da...@simpledesign.com>.
On Friday, January 10, 2003, at 11:52 AM, David Worms wrote:
>
> On Friday, January 10, 2003, at 11:31 AM, Stephen Haberman wrote:
>
>> On Fri, Jan 10, 2003 at 11:11:29AM -0800, David Worms wrote:
>>> I would be interested in providing an in-memory database
>>> implementation
>>> (maybe using Prevayler @ SourceForge)
>>
>> I haven't looked at Prevalyer, but Axion over at tigris.org is an
>> in-memory database implementation worked on by some Turbine people.
>> I haven't used it, but there are adapters for it in Torque already.
>
> I'll check Axion.
Sorry, I wasn't clear enough, I was mentioning an <b>object</b>
in-memory database implementation.
>
>>
>>>> I'm in initial agreement, though dan.envoisolutions.com isn't
>>>> responding, so I can't give the API a more careful look.
>>>
>>> How can we get the source code?
>>
>> Was this directed at me or Dan? (e.g. what source code are you
>> asking for?)
>>
>> - Stephen
>
> This was directed to Dan. I am looking for the source of the proposed
> security service, if available, or an access to the API,
> dan.envoisolutions.com not responding. I need to get more familiar
> with JAAS.
>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by David Worms <da...@simpledesign.com>.
On Friday, January 10, 2003, at 11:31 AM, Stephen Haberman wrote:
> On Fri, Jan 10, 2003 at 11:11:29AM -0800, David Worms wrote:
>> I would be interested in providing an in-memory database
>> implementation
>> (maybe using Prevayler @ SourceForge)
>
> I haven't looked at Prevalyer, but Axion over at tigris.org is an
> in-memory database implementation worked on by some Turbine people.
> I haven't used it, but there are adapters for it in Torque already.
I'll check Axion.
>
>>> I'm in initial agreement, though dan.envoisolutions.com isn't
>>> responding, so I can't give the API a more careful look.
>>
>> How can we get the source code?
>
> Was this directed at me or Dan? (e.g. what source code are you
> asking for?)
>
> - Stephen
This was directed to Dan. I am looking for the source of the proposed
security service, if available, or an access to the API,
dan.envoisolutions.com not responding. I need to get more familiar with
JAAS.
>
> --
> 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: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by Stephen Haberman <st...@beachead.com>.
On Fri, Jan 10, 2003 at 11:11:29AM -0800, David Worms wrote:
> I would be interested in providing an in-memory database implementation
> (maybe using Prevayler @ SourceForge)
I haven't looked at Prevalyer, but Axion over at tigris.org is an
in-memory database implementation worked on by some Turbine people.
I haven't used it, but there are adapters for it in Torque already.
> >I'm in initial agreement, though dan.envoisolutions.com isn't
> >responding, so I can't give the API a more careful look.
>
> How can we get the source code?
Was this directed at me or Dan? (e.g. what source code are you
asking for?)
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Security Service [was RE: TurbineUser - Extending it? Maybe
you should not have to.]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Stephen Haberman wrote:
> On Fri, Jan 10, 2003 at 04:02:25AM -0300, Gonzalo Diethelm wrote:
>
>>If you can package it so that:
>>
>>* it compiles with HEAD,
>>* it is pluggable and configurable via TR.props,
>>* it provides the following implementations: DB-based (traditional
>> Turbine style), XML-based and null (that is, no security,
>> everything is allowed),
>>
>>then I would heartily stand by it as a Next Generation security
>>service. Even more, I would push for having the null
>>implementation as Turbine's default.
>
>
> I'm in initial agreement, though dan.envoisolutions.com isn't
> responding, so I can't give the API a more careful look. But if
> enough people like it, there is no reason Turbine (or more
> appropriately Fulcrum :-) can't have more than one security
> solution.
>
> Granted it'd be fragmented, but competition is a good thing, and the
> one with the most support/users could always win out in the end as
> the other is deprecated.
>
> - Stephen
The site is back up. Why do things always go wrong when you're gone? :)
I will work on it a bit tonight and post the stuff tomorrow. Be patient
as I'm still travelling through Europe on vacation. I'll be intouch in
the next day or two with more info. Thanks for the positive feedback!
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by David Worms <da...@simpledesign.com>.
>>
>> * it is pluggable and configurable via TR.props,
>> * it provides the following implementations: DB-based (traditional
>> Turbine style), XML-based and null (that is, no security,
>> everything is allowed),
I would be interested in providing an in-memory database implementation
(maybe using Prevayler @ SourceForge)
> I'm in initial agreement, though dan.envoisolutions.com isn't
> responding, so I can't give the API a more careful look.
How can we get the source code?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by Stephen Haberman <st...@beachead.com>.
On Fri, Jan 10, 2003 at 04:02:25AM -0300, Gonzalo Diethelm wrote:
> If you can package it so that:
>
> * it compiles with HEAD,
> * it is pluggable and configurable via TR.props,
> * it provides the following implementations: DB-based (traditional
> Turbine style), XML-based and null (that is, no security,
> everything is allowed),
>
> then I would heartily stand by it as a Next Generation security
> service. Even more, I would push for having the null
> implementation as Turbine's default.
I'm in initial agreement, though dan.envoisolutions.com isn't
responding, so I can't give the API a more careful look. But if
enough people like it, there is no reason Turbine (or more
appropriately Fulcrum :-) can't have more than one security
solution.
Granted it'd be fragmented, but competition is a good thing, and the
one with the most support/users could always win out in the end as
the other is deprecated.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by Gonzalo Diethelm <go...@aditiva.com>.
> > I like it. How do you specify the controllers you want to use? I'm
> > thinking from the point of view of a Turbine security service, you
> > would probably want to configure that from the properties file.
> >
> > In fact, I think it works pretty much like the thing I came up with.
> > Good work! ;-)
>
> If people are interested (please give me your thoughts) I will port the
> db service to this as well as finish off an XML implementation that I
> started as well as create a Turbine binding. If people are seriously
> considering this I will clean everything up and present as a package in
> a week or two.
If you can package it so that:
* it compiles with HEAD,
* it is pluggable and configurable via TR.props,
* it provides the following implementations: DB-based (traditional
Turbine style), XML-based and null (that is, no security,
everything is allowed),
then I would heartily stand by it as a Next Generation security
service. Even more, I would push for having the null implementation
as Turbine's default.
> - Dan
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: New Security Service [was RE: TurbineUser - Extending it? Maybe
you should not have to.]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Gonzalo Diethelm wrote:
>>Speaking of this topic, I had an idea one night about security. After a
>>couple hours I came up with this:
>>
>>http://dan.envoisolutions.com/jasf/
>>
>>It seems to be pretty flexible, but I'm not sure everyone would like
>>using it. I wanted something where I could authenticate not only
>>webpages, but other resources - such as access to various components in
>>my system. I even wrote a XML user and permission based system for it.
>>
>>Thoughts?
>
>
> I like it. How do you specify the controllers you want to use? I'm
> thinking from the point of view of a Turbine security service, you
> would probably want to configure that from the properties file.
>
> In fact, I think it works pretty much like the thing I came up with.
> Good work! ;-)
>
Hi,
Sorry it has taken so long for me to reply, I am currently travelling
through Europe :).
To access the different controllers you register them with the
ResourceManager or the EntityAuthenticationManager (more correctly the
implementation of these interfaces). Then you just do
manager.lookup(ResourceClass.RESOURCE_TYPE) or
manager.lookup(BasicUser.ENTITY_TYPE). I haven't created binding class
for Turbine yet, but yes, it would be through TR.props.
If people are interested (please give me your thoughts) I will port the
db service to this as well as finish off an XML implementation that I
started as well as create a Turbine binding. If people are seriously
considering this I will clean everything up and present as a package in
a week or two.
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Security Service
Posted by Dan Diephouse <da...@envoisolutions.com>.
David Worms wrote:
>
> Dan,
>
> Could you put back up the link for the source code on the JASF web site ?
>
> Thanks
Sorry, server switch. Should be here:
http://dan.envoisolutions.com/jasf
Cheers,
Dan Diephouse
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: New Security Service [was RE: TurbineUser - Extending it? Maybe
you should not have to.]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Yes, that is the point. Suppose you have your Turbine application.
Well, it is able to use the ResourceManager to lookup a
ResourceAccessController. How the ResourceAccessController acts for
each function is entirely up to you. We would probably want to package
it with the default DB service, but you could easily design it so it
loads JAASAccessController instead of DBAccessController for the turbine
resource type (ie: a web page). Hope this makes sense :)
- Dan
Colin Chalmers wrote:
> Would it be able to plug into other systems? ie Tomcat's Realm or Suns JAAS?
>
> The discussion surrounding security was quite lively about a year ago (was
> it really a year ago?) with some good suggestions on improving the current
> service.
>
> Should we perhaps re-waken this discussion and see if we get any further?
>
> /c
>
>
>
>>>Speaking of this topic, I had an idea one night about security. After a
>>>couple hours I came up with this:
>>>
>>>http://dan.envoisolutions.com/jasf/
>>>
>>>It seems to be pretty flexible, but I'm not sure everyone would like
>>>using it. I wanted something where I could authenticate not only
>>>webpages, but other resources - such as access to various components in
>>>my system. I even wrote a XML user and permission based system for it.
>>>
>>>Thoughts?
>>
>>I like it. How do you specify the controllers you want to use? I'm
>>thinking from the point of view of a Turbine security service, you
>>would probably want to configure that from the properties file.
>>
>>In fact, I think it works pretty much like the thing I came up with.
>
>Good work! ;-)
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by Colin Chalmers <co...@maxware.nl>.
Would it be able to plug into other systems? ie Tomcat's Realm or Suns JAAS?
The discussion surrounding security was quite lively about a year ago (was
it really a year ago?) with some good suggestions on improving the current
service.
Should we perhaps re-waken this discussion and see if we get any further?
/c
> > Speaking of this topic, I had an idea one night about security. After a
> > couple hours I came up with this:
> >
> > http://dan.envoisolutions.com/jasf/
> >
> > It seems to be pretty flexible, but I'm not sure everyone would like
> > using it. I wanted something where I could authenticate not only
> > webpages, but other resources - such as access to various components in
> > my system. I even wrote a XML user and permission based system for it.
> >
> > Thoughts?
>
> I like it. How do you specify the controllers you want to use? I'm
> thinking from the point of view of a Turbine security service, you
> would probably want to configure that from the properties file.
>
> In fact, I think it works pretty much like the thing I came up with.
> Good work! ;-)
>
> > - Dan Diephouse
>
> 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: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by Gonzalo Diethelm <go...@aditiva.com>.
> Speaking of this topic, I had an idea one night about security. After a
> couple hours I came up with this:
>
> http://dan.envoisolutions.com/jasf/
>
> It seems to be pretty flexible, but I'm not sure everyone would like
> using it. I wanted something where I could authenticate not only
> webpages, but other resources - such as access to various components in
> my system. I even wrote a XML user and permission based system for it.
>
> Thoughts?
I like it. How do you specify the controllers you want to use? I'm
thinking from the point of view of a Turbine security service, you
would probably want to configure that from the properties file.
In fact, I think it works pretty much like the thing I came up with.
Good work! ;-)
> - Dan Diephouse
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: New Security Service
Posted by David Worms <da...@simpledesign.com>.
Dan,
Could you put back up the link for the source code on the JASF web site
?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: New Security Service [was RE: TurbineUser - Extending it? Maybe
you should not have to.]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Gonzalo Diethelm wrote:
>
> Yeah, old issue, big can'o worms.
>
> I participated in that old thread months (actually, I think it was more
> than a year) ago. I still believe we should go this route:
>
> * Everything is based on interfaces.
> * There is a security manager interface that provides two methods:
> one to authenticate a user given their credentials (to login),
> and one to determine whether a user is authorized to do something.
> Nothing more, nothing less.
> * From here on, there are several choices. I personally have an
> implementation of a concrete security manager that is pluggable:
> you specify how you authenticate and authorize (via objects that
> themselves implement a couple of generic interfaces). This means
> that I can then implement concrete authenticators and authorizers
> that, for example, replicate the current Turbine DB-based service,
> or I can implement null operators, etc., and switch from one to
> the other via TR.props. It also means that Turbine could ship with
> a default, simpler security implementation (null) AND a DB-based
> implementation that can be turned on if the user so desires.
>
> Just my opinions. Regards,
>
>
> --
> Gonzalo A. Diethelm
> gonzalo.diethelm@aditiva.com
Speaking of this topic, I had an idea one night about security. After a
couple hours I came up with this:
http://dan.envoisolutions.com/jasf/
It seems to be pretty flexible, but I'm not sure everyone would like
using it. I wanted something where I could authenticate not only
webpages, but other resources - such as access to various components in
my system. I even wrote a XML user and permission based system for it.
Thoughts?
- Dan Diephouse
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by Gonzalo Diethelm <go...@aditiva.com>.
> > * There is a security manager interface that provides two methods:
> > one to authenticate a user given their credentials (to login),
> > and one to determine whether a user is authorized to do something.
> > Nothing more, nothing less.
>
> How would you get the user or user id to ask that second question ?
>
> IMHO, if you want to ask that second question, you need to be
> able to get a
> reference to the current user/userid (or whatever you want to
> call it) from
> the RunData (like the current getUser() method). And that means you need
> some kind of basic User (or whatever) object/interface to talk
> to.... right?
Yes. I have empty interfaces for the concepts of Subject (or User)
and Permission. The concrete classes to be used are configurable in
the system as well. I guess any minimal concrete class would have an
id for each class.
> Age
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: New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by Age Mooy <am...@home.nl>.
> Yeah, old issue, big can'o worms.
>
> I participated in that old thread months (actually, I think it was more
> than a year) ago. I still believe we should go this route:
>
> * Everything is based on interfaces.
> * There is a security manager interface that provides two methods:
> one to authenticate a user given their credentials (to login),
> and one to determine whether a user is authorized to do something.
> Nothing more, nothing less.
How would you get the user or user id to ask that second question ?
IMHO, if you want to ask that second question, you need to be able to get a
reference to the current user/userid (or whatever you want to call it) from
the RunData (like the current getUser() method). And that means you need
some kind of basic User (or whatever) object/interface to talk to.... right
?
Age
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
New Security Service [was RE: TurbineUser - Extending it? Maybe you should not have to.]
Posted by Gonzalo Diethelm <go...@aditiva.com>.
> Rodney Schneider <ro...@actf.com.au> writes:
>
> > ... and diving head first into one of the longest standing issues in
> > Turbine land -- the notorious Security Service.
> >
> > The idea of removing most of the methods of the security interfaces has
> > been discussed many times on this list. The archives will reveal a
> > sordid tale. I think the final conclusion was to use empty security
> > interfaces and allow users to define there own custom security
> > services, with a default implementation similar to the current security
> > scheme (ie: user, group, role, permission).
Yeah, old issue, big can'o worms.
I participated in that old thread months (actually, I think it was more
than a year) ago. I still believe we should go this route:
* Everything is based on interfaces.
* There is a security manager interface that provides two methods:
one to authenticate a user given their credentials (to login),
and one to determine whether a user is authorized to do something.
Nothing more, nothing less.
* From here on, there are several choices. I personally have an
implementation of a concrete security manager that is pluggable:
you specify how you authenticate and authorize (via objects that
themselves implement a couple of generic interfaces). This means
that I can then implement concrete authenticators and authorizers
that, for example, replicate the current Turbine DB-based service,
or I can implement null operators, etc., and switch from one to
the other via TR.props. It also means that Turbine could ship with
a default, simpler security implementation (null) AND a DB-based
implementation that can be turned on if the user so desires.
Just my opinions. 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>