Thanks a ton Guillaume !!
Regards
JB
On 01/31/2011 02:59 PM, Guillaume Nodet wrote:
I've added a section named "Configuration override and use of the rank
attribute" in the dev guide.
On Mon, Jan 31, 2011 at 14:13, Jean-Baptiste Onofré<[email protected]> wrote:
It sounds good.
Improving the manual to provide a better overview and understanding for the
users is enough for Karaf 2.2.x.
As you mentioned, I guess that deeper explanations will be better around the
ranking, etc.
We can improve and externalize the JAAS configuration for Karaf 3.x. Have we
a kind of roadmap wiki or JIRA to keep this in mind ?
Thanks
Regards
JB
On 01/31/2011 02:10 PM, Guillaume Nodet wrote:
On Mon, Jan 31, 2011 at 13:49, Jean-Baptiste Onofré<[email protected]>
wrote:
Hi Guillaume,
My previous e-mail gathers two topic:
1/ thanks for the reminder about<jaas:config/> blueprint file. We should
definitely document that.
This is partially covered in
http://karaf.apache.org/manual/2.1.99-SNAPSHOT/developers-guide/security-framework.html
but I'll enhance it to explain the use of the rank attribute and how
it can be used to override the default settings.
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.
Yeah, currently, there are two levels. The first one (modifying
encryption, users, etc..) can be done by modifying the files in etc/xx
But if you want to change the login module (configuring ldap for
example), you currently have to write a blueprint xml config file.
I don't think this is too much a problem for now, but I agree we may
want to have something simpler as I described for 3.0 maybe.
For now, I'd rather improve the current manual for 2.2.0.
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
