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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
