> 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
