You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Richard Wallace <rw...@a--i--m.com> on 2002/06/06 02:58:55 UTC
Mulitple components of same ROLE
Hey guys,
I've been working with Larry on a AAA
(Authentication/Authorization/Auditing) framework for cornerstone. One
of the things that we're discussing is if we should have support for
multiple Realms similar to the way PAM and JAAS have multiple
LoginModules. I'm thinking that it would be similar in function to the
way JAAS does it, but alleviates the need for relying on the JAAS API
and creating a JAASRealm that would have to be used to get this feature.
I have two questions about this, I guess:
1) Does this sound like a feature people would be interested in? If
there isn't a lot of need for it we'll put it on the back burner and
maybe write an implementation later that will support it.
2) We're deciding that (at least within phoenix) Realms will be
configured and provided to the Authenticator as blocks. So, if we
decide to support multiple realms how do we provide multiple components
that implement the same role (in this case Realm) to a Serviceable
component? Or would that not be the right interface to implement?
What, other than Serviceable, should it become to accomplish this?
Thanks.
--
Richard Wallace
AIM, Inc. (www.a--i--m.com)
Information Systems Consultants
"Providing New Technology,
the Old-Fashioned Way"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mulitple components of same ROLE
Posted by Stephen McConnell <mc...@osm.net>.
Paul Hammant wrote:
> Stephen.
>
>>> 2) We're deciding that (at least within phoenix) Realms will be
>>> configured and provided to the Authenticator as blocks.
>>
>>
>>
>> +1
>> (and I'm assuming when you say block, you actually mean a
>> component + meta-info .. which is equivalent to the notion of a block)
>
>
> It is coupled to a Phonix impl at present. Are you interested in
> using outrside of Phonix - i.e . in servlet context?
>
>>> So, if we
>>> decide to support multiple realms how do we provide multiple components
>>> that implement the same role (in this case Realm) to a Serviceable
>>> component? Or would that not be the right interface to implement?
>>
>>
>>
>> Yes and no.
>> Some possible approaches:
>>
>> 1. Create an Authenticator component that has a dependecy of a RealmSet
>> component. The RealSet establishes the realms using whatever
>> implementation magic it likes (via configuration info, via dynamic
>> lookup of available realms in a directory or file-system, etc).
>> The kernel will supply the RealmSet to the Authenticator based on the
>> dependecies you declare.
>
>
> The trouble is that in terms of lifecycle, service(..) is called for
> all blocks before configure(..) is for all blocks.
Hang on - just re-reading this - and I think I disagree.
In Phoenix, blocks are fully processed through the lifecycle one by one.
I.e. process block A, process block B, etc. At least that was how it
was working the last time I looked. Merlin does almost the same thing -
the only difference being that Merlin defers the start phase until after
all blocks have been initialized.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mulitple components of same ROLE
Posted by Stephen McConnell <mc...@osm.net>.
Paul Hammant wrote:
> Stephen.
>
>>> 2) We're deciding that (at least within phoenix) Realms will be
>>> configured and provided to the Authenticator as blocks.
>>
>>
>>
>> +1
>> (and I'm assuming when you say block, you actually mean a
>> component + meta-info .. which is equivalent to the notion of a block)
>
>
> It is coupled to a Phonix impl at present. Are you interested in
> using outrside of Phonix - i.e . in servlet context?
>
>>> So, if we
>>> decide to support multiple realms how do we provide multiple components
>>> that implement the same role (in this case Realm) to a Serviceable
>>> component? Or would that not be the right interface to implement?
>>
>>
>>
>> Yes and no.
>> Some possible approaches:
>>
>> 1. Create an Authenticator component that has a dependecy of a RealmSet
>> component. The RealSet establishes the realms using whatever
>> implementation magic it likes (via configuration info, via dynamic
>> lookup of available realms in a directory or file-system, etc).
>> The kernel will supply the RealmSet to the Authenticator based on the
>> dependecies you declare.
>
>
> The trouble is that in terms of lifecycle, service(..) is called for
> all blocks before configure(..) is for all blocks.
> If it is to take configurable realm class names it would have to be a
> custom impl.
>
> - Paul
That ok - if you have component RealmSet, it get pipelined through its
lifecycle and as a result is ready to provide access to Realms by any
component that has declared a dependecy on it. In the above example the
service() invocation is relative to the Authenticator wheras the
configuration action is relative to the RealmSet.
Steve.
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mulitple components of same ROLE
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen.
>> 2) We're deciding that (at least within phoenix) Realms will be
>> configured and provided to the Authenticator as blocks.
>
>
> +1
> (and I'm assuming when you say block, you actually mean a
> component + meta-info .. which is equivalent to the notion of a block)
It is coupled to a Phonix impl at present. Are you interested in using
outrside of Phonix - i.e . in servlet context?
>> So, if we
>> decide to support multiple realms how do we provide multiple components
>> that implement the same role (in this case Realm) to a Serviceable
>> component? Or would that not be the right interface to implement?
>
>
> Yes and no.
> Some possible approaches:
>
> 1. Create an Authenticator component that has a dependecy of a RealmSet
> component. The RealSet establishes the realms using whatever
> implementation magic it likes (via configuration info, via dynamic
> lookup of available realms in a directory or file-system, etc).
> The kernel will supply the RealmSet to the Authenticator based on the
> dependecies you declare.
The trouble is that in terms of lifecycle, service(..) is called for all
blocks before configure(..) is for all blocks.
If it is to take configurable realm class names it would have to be a
custom impl.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mulitple components of same ROLE
Posted by Stephen McConnell <mc...@osm.net>.
Richard Wallace wrote:
>Hey guys,
>
>I've been working with Larry on a AAA
>(Authentication/Authorization/Auditing) framework for cornerstone. One
>of the things that we're discussing is if we should have support for
>multiple Realms similar to the way PAM and JAAS have multiple
>LoginModules. I'm thinking that it would be similar in function to the
>way JAAS does it, but alleviates the need for relying on the JAAS API
>and creating a JAASRealm that would have to be used to get this feature.
>
>I have two questions about this, I guess:
>1) Does this sound like a feature people would be interested in? If
>there isn't a lot of need for it we'll put it on the back burner and
>maybe write an implementation later that will support it.
>
Yes, I'm iunterested in seeing multiple realms.
>2) We're deciding that (at least within phoenix) Realms will be
>configured and provided to the Authenticator as blocks.
>
+1
(and I'm assuming when you say block, you actually mean a
component + meta-info .. which is equivalent to the notion of a block)
>So, if we
>decide to support multiple realms how do we provide multiple components
>that implement the same role (in this case Realm) to a Serviceable
>component? Or would that not be the right interface to implement?
>
Yes and no.
Some possible approaches:
1. Create an Authenticator component that has a dependecy of a RealmSet
component. The RealSet establishes the realms using whatever
implementation magic it likes (via configuration info, via dynamic
lookup of available realms in a directory or file-system, etc).
The kernel will supply the RealmSet to the Authenticator based on the
dependecies you declare.
2. If is a pure Phoenix environment, then you could use a block listener
aggregate the set of realms and wire these to the Authenticator.
My preference would be for option 1.
>
>What, other than Serviceable, should it become to accomplish this?
>
Serviceable is what you should be using if you declare dependecies - the
quetion is - are yuou declaring a dependecy on a single realm, or a
component that enables you to select one or more realms.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mulitple components of same ROLE
Posted by Richard Wallace <rw...@a--i--m.com>.
Hey everybody!
Thanks for the responses guys. Larry and I have decided to put this on
the back burner until we get the framework into a more usable state.
We'll readdress it then since there is a need/desire for it. Maybe by
then there will be a better way to go about getting the multiple
realms. If not, I think Paul and Stephen have given some valuable ideas
on how to go about it (I like the RealmSet... it's along the same lines
as I was thinking if there wasn't another way to do it).
Thanks
Rich
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mulitple components of same ROLE
Posted by Paul Hammant <Pa...@yahoo.com>.
Richard,
>That was something I had considered. The thing about that solution is
>that it is impossible to have two components that have the same ROLE.
>For instance, someone (not necessarily me, I'm just trying to think
>ahead) might want to have two instances of a JNDIRealm that make use of
>two different directories to do the validation. I think what I was
>hoping for was a lookupAll() method or something similar in concept.
>
>
-> Object[] lookupAll(String role) throws ServiceException;
Interesting. The assembly.xml consequences would be too. Currently
Phoenix barfs when it finds multiple provision of roles.
Expanding my previous suggestion for a delegate to solve your
think-ahead scenario, I think that coder would have to write their own
delegate to enable 'merged JNDI realm' functionality. There comes a
time when an assembler says 'I can't do this' an commissions some dev
work for a block for niche cases like this.
Thoughts?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mulitple components of same ROLE
Posted by Richard Wallace <rw...@a--i--m.com>.
On Wed, 2002-06-05 at 21:40, Paul Hammant wrote:
> Richard,
>
> Multi-realm ideas are great lads :-)
>
> >So, if we
> >decide to support multiple realms how do we provide multiple components
> >that implement the same role (in this case Realm) to a Serviceable
> >component? Or would that not be the right interface to implement?
> >What, other than Serviceable, should it become to accomplish this?
> >
> Well here is an idea....
>
> Have a RealmDelegate block - it is the thing that implements the
> "org.apache.avalon.cornerstone.services.security.Realm" ROLE
>
> It has multiple implementations : JAASRealmDelegate, PAMRealDelegate &
> JAASnPAMRealmDelegate. These probably share a parent class (some
> glorified hashmap). The trick is that each hasa different service(..)
> method and looks up more strongly typed services as their class name
> would hint :
>
> class JAASnPAMRealmDelegate extends AbstractRealmDelegate {
> public void service(ServiceManager sm) throws ServiceException{
>
> realmMap.add("jaas",sm.lookup("org.apache.avalon.cornerstone.services.security.Realm:JAAS"));
>
> realmMap.add("pam",sm.lookup("org.apache.avalon.cornerstone.services.security.Realm:PAM"));
> }
> }
>
> This solution, if it is workable, is based on the fact that ROLE need
> not be a class name, it is just a string that si expected to have some
> theme.
>
> - Paul
That was something I had considered. The thing about that solution is
that it is impossible to have two components that have the same ROLE.
For instance, someone (not necessarily me, I'm just trying to think
ahead) might want to have two instances of a JNDIRealm that make use of
two different directories to do the validation. I think what I was
hoping for was a lookupAll() method or something similar in concept.
>
> --
> 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: Mulitple components of same ROLE
Posted by Paul Hammant <Pa...@yahoo.com>.
Richard,
Multi-realm ideas are great lads :-)
>So, if we
>decide to support multiple realms how do we provide multiple components
>that implement the same role (in this case Realm) to a Serviceable
>component? Or would that not be the right interface to implement?
>What, other than Serviceable, should it become to accomplish this?
>
Well here is an idea....
Have a RealmDelegate block - it is the thing that implements the
"org.apache.avalon.cornerstone.services.security.Realm" ROLE
It has multiple implementations : JAASRealmDelegate, PAMRealDelegate &
JAASnPAMRealmDelegate. These probably share a parent class (some
glorified hashmap). The trick is that each hasa different service(..)
method and looks up more strongly typed services as their class name
would hint :
class JAASnPAMRealmDelegate extends AbstractRealmDelegate {
public void service(ServiceManager sm) throws ServiceException{
realmMap.add("jaas",sm.lookup("org.apache.avalon.cornerstone.services.security.Realm:JAAS"));
realmMap.add("pam",sm.lookup("org.apache.avalon.cornerstone.services.security.Realm:PAM"));
}
}
This solution, if it is workable, is based on the fact that ROLE need
not be a class name, it is just a string that si expected to have some
theme.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mulitple components of same ROLE
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter
>> 2) We're deciding that (at least within phoenix) Realms will be
>> configured and provided to the Authenticator as blocks. So, if we
>> decide to support multiple realms how do we provide multiple components
>> that implement the same role (in this case Realm) to a Serviceable
>> component? Or would that not be the right interface to implement?
>> What, other than Serviceable, should it become to accomplish this?
>
>
> Hmm - theres actually no easy way to do this atm. In the past we
> suggested you create a RealmManager that the Authenticator would use
> to look up N different Realms.
>
> However I am currently messing around with phoenix down in that area
> so I will look at trying to fix it so that you can have multiple
> elements for the same Realm. For the moment just assume it will be
> possible but test with one realm and I will try to get around to
> fixing it ;)
Kewl..... :-)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mulitple components of same ROLE
Posted by Peter Donald <pe...@apache.org>.
At 05:58 PM 6/5/2002 -0700, you wrote:
>I've been working with Larry on a AAA
>(Authentication/Authorization/Auditing) framework for cornerstone. One
>of the things that we're discussing is if we should have support for
>multiple Realms
+1
> I have two questions about this, I guess:
>1) Does this sound like a feature people would be interested in? If
>there isn't a lot of need for it we'll put it on the back burner and
>maybe write an implementation later that will support it.
I have needed it a couple of times in the past but worked around not having
it ;) A fairly common example may be a mail server such as James. In many
cases you will want to be able to deliver mail to local users so you would
have a Realm such as UnixRealm or NTRealm etc. But you may want to also
host simple mail accounts that don't have logins on the box so you will
have another text/ldap/db realm.
So you would first check the Unix realm and if you could not find anything
there you would check the Ldap realm or whatever.
>2) We're deciding that (at least within phoenix) Realms will be
>configured and provided to the Authenticator as blocks. So, if we
>decide to support multiple realms how do we provide multiple components
>that implement the same role (in this case Realm) to a Serviceable
>component? Or would that not be the right interface to implement?
>What, other than Serviceable, should it become to accomplish this?
Hmm - theres actually no easy way to do this atm. In the past we suggested
you create a RealmManager that the Authenticator would use to look up N
different Realms.
However I am currently messing around with phoenix down in that area so I
will look at trying to fix it so that you can have multiple elements for
the same Realm. For the moment just assume it will be possible but test
with one realm and I will try to get around to fixing it ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>