I haven't looked at your proposed code yet but from your description it sounds like you have nice solutions for all the problems I'm aware of working around the JAAS apis :-)
thanks! david jencks On Sep 28, 2012, at 1:42 AM, Chetan Mehrotra wrote: >> I would be interested in hearing what >>> the differences with the Karaf implementation are. > > Yes I had a closer look at the JAAS support present in Karaf project. > As mentioned earlier the proposed implementation borrows from both > Karaf implementation and Stefan Vladov's proposal > > Below are couple of areas where it differs from Karaf implementation > > 1. Global Configuration Handling - It should be possible to use OSGi > based JAAS support without affecting the Global configuration. For > example if a Sling app is deployed as war on an application server > then its usage of JAAS should not affect other applications running on > same App Server. The Karaf implementation currently replaces the > Global configuration. The proposed implementation uses the new > ConfigurationSpi mechanism in JDK 1.6 to provide this isolation. Refer > to 'Configuration Policy and Invocation Mode' at [1] for further > details > > 2. LoginModule Creation - The Karaf implementation currently directly > instantiates the LoginModule instance. This is similar to how normal > usage of JAAS works in non OSGi env. However to make proper use of > OSGi features it would be preferable to have some sort of LoginModule > factory which is registered in OSGi Service Registry (SR) and use > that. This allows the LoginModule provider to make better use of OSGi > by making its implementation OSGi aware. For implementations which do > not want to depend on OSGi the default approach would still work and > JAAS support would manage there creation. > > One potential example is say a LDAPLoginModule - If I have a factory > service then it would be possible for LDAPLoginModuleFactory to manage > its LDAP configuration separately. It can provide its own metadata > information for LDAP configuration which allows capturing the required > information through Felix WebConsole with proper form support (instead > of generic key value pairs). Also it helps is managing lifecycle - For > example the DatabaseLoginModule factory can create a connection pool > and provide that to LoginModule implementation. > > 3. Dependencies on other fwk - To make optimum use of Karaf JAAS > support one would have to use Blueprint Runtime. In Sling we currently > only use the Declarative Services. The proposed implementation does > not have much dependencies and only depends on OSGi Core API and > ConfigAdmin > > 4. Dynamic Realm Composition - In proposed implementation the various > LoginModule can belong to different bundles. The JAAS support would > use realm info from service properties (LoginModuleFactory) and config > to determine the realm composition at runtime. > > Chetan Mehrotra > > [1] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
