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 13:59:00 GMT
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é <jb@nanthrax.net> 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é<jb@nanthrax.net>
>>  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é<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