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.
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. 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 Chetan Mehrotra On Wed, Feb 12, 2014 at 9:01 PM, Tobias Bocanegra <tri...@apache.org> wrote: > Hi, > > On Tue, Feb 11, 2014 at 11:56 PM, Chetan Mehrotra > <chetan.mehro...@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 <tri...@apache.org> wrote: >>> Hi, >>> >>> >>> On Tue, Feb 11, 2014 at 4:38 PM, Tobias Bocanegra <tri...@apache.org> wrote: >>>> On Tue, Feb 11, 2014 at 1:59 PM, Jukka Zitting <jukka.zitt...@gmail.com> >>>> wrote: >>>>> On Mon, Feb 10, 2014 at 2:25 AM, Felix Meschberger <fmesc...@adobe.com> >>>>> 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
