karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Keep clean repo and JAAS configuration for the end-users
Date Mon, 31 Jan 2011 12:45:29 GMT
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é <jb@nanthrax.net> 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

Mime
View raw message