jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@apache.org>
Subject Re: Make "Whiteboard" accessible through ContentRepository
Date Thu, 13 Feb 2014 07:15:12 GMT

On Wed, Feb 12, 2014 at 11:00 PM, Chetan Mehrotra
<chetan.mehrotra@gmail.com> wrote:
> The LM would be configured in normal way only just that instead of
> using actual LM it would be passed to ProxyLoginModule which in turn
> would pass it to actual LoginModule.

I don't quite follow. can you give an example of what would be in the
jaas.conf and where you instantiate the ProxyLoginModule ?

> The reason I prefer a factory approach is that any real life
> LoginModule implementation would probably be exposing some extension
> points say mapping LDAP name to User name, extracting extra properties
> etc. Supporting such extension points is quite easy within OSGi env
> without hard coupling.

> If a LM _pull_ its dependencies then
> 1. It becomes hard to expose extension points which can be easily
> swapped/extended at runtime.
I agree.

> 2. Further looking up services from OSGi Service Registry frequently
> is not performant. So a frequent operation like Login which triggers
> frequent lookups would cause issues and something which can be avoided
good point.

regards, Toby

> On Wed, Feb 12, 2014 at 9:01 PM, Tobias Bocanegra <tripod@apache.org> wrote:
>> Hi,
>> On Tue, Feb 11, 2014 at 11:56 PM, Chetan Mehrotra
>> <chetan.mehrotra@gmail.com> wrote:
>>> To address the same problem with Felix Jaas support one can make use
>>> of LoginModuleFactory [1]. Its job is to create LoginModule instances.
>>> One example of this is JdbcLoginModuleFactory [2]. It creates
>>> JdbcLoginModule and passes on the DataSource to the LoginModule
>>> instances. So instead of LoginModule _looking up_ the DataSource
>>> service it is provided with the DataSource instance. The factory
>>> itself was _provided_ with DataSource reference via DI (via
>>> Declarative Services)
>>> To implement a similar approach in non OSGi world following approach can be used
>>> 1. Have a ProxyLoginModule like [3]. The JAAS Config would refer to
>>> this class and would be able to create it
>>> 2. Have a LoginModuleFactory LMF (custom one) which is referred to in
>>> the JAAS Config.
>>> 3. One can register a custom LMF implementation with Oak and they
>>> would be passed on to SecurityProvider
>>> 3. ProxyLoginModule determines the type of LoginModuleFactory and
>>> obtains them via Callback
>>> 4. The LMF obtained is used to create the LoginModule instance
>>> Now same LoginModule (where most of the logic reside) can be shared
>>> between OSGi and non OSGi world. Further you can even share the
>>> LoginModuleFactory (if using non OSGi stuff only).
>>> For OSGi case the LMF would be managed via DS and its dependencies
>>> provided via DS
>>> For non OSGi case host application would wire up the LMF with its
>>> dependencies (via setters) and then register them with the Oak
>> Interesting idea, but I think we should continue support the LM to be
>> configured via the application container (eg. via jaas.conf).
>> Regards, Toby
>>> Chetan Mehrotra
>>> [1] http://svn.apache.org/repos/asf/felix/trunk/jaas/src/main/java/org/apache/felix/jaas/LoginModuleFactory.java
>>> [2] http://svn.apache.org/repos/asf/felix/trunk/examples/jaas/lm-jdbc/src/main/java/org/apache/felix/example/jaas/jdbc/JdbcLoginModuleFactory.java
>>> [3] http://svn.apache.org/repos/asf/felix/trunk/jaas/src/main/java/org/apache/felix/jaas/boot/ProxyLoginModule.java
>>> On Wed, Feb 12, 2014 at 12:07 PM, Tobias Bocanegra <tripod@apache.org>
>>>> Hi,
>>>> On Tue, Feb 11, 2014 at 4:38 PM, Tobias Bocanegra <tripod@apache.org>
>>>>> On Tue, Feb 11, 2014 at 1:59 PM, Jukka Zitting <jukka.zitting@gmail.com>
>>>>>> On Mon, Feb 10, 2014 at 2:25 AM, Felix Meschberger <fmeschbe@adobe.com>
>>>>>>> This thread indeed raises the question, why Oak has to come up
with something (the Whiteboard)
>>>>>>> that is almost but not quite like OSGi instead of going all the
way through ?
>>>>>> This is a misunderstanding; we're not trying to reinvent OSGi.
>>>>>> The Whiteboard interface is *only* an abstraction of the whiteboard
>>>>>> pattern described in
>>>>>> http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf, and is used
>>>>>> only for those cases in Oak where that pattern is useful. When running
>>>>>> in an OSGi environment, the Whiteboard simply leverages the existing
>>>>>> OSGi functionality.
>>>>>> The Whiteboard in Oak is not a generic service registry, and is not
>>>>>> supposed to become one.
>>>>> but then, why does the Whiteboard interface has a register() method?
>>>>> This indicates to me, that there is a global service registry behind
>>>>> that can be used by all other users of the whiteboard.
>>>>> Also, using the whiteboard in the tests make them very easy
>>>>> configurable and simulates a bit better how OSGi will work. for
>>>>> example in the ExternalLoginModuleTest, I can just do:
>>>>>         whiteboard = oak.getWhiteboard();
>>>>>         whiteboard.register(SyncManager.class, new
>>>>> SyncManagerImpl(whiteboard), Collections.emptyMap());
>>>>>         whiteboard.register(ExternalIdentityProviderManager.class, new
>>>>> ExternalIDPManagerImpl(whiteboard), Collections.emptyMap());
>>>>> If I need to register them with the login module, this would not work
>>>>> today, without hard wiring all possible services to the
>>>>> SecurityProvider.
>>>> addendum: If I want to achieve the same without the whiteboard, I would need
>>>> * Invent a new interface that allows to pass services/helpers to the
>>>> login modules. eg a LoginModuleService interface
>>>> * Create some sort of LoginModuleServiceProviderConfiguration
>>>> * Create an implementation of the above that deals with OSGi but also
>>>> can be used statically
>>>> * Add the LoginModuleServiceProviderConfiguration to
>>>> ServiceProvider.getConfiguration()
>>>> * Add the interface to my ExternalIDPManagerImpl and SyncManagerImpl
>>>> * in the login module, retrieve the
>>>> LoginModuleServiceProviderConfiguration from the SecurityProvider,
>>>> then find a service for SyncManager and
>>>> ExternalIdentityProviderManager
>>>> * in the non-osgi case, I would need to initialize the
>>>> LoginModuleServiceProviderConfigurationImpl myself and add the 2
>>>> services and add the config to the securityprovider.
>>>> The additional work is that I need to re-invent some sort of service
>>>> registry for the LoginModuleServiceProviderConfigurationImpl and
>>>> extend the SecurityProvider with another configuration. Also, I limit
>>>> the interfaces to be used in the LoginModules to the ones implementing
>>>> the LoginModuleService interface. you might say, this is more robust -
>>>> I say, this is just more complicated and has tighter coupling.
>>>> regards, toby

View raw message