Hi Guillaume,
My previous e-mail gathers two topic:
1/ thanks for the reminder about <jaas:config/> blueprint file. We
should definitely document that.
2/ You have understood the need. For the end users, the current JAAS
configuration is a little bit hidden. In the
etc/org.apache.karaf.jaas.cfg file, he can only tune the encryption etc,
but not really tune the login module in use. My purpose is to provide a
clean overview to the users about the current JAAS configuration and be
able to tune the login modules, add new one, delete existing, etc.
Thanks
Regards
JB
On 01/31/2011 01:45 PM, Guillaume Nodet wrote:
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
