You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2011/01/30 10:27:44 UTC
Keep clean repo and JAAS configuration for the end-users
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
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yeah, for instance users would tune the login.properties to add MyAppAuthentication subject, not only the karaf one.
Regards
JB
-----Original Message-----
From: Andreas Pieber <an...@gmail.com>
Date: Sun, 30 Jan 2011 12:21:23
To: <de...@karaf.apache.org>
Reply-To: dev@karaf.apache.org
Subject: Re: Keep clean repo and JAAS configuration for the end-users
If blueprint supports this a big +1 (never tried this but somehow sceptical if
this works :)); I like to use the same jaas config for karaf and my application
--> If I could change the entire implementation and flags... great!
kind regards,
andreas
On Sun, Jan 30, 2011 at 10:27:44AM +0100, Jean-Baptiste Onofré 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
>
>
>
>
>
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Andreas Pieber <an...@gmail.com>.
If blueprint supports this a big +1 (never tried this but somehow sceptical if
this works :)); I like to use the same jaas config for karaf and my application
--> If I could change the entire implementation and flags... great!
kind regards,
andreas
On Sun, Jan 30, 2011 at 10:27:44AM +0100, Jean-Baptiste Onofré 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
>
>
>
>
>
Re: Keep clean repo and JAAS configuration for the end-users
Posted by David Jencks <da...@yahoo.com>.
On Jan 30, 2011, at 1:27 AM, Jean-Baptiste Onofré 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 ?
I hope this is a temporary situation -- the one assembly in assemblies now is just something to show how to set up an assembly. Although I have some high-priority unrelated problems to fix in geronimo I'll try to set up some more stuff to show how we can build profiles using these new maven packagings.
> - @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.
We've had this problem in geronimo for a long time. I think a translation of our solution into karafosgi terms would be that we have a feature that provides a named security realm service that uses a simple properties file login module. If users want they can replace this feature with another that provides a different security realm service with the same name. I don't think you can parameterize class names in blueprint, but I don't know for sure. I pretty much hope not :-)
thanks
david jencks
>
> WDYT ?
>
> Thank
> Regards
> JB
>
>
>
>
>
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é<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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Guillaume Nodet <gn...@gmail.com>.
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
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Regarding the roadmap, I remember two open discussions for now:
1/ Karaf profiles (linked with the David's current work)
2/ JAAS configuration
I have created a wiki page:
https://cwiki.apache.org/confluence/display/KARAF/Roadmap
Feel free to append some idea or open discussions.
Regards
JB
On 01/31/2011 02:13 PM, Jean-Baptiste Onofré 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Guillaume Nodet <gn...@gmail.com>.
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
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é<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
>>
>>
>>
>>
>>
>>
>
>
>
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Guillaume Nodet <gn...@gmail.com>.
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
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Achim Nierbeck <bc...@googlemail.com>.
Sounds great.
2011/1/31 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> What do you think about:
>
> src/main/resources/extras
>
> ?
>
> The resources directory filtering could be disabled.
>
> Thanks,
> Regards
> JB
>
> On 01/31/2011 09:34 AM, Achim Nierbeck wrote:
>>
>> Hi,
>>
>> I added the jetty.xml file to this directory since it needs no
>> filtering, and also isn't part of the standard distribution. This
>> file is only used in conjunction with the http feature. Therefore I
>> placed it a bit "of scope" of the standard artifacts. If there is a
>> better place to put it, we can move it there.
>>
>> Regards, Achim
>>
>>
>> 2011/1/30 Jean-Baptiste Onofré<jb...@nanthrax.net>:
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
What do you think about:
src/main/resources/extras
?
The resources directory filtering could be disabled.
Thanks,
Regards
JB
On 01/31/2011 09:34 AM, Achim Nierbeck wrote:
> Hi,
>
> I added the jetty.xml file to this directory since it needs no
> filtering, and also isn't part of the standard distribution. This
> file is only used in conjunction with the http feature. Therefore I
> placed it a bit "of scope" of the standard artifacts. If there is a
> better place to put it, we can move it there.
>
> Regards, Achim
>
>
> 2011/1/30 Jean-Baptiste Onofré<jb...@nanthrax.net>:
>> 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
>>
>>
>>
>>
>>
>>
Re: Keep clean repo and JAAS configuration for the end-users
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
I added the jetty.xml file to this directory since it needs no
filtering, and also isn't part of the standard distribution. This
file is only used in conjunction with the http feature. Therefore I
placed it a bit "of scope" of the standard artifacts. If there is a
better place to put it, we can move it there.
Regards, Achim
2011/1/30 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> 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
>
>
>
>
>
>