The way I thought about the JAAS thing is that users would use a different blueprint file dropped in the deploy folder. For exmaple if you deploy:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";> <jaas:config name="karaf" rank="1"> <...> </jaas:config> </blueprint> It will override the default settings, so there's no need to create a full bundle for that. I'm not completely sure to understand what you mean with the properties file. I agree we could externalize the whole configuration in a properties file similar to log4j for example: <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";> <jaas:config factory-pid="org.apache.karaf.jaas.config" /> </blueprint> This would create JAAS configurations based on ConfigAdmin factory configurations. Each configuration could contain: jaas.name = [config name] jaas.rank = [config rank] jaas.modules = [list of modules] jaas.module.[module] = [module class name] jaas.module.[module].flags = [module flags] jaas.module.[module].options.[key] = [value] So that the default one could be: jaas.name = karaf jaas.rank = 0 jaas.modules = mymodule jaas.module.mymodule = org.apache.karaf.jaas.modules.properties.PropertiesLoginModule jaas.module.mymodule.flags = required jaas.module.mymodule.options.users = ${karaf.base}/etc/users.properties jaas.module.mymodule.options.encryption.name = ${encryption.name} jaas.module.mymodule.options.encryption.prefix = ${encryption.prefix} jaas.module.mymodule.options.encryption.suffix = ${encryption.suffix} jaas.module.mymodule.options.encryption.algorithm = ${encryption.algorithm} jaas.module.mymodule.options.encryption.encoding = ${encryption.encoding} That way, users could easily change the default config or create new ones by creating a etc/org.apache.karaf.jaas.config-myconfig.cfg file. On Sun, Jan 30, 2011 at 10:27, Jean-Baptiste Onofré <[email protected]> wrote: > Hi all, > > I have some questions about the current scm repo: > > - @David: I saw that you created an assemblies module. We still have the > assembly module defined and used in the <modules/> main POM. I guess it's a > temporary situation and, after some more tests, the assemblies module will > replace the assembly module ? What about profiles implementation and > brainstorm ? > - @Achim: I saw that you added a src/main/configfiles directory (containing > a jetty.xml) in the assembly module. Why not used the > src/main/filtered-resources directory (and eventually create a new directory > in this one) or define a new sub-module ? I don't wanna split the resources > in a lot of directories. WDYT ? > > Now regarding the JAAS configuration. Correct me if I'm wrong, but up to > now, the JAAS configuration is defined in the blueprint > (OSGI-INF/blueprint/karaf-jaas-module.xml) descriptor of the jaas/modules > module: > > <jaas:config name="karaf"> > <jaas:module > className="org.apache.karaf.jaas.modules.properties.PropertiesLoginModule" > flags="required"> > users = $[karaf.base]/etc/users.properties > encryption.name = ${encryption.name} > encryption.enabled = ${encryption.enabled} > encryption.prefix = ${encryption.prefix} > encryption.suffix = ${encryption.suffix} > encryption.algorithm = ${encryption.algorithm} > encryption.encoding = ${encryption.encoding} > </jaas:module> > </jaas:config> > > So by default, we "force" the usage of the PropertiesLoginModule. > > It could be helpful for the end users to have access to a > etc/login.properties file to be able to define the login modules to use with > the policy associated (required, sufficient, optional). > For instance, we can add a property in the etc/org.apache.karaf.jaas.cfg > file to define the location of this login.properties file > (etc/login.properties by default) and reference the PropertiesLoginModule by > default. It could be more clear for the users. > > WDYT ? > > Thank > Regards > JB > > > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
