Hi, On Wed, Feb 12, 2014 at 11:00 PM, Chetan Mehrotra <[email protected]> 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. yes. > > 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 <[email protected]> wrote: >> 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
