Hi, On Thu, Feb 13, 2014 at 8:55 AM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > Hi, > On Thu, Feb 13, 2014 at 4:11 AM, Chetan Mehrotra > <chetan.mehro...@gmail.com> wrote: >> Note here I preferred using the callback to get LM access the outer >> layer services instead of using a custom config. >> >> The custom config mode works fine in standalone case where the >> application is the sole user of JAAS system. Hence it works fine for >> Karaf/OSGi env But that might not work properly in App server env >> where app server itself uses jaas. So to avoid interfering in embedded >> mode callback should be preferred. > > The problem with using a CallbackHandler for such things is that it > forces the client code (that controls the CallbackHandler) to > understand about the LoginModule implementation. Thus you can't use > such a LoginModule with a client that relies only on the standard JAAS > API. well yes. but I think the LMs are never generic. They need to understand the host application they are running in; especially with more complex setup of different LMs. In reality, I don't think that a LM that doesn't extend from Oak's AbstractLoginModule really works great.
> As mentioned in a previous message, it's better to use the options map > that comes from the runtime environment and can thus be controlled > without touching the client code. I think both are needed. As I wrote above, I think tightly Oak coupled login modules even benefit from a fixed set of callback handlers. i.e. it is more robust to write: RepositoryCallback rcb = new RepositoryCallback(); callbackHandler.handle(new Callback[]{rcb}); securityProvider = rcb.getSecurityProvider(); than: securityProvider = options.get(SecurityProvider.class.getName()); It is more transparent to the developer what backend objects are retrievable, IMO.