Hi, On Tue, Feb 11, 2014 at 11:56 PM, Chetan Mehrotra <[email protected]> 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 <[email protected]> wrote: >> Hi, >> >> >> On Tue, Feb 11, 2014 at 4:38 PM, Tobias Bocanegra <[email protected]> wrote: >>> On Tue, Feb 11, 2014 at 1:59 PM, Jukka Zitting <[email protected]> >>> wrote: >>>> On Mon, Feb 10, 2014 at 2:25 AM, Felix Meschberger <[email protected]> >>>> wrote: >>>>> 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 >> to: >> >> * 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
