You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Aki Yoshida <el...@googlemail.com> on 2012/07/04 12:59:26 UTC
more flexibility in configuring httpconduit's tlsClientParameters in
spring or blueprint?
Hi,
I haven been wondering about this for a while and I would like to hear
your thoughts.
Concretely, I am wondering if people are happy with the current file
or resource based keystore instantiation provided by the
tlsClientParameters's configuration schema. The current schema does
not allow any bean referencing from within that structure. So, using
the http's spring or blueprint namespace handlers that are based on
this schema, you need to configure this entire structure. This makes
it difficult to use this configuration handler If you have your own
mechanism to get keystores and you can provide it as a bean or
factory-bean reference.
In such cases, one could directly configure the httpConduit and its
tlsClientParameter as beans directly. Unfortunately, this doesn't work
in blueprint because the blueprint bean element does not have the name
attribute that can be used to configure the conduit's matching
pattern. So, this is not practical. Besides, I think it's pain to
configure beans directly when the specific namespace handlers are
available.
So what are the options? Is this an unusual use case? If this is not
an unusual use case, should we add the reference attribute in some of
those elements so that these can be optionally configured separately
and referenced?
Your comments are appreciated.
Thanks.
Regards, Aki
Re: more flexibility in configuring httpconduit's tlsClientParameters
in spring or blueprint?
Posted by Aki Yoshida <el...@gmail.com>.
2012/7/16 Sergey Beryozkin <sb...@gmail.com>:
> On 13/07/12 18:35, Aki Yoshida wrote:
>>
>> Hi,
>>
>> I just submitted the code with CXF-4423 into trunk. Currently, it has
>> only the spring support and the blueprint support is to follow.
>>
>> Basically, you can do something like:
>> <bean id="keyManagers" .../>
>> <bean id="trustManagers" .../>
>>
>> <http:conduit
>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>> <http:tlsClientParameters>
>> <sec:keyManagers ref="keyManagers"/>
>> <sec:trustManagers ref="trustManagers"/>
>> <sec:cipherSuitesFilter>
>> ...
>> Is this syntax okay? Alternatively, we could add the keyMangersRef and
>> trustMangersRef attributes within tlsClientParameters and not use the
>> keyManagers and trustManagers elements in this case. But I thought the
>> ref attribute within the keyManagers/trustManagers elements didn't
>> look bad.
>
>
> IMHO it looks fine, I guess the individual stores can be represented as bean
> references too if required
>
Hi Sergey,
thanks for your feedback. Going deeper in the structure (to also make
the keystores also to be referenced individually) requires a more
namespace handler code and more changes to the schema. So, I think we
can leave it out and stay with this syntax.
regards, aki
> Sergey
>
>
>>
>> regards, aki
>>
>>
>> 2012/7/6 Freeman Fang<fr...@gmail.com>:
>>>
>>> Sounds good to me, +1
>>>
>>> Freeman
>>>
>>> On 2012-7-5, at 下午10:28, Willem Jiang wrote:
>>>
>>>> +1，it makes our life easier to share the security parameter beans across
>>>> the http conduit.
>>>> On Thu Jul 5 19:09:57 2012, Sergey Beryozkin wrote:
>>>>>
>>>>>
>>>>> Hi Aki,
>>>>> On 05/07/12 11:58, Aki Yoshida wrote:
>>>>>>
>>>>>>
>>>>>> 2012/7/5 Sergey Beryozkin<sb...@gmail.com>:
>>>>>>>
>>>>>>>
>>>>>>> Hi Aki
>>>>>>>
>>>>>>> On 04/07/12 11:59, Aki Yoshida wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I haven been wondering about this for a while and I would like to
>>>>>>>> hear
>>>>>>>> your thoughts.
>>>>>>>>
>>>>>>>> Concretely, I am wondering if people are happy with the current file
>>>>>>>> or resource based keystore instantiation provided by the
>>>>>>>> tlsClientParameters's configuration schema. The current schema does
>>>>>>>> not allow any bean referencing from within that structure. So, using
>>>>>>>> the http's spring or blueprint namespace handlers that are based on
>>>>>>>> this schema, you need to configure this entire structure. This makes
>>>>>>>> it difficult to use this configuration handler If you have your own
>>>>>>>> mechanism to get keystores and you can provide it as a bean or
>>>>>>>> factory-bean reference.
>>>>>>>>
>>>>>>>> In such cases, one could directly configure the httpConduit and its
>>>>>>>> tlsClientParameter as beans directly. Unfortunately, this doesn't
>>>>>>>> work
>>>>>>>> in blueprint because the blueprint bean element does not have the
>>>>>>>> name
>>>>>>>> attribute that can be used to configure the conduit's matching
>>>>>>>> pattern. So, this is not practical. Besides, I think it's pain to
>>>>>>>> configure beans directly when the specific namespace handlers are
>>>>>>>> available.
>>>>>>>>
>>>>>>>> So what are the options? Is this an unusual use case? If this is
>>>>>>>> not
>>>>>>>> an unusual use case, should we add the reference attribute in some
>>>>>>>> of
>>>>>>>> those elements so that these can be optionally configured separately
>>>>>>>> and referenced?
>>>>>>>>
>>>>>>>> Your comments are appreciated.
>>>>>>>>
>>>>>>>
>>>>>>> I've had a chance to deal with tlsClientParameters few days ago,
>>>>>>> I've seen
>>>>>>> the examples of the references like
>>>>>>> <sec:keyStore type="JKS" password="sspass"
>>>>>>> url="mtprotocol://mystorejks"/>
>>>>>>>
>>>>>>> Are you thinking of having something like
>>>>>>>
>>>>>>> ref="mybean" ? I guess it makes sense, we'd probably need to have
>>>>>>> some
>>>>>>> interface like KeyResourceStore introduced, sorry if I misunderstood
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Sergey,
>>>>>>
>>>>>> yes. I was thinking about introducing an optional ref attribute in
>>>>>> some suitable places to do ref="mybean".
>>>>>> Here are some examples.
>>>>>>
>>>>>> The current configuration looks like this:
>>>>>> <http:conduit
>>>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>>>> <http:tlsClientParameters>
>>>>>> <sec:keyManagers keyPassword="password">
>>>>>> <sec:keyStore type="JKS" password="password"
>>>>>> file="my/file/dir/Morpit.jks"/>
>>>>>> </sec:keyManagers>
>>>>>> <sec:trustManagers>
>>>>>> <sec:keyStore type="JKS" password="password"
>>>>>> file="my/file/dir/Truststore.jks"/>
>>>>>> </sec:trustManagers>
>>>>>> ...
>>>>>>
>>>>>> Depending on where we allow this optional ref attribute, we could have
>>>>>> several variations in referencing.
>>>>>>
>>>>>> For example, we could allow this attribute in the root level as in
>>>>>> <http:conduit
>>>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>>>> <http:tlsClientParameters ref="mytlsbean">
>>>>>> ...
>>>>>> In this case, you could configure this bean directly and setting each
>>>>>> of its bean attributes. This may not be very convenient, but it is
>>>>>> simple and does not require any schema changes to its sub components.
>>>>>>
>>>>>> or we could allow the ref attribute in the key/trustManagers level,
>>>>>> as in
>>>>>> <http:conduit
>>>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>>>> <http:tlsClientParameters>
>>>>>> <sec:keyManagers ref="mykeymanagersbean"/>
>>>>>> <sec:trustManagers ref="mytrustmanagersbean"/>
>>>>>> ...
>>>>>>
>>>>>> or in the keystore level:
>>>>>> <http:conduit
>>>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>>>> <http:tlsClientParameters>
>>>>>> <sec:keyManagers keyPassword="password">
>>>>>> <sec:keyStore ref="mykeystorebean"/>
>>>>>> ...
>>>>>>
>>>>>> I would like to hear if people want to have something like these.
>>>>>
>>>>>
>>>>>
>>>>> IMHO both options look good, +1 from me
>>>>>
>>>>> Thanks, Sergey
>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Regards, aki
>>>>>>
>>>>>>
>>>>>>> Cheers, Sergey
>>>>>>>
>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Regards, Aki
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sergey Beryozkin
>>>>>>>
>>>>>>> Talend Community Coders
>>>>>>> http://coders.talend.com/
>>>>>>>
>>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Willem
>>>> ----------------------------------
>>>> FuseSource
>>>> Web: http://www.fusesource.com
>>>> Blog: http://willemjiang.blogspot.com (English)
>>>> http://jnn.javaeye.com (Chinese)
>>>> Twitter: willemjiang
>>>> Weibo: willemjiang
>>>>
>>>
>>> ---------------------------------------------
>>> Freeman Fang
>>>
>>> FuseSource
>>> Email:ffang@fusesource.com
>>> Web: fusesource.com
>>> Twitter: freemanfang
>>> Blog: http://freemanfang.blogspot.com
>>> http://blog.sina.com.cn/u/1473905042
>>> weibo: http://weibo.com/u/1473905042
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
Re: more flexibility in configuring httpconduit's tlsClientParameters
in spring or blueprint?
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 13/07/12 18:35, Aki Yoshida wrote:
> Hi,
> I just submitted the code with CXF-4423 into trunk. Currently, it has
> only the spring support and the blueprint support is to follow.
>
> Basically, you can do something like:
> <bean id="keyManagers" .../>
> <bean id="trustManagers" .../>
>
> <http:conduit
> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
> <http:tlsClientParameters>
> <sec:keyManagers ref="keyManagers"/>
> <sec:trustManagers ref="trustManagers"/>
> <sec:cipherSuitesFilter>
> ...
> Is this syntax okay? Alternatively, we could add the keyMangersRef and
> trustMangersRef attributes within tlsClientParameters and not use the
> keyManagers and trustManagers elements in this case. But I thought the
> ref attribute within the keyManagers/trustManagers elements didn't
> look bad.
IMHO it looks fine, I guess the individual stores can be represented as
bean references too if required
Sergey
>
> regards, aki
>
>
> 2012/7/6 Freeman Fang<fr...@gmail.com>:
>> Sounds good to me, +1
>>
>> Freeman
>>
>> On 2012-7-5, at 下午10:28, Willem Jiang wrote:
>>
>>> +1，it makes our life easier to share the security parameter beans across
>>> the http conduit.
>>> On Thu Jul 5 19:09:57 2012, Sergey Beryozkin wrote:
>>>>
>>>> Hi Aki,
>>>> On 05/07/12 11:58, Aki Yoshida wrote:
>>>>>
>>>>> 2012/7/5 Sergey Beryozkin<sb...@gmail.com>:
>>>>>>
>>>>>> Hi Aki
>>>>>>
>>>>>> On 04/07/12 11:59, Aki Yoshida wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>> I haven been wondering about this for a while and I would like to hear
>>>>>>> your thoughts.
>>>>>>>
>>>>>>> Concretely, I am wondering if people are happy with the current file
>>>>>>> or resource based keystore instantiation provided by the
>>>>>>> tlsClientParameters's configuration schema. The current schema does
>>>>>>> not allow any bean referencing from within that structure. So, using
>>>>>>> the http's spring or blueprint namespace handlers that are based on
>>>>>>> this schema, you need to configure this entire structure. This makes
>>>>>>> it difficult to use this configuration handler If you have your own
>>>>>>> mechanism to get keystores and you can provide it as a bean or
>>>>>>> factory-bean reference.
>>>>>>>
>>>>>>> In such cases, one could directly configure the httpConduit and its
>>>>>>> tlsClientParameter as beans directly. Unfortunately, this doesn't work
>>>>>>> in blueprint because the blueprint bean element does not have the name
>>>>>>> attribute that can be used to configure the conduit's matching
>>>>>>> pattern. So, this is not practical. Besides, I think it's pain to
>>>>>>> configure beans directly when the specific namespace handlers are
>>>>>>> available.
>>>>>>>
>>>>>>> So what are the options? Is this an unusual use case? If this is not
>>>>>>> an unusual use case, should we add the reference attribute in some of
>>>>>>> those elements so that these can be optionally configured separately
>>>>>>> and referenced?
>>>>>>>
>>>>>>> Your comments are appreciated.
>>>>>>>
>>>>>>
>>>>>> I've had a chance to deal with tlsClientParameters few days ago,
>>>>>> I've seen
>>>>>> the examples of the references like
>>>>>> <sec:keyStore type="JKS" password="sspass"
>>>>>> url="mtprotocol://mystorejks"/>
>>>>>>
>>>>>> Are you thinking of having something like
>>>>>>
>>>>>> ref="mybean" ? I guess it makes sense, we'd probably need to have some
>>>>>> interface like KeyResourceStore introduced, sorry if I misunderstood
>>>>>>
>>>>>
>>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> yes. I was thinking about introducing an optional ref attribute in
>>>>> some suitable places to do ref="mybean".
>>>>> Here are some examples.
>>>>>
>>>>> The current configuration looks like this:
>>>>> <http:conduit
>>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>>> <http:tlsClientParameters>
>>>>> <sec:keyManagers keyPassword="password">
>>>>> <sec:keyStore type="JKS" password="password"
>>>>> file="my/file/dir/Morpit.jks"/>
>>>>> </sec:keyManagers>
>>>>> <sec:trustManagers>
>>>>> <sec:keyStore type="JKS" password="password"
>>>>> file="my/file/dir/Truststore.jks"/>
>>>>> </sec:trustManagers>
>>>>> ...
>>>>>
>>>>> Depending on where we allow this optional ref attribute, we could have
>>>>> several variations in referencing.
>>>>>
>>>>> For example, we could allow this attribute in the root level as in
>>>>> <http:conduit
>>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>>> <http:tlsClientParameters ref="mytlsbean">
>>>>> ...
>>>>> In this case, you could configure this bean directly and setting each
>>>>> of its bean attributes. This may not be very convenient, but it is
>>>>> simple and does not require any schema changes to its sub components.
>>>>>
>>>>> or we could allow the ref attribute in the key/trustManagers level,
>>>>> as in
>>>>> <http:conduit
>>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>>> <http:tlsClientParameters>
>>>>> <sec:keyManagers ref="mykeymanagersbean"/>
>>>>> <sec:trustManagers ref="mytrustmanagersbean"/>
>>>>> ...
>>>>>
>>>>> or in the keystore level:
>>>>> <http:conduit
>>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>>> <http:tlsClientParameters>
>>>>> <sec:keyManagers keyPassword="password">
>>>>> <sec:keyStore ref="mykeystorebean"/>
>>>>> ...
>>>>>
>>>>> I would like to hear if people want to have something like these.
>>>>
>>>>
>>>> IMHO both options look good, +1 from me
>>>>
>>>> Thanks, Sergey
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Regards, aki
>>>>>
>>>>>
>>>>>> Cheers, Sergey
>>>>>>
>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Regards, Aki
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sergey Beryozkin
>>>>>>
>>>>>> Talend Community Coders
>>>>>> http://coders.talend.com/
>>>>>>
>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Willem
>>> ----------------------------------
>>> FuseSource
>>> Web: http://www.fusesource.com
>>> Blog: http://willemjiang.blogspot.com (English)
>>> http://jnn.javaeye.com (Chinese)
>>> Twitter: willemjiang
>>> Weibo: willemjiang
>>>
>>
>> ---------------------------------------------
>> Freeman Fang
>>
>> FuseSource
>> Email:ffang@fusesource.com
>> Web: fusesource.com
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> http://blog.sina.com.cn/u/1473905042
>> weibo: http://weibo.com/u/1473905042
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Re: more flexibility in configuring httpconduit's tlsClientParameters
in spring or blueprint?
Posted by Aki Yoshida <el...@googlemail.com>.
Hi,
I just submitted the code with CXF-4423 into trunk. Currently, it has
only the spring support and the blueprint support is to follow.
Basically, you can do something like:
<bean id="keyManagers" .../>
<bean id="trustManagers" .../>
<http:conduit
name="{http://apache.org/hello_world}HelloWorld.http-conduit">
<http:tlsClientParameters>
<sec:keyManagers ref="keyManagers"/>
<sec:trustManagers ref="trustManagers"/>
<sec:cipherSuitesFilter>
...
Is this syntax okay? Alternatively, we could add the keyMangersRef and
trustMangersRef attributes within tlsClientParameters and not use the
keyManagers and trustManagers elements in this case. But I thought the
ref attribute within the keyManagers/trustManagers elements didn't
look bad.
regards, aki
2012/7/6 Freeman Fang <fr...@gmail.com>:
> Sounds good to me, +1
>
> Freeman
>
> On 2012-7-5, at 下午10:28, Willem Jiang wrote:
>
>> +1，it makes our life easier to share the security parameter beans across
>> the http conduit.
>> On Thu Jul 5 19:09:57 2012, Sergey Beryozkin wrote:
>>>
>>> Hi Aki,
>>> On 05/07/12 11:58, Aki Yoshida wrote:
>>>>
>>>> 2012/7/5 Sergey Beryozkin<sb...@gmail.com>:
>>>>>
>>>>> Hi Aki
>>>>>
>>>>> On 04/07/12 11:59, Aki Yoshida wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>> I haven been wondering about this for a while and I would like to hear
>>>>>> your thoughts.
>>>>>>
>>>>>> Concretely, I am wondering if people are happy with the current file
>>>>>> or resource based keystore instantiation provided by the
>>>>>> tlsClientParameters's configuration schema. The current schema does
>>>>>> not allow any bean referencing from within that structure. So, using
>>>>>> the http's spring or blueprint namespace handlers that are based on
>>>>>> this schema, you need to configure this entire structure. This makes
>>>>>> it difficult to use this configuration handler If you have your own
>>>>>> mechanism to get keystores and you can provide it as a bean or
>>>>>> factory-bean reference.
>>>>>>
>>>>>> In such cases, one could directly configure the httpConduit and its
>>>>>> tlsClientParameter as beans directly. Unfortunately, this doesn't work
>>>>>> in blueprint because the blueprint bean element does not have the name
>>>>>> attribute that can be used to configure the conduit's matching
>>>>>> pattern. So, this is not practical. Besides, I think it's pain to
>>>>>> configure beans directly when the specific namespace handlers are
>>>>>> available.
>>>>>>
>>>>>> So what are the options? Is this an unusual use case? If this is not
>>>>>> an unusual use case, should we add the reference attribute in some of
>>>>>> those elements so that these can be optionally configured separately
>>>>>> and referenced?
>>>>>>
>>>>>> Your comments are appreciated.
>>>>>>
>>>>>
>>>>> I've had a chance to deal with tlsClientParameters few days ago,
>>>>> I've seen
>>>>> the examples of the references like
>>>>> <sec:keyStore type="JKS" password="sspass"
>>>>> url="mtprotocol://mystorejks"/>
>>>>>
>>>>> Are you thinking of having something like
>>>>>
>>>>> ref="mybean" ? I guess it makes sense, we'd probably need to have some
>>>>> interface like KeyResourceStore introduced, sorry if I misunderstood
>>>>>
>>>>
>>>>
>>>> Hi Sergey,
>>>>
>>>> yes. I was thinking about introducing an optional ref attribute in
>>>> some suitable places to do ref="mybean".
>>>> Here are some examples.
>>>>
>>>> The current configuration looks like this:
>>>> <http:conduit
>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>> <http:tlsClientParameters>
>>>> <sec:keyManagers keyPassword="password">
>>>> <sec:keyStore type="JKS" password="password"
>>>> file="my/file/dir/Morpit.jks"/>
>>>> </sec:keyManagers>
>>>> <sec:trustManagers>
>>>> <sec:keyStore type="JKS" password="password"
>>>> file="my/file/dir/Truststore.jks"/>
>>>> </sec:trustManagers>
>>>> ...
>>>>
>>>> Depending on where we allow this optional ref attribute, we could have
>>>> several variations in referencing.
>>>>
>>>> For example, we could allow this attribute in the root level as in
>>>> <http:conduit
>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>> <http:tlsClientParameters ref="mytlsbean">
>>>> ...
>>>> In this case, you could configure this bean directly and setting each
>>>> of its bean attributes. This may not be very convenient, but it is
>>>> simple and does not require any schema changes to its sub components.
>>>>
>>>> or we could allow the ref attribute in the key/trustManagers level,
>>>> as in
>>>> <http:conduit
>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>> <http:tlsClientParameters>
>>>> <sec:keyManagers ref="mykeymanagersbean"/>
>>>> <sec:trustManagers ref="mytrustmanagersbean"/>
>>>> ...
>>>>
>>>> or in the keystore level:
>>>> <http:conduit
>>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>>> <http:tlsClientParameters>
>>>> <sec:keyManagers keyPassword="password">
>>>> <sec:keyStore ref="mykeystorebean"/>
>>>> ...
>>>>
>>>> I would like to hear if people want to have something like these.
>>>
>>>
>>> IMHO both options look good, +1 from me
>>>
>>> Thanks, Sergey
>>>
>>>>
>>>> Thanks.
>>>>
>>>> Regards, aki
>>>>
>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Regards, Aki
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sergey Beryozkin
>>>>>
>>>>> Talend Community Coders
>>>>> http://coders.talend.com/
>>>>>
>>>>> Blog: http://sberyozkin.blogspot.com
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Willem
>> ----------------------------------
>> FuseSource
>> Web: http://www.fusesource.com
>> Blog: http://willemjiang.blogspot.com (English)
>> http://jnn.javaeye.com (Chinese)
>> Twitter: willemjiang
>> Weibo: willemjiang
>>
>
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> http://blog.sina.com.cn/u/1473905042
> weibo: http://weibo.com/u/1473905042
>
>
>
>
>
>
>
>
>
>
Re: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
Posted by Freeman Fang <fr...@gmail.com>.
Sounds good to me, +1
Freeman
On 2012-7-5, at 下午10:28, Willem Jiang wrote:
> +1，it makes our life easier to share the security parameter beans
> across the http conduit.
> On Thu Jul 5 19:09:57 2012, Sergey Beryozkin wrote:
>> Hi Aki,
>> On 05/07/12 11:58, Aki Yoshida wrote:
>>> 2012/7/5 Sergey Beryozkin<sb...@gmail.com>:
>>>> Hi Aki
>>>>
>>>> On 04/07/12 11:59, Aki Yoshida wrote:
>>>>>
>>>>> Hi,
>>>>> I haven been wondering about this for a while and I would like
>>>>> to hear
>>>>> your thoughts.
>>>>>
>>>>> Concretely, I am wondering if people are happy with the current
>>>>> file
>>>>> or resource based keystore instantiation provided by the
>>>>> tlsClientParameters's configuration schema. The current schema
>>>>> does
>>>>> not allow any bean referencing from within that structure. So,
>>>>> using
>>>>> the http's spring or blueprint namespace handlers that are based
>>>>> on
>>>>> this schema, you need to configure this entire structure. This
>>>>> makes
>>>>> it difficult to use this configuration handler If you have your
>>>>> own
>>>>> mechanism to get keystores and you can provide it as a bean or
>>>>> factory-bean reference.
>>>>>
>>>>> In such cases, one could directly configure the httpConduit and
>>>>> its
>>>>> tlsClientParameter as beans directly. Unfortunately, this
>>>>> doesn't work
>>>>> in blueprint because the blueprint bean element does not have
>>>>> the name
>>>>> attribute that can be used to configure the conduit's matching
>>>>> pattern. So, this is not practical. Besides, I think it's pain to
>>>>> configure beans directly when the specific namespace handlers are
>>>>> available.
>>>>>
>>>>> So what are the options? Is this an unusual use case? If this
>>>>> is not
>>>>> an unusual use case, should we add the reference attribute in
>>>>> some of
>>>>> those elements so that these can be optionally configured
>>>>> separately
>>>>> and referenced?
>>>>>
>>>>> Your comments are appreciated.
>>>>>
>>>>
>>>> I've had a chance to deal with tlsClientParameters few days ago,
>>>> I've seen
>>>> the examples of the references like
>>>> <sec:keyStore type="JKS" password="sspass"
>>>> url="mtprotocol://mystorejks"/>
>>>>
>>>> Are you thinking of having something like
>>>>
>>>> ref="mybean" ? I guess it makes sense, we'd probably need to have
>>>> some
>>>> interface like KeyResourceStore introduced, sorry if I
>>>> misunderstood
>>>>
>>>
>>>
>>> Hi Sergey,
>>>
>>> yes. I was thinking about introducing an optional ref attribute in
>>> some suitable places to do ref="mybean".
>>> Here are some examples.
>>>
>>> The current configuration looks like this:
>>> <http:conduit
>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>> <http:tlsClientParameters>
>>> <sec:keyManagers keyPassword="password">
>>> <sec:keyStore type="JKS" password="password"
>>> file="my/file/dir/Morpit.jks"/>
>>> </sec:keyManagers>
>>> <sec:trustManagers>
>>> <sec:keyStore type="JKS" password="password"
>>> file="my/file/dir/Truststore.jks"/>
>>> </sec:trustManagers>
>>> ...
>>>
>>> Depending on where we allow this optional ref attribute, we could
>>> have
>>> several variations in referencing.
>>>
>>> For example, we could allow this attribute in the root level as in
>>> <http:conduit
>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>> <http:tlsClientParameters ref="mytlsbean">
>>> ...
>>> In this case, you could configure this bean directly and setting
>>> each
>>> of its bean attributes. This may not be very convenient, but it is
>>> simple and does not require any schema changes to its sub
>>> components.
>>>
>>> or we could allow the ref attribute in the key/trustManagers level,
>>> as in
>>> <http:conduit
>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>> <http:tlsClientParameters>
>>> <sec:keyManagers ref="mykeymanagersbean"/>
>>> <sec:trustManagers ref="mytrustmanagersbean"/>
>>> ...
>>>
>>> or in the keystore level:
>>> <http:conduit
>>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>>> <http:tlsClientParameters>
>>> <sec:keyManagers keyPassword="password">
>>> <sec:keyStore ref="mykeystorebean"/>
>>> ...
>>>
>>> I would like to hear if people want to have something like these.
>>
>> IMHO both options look good, +1 from me
>>
>> Thanks, Sergey
>>
>>>
>>> Thanks.
>>>
>>> Regards, aki
>>>
>>>
>>>> Cheers, Sergey
>>>>
>>>>
>>>>> Thanks.
>>>>>
>>>>> Regards, Aki
>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>>
>>>> Blog: http://sberyozkin.blogspot.com
>>
>>
>>
>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
Re: more flexibility in configuring httpconduit's tlsClientParameters
in spring or blueprint?
Posted by Willem Jiang <wi...@gmail.com>.
+1，it makes our life easier to share the security parameter beans
across the http conduit.
On Thu Jul 5 19:09:57 2012, Sergey Beryozkin wrote:
> Hi Aki,
> On 05/07/12 11:58, Aki Yoshida wrote:
>> 2012/7/5 Sergey Beryozkin<sb...@gmail.com>:
>>> Hi Aki
>>>
>>> On 04/07/12 11:59, Aki Yoshida wrote:
>>>>
>>>> Hi,
>>>> I haven been wondering about this for a while and I would like to hear
>>>> your thoughts.
>>>>
>>>> Concretely, I am wondering if people are happy with the current file
>>>> or resource based keystore instantiation provided by the
>>>> tlsClientParameters's configuration schema. The current schema does
>>>> not allow any bean referencing from within that structure. So, using
>>>> the http's spring or blueprint namespace handlers that are based on
>>>> this schema, you need to configure this entire structure. This makes
>>>> it difficult to use this configuration handler If you have your own
>>>> mechanism to get keystores and you can provide it as a bean or
>>>> factory-bean reference.
>>>>
>>>> In such cases, one could directly configure the httpConduit and its
>>>> tlsClientParameter as beans directly. Unfortunately, this doesn't work
>>>> in blueprint because the blueprint bean element does not have the name
>>>> attribute that can be used to configure the conduit's matching
>>>> pattern. So, this is not practical. Besides, I think it's pain to
>>>> configure beans directly when the specific namespace handlers are
>>>> available.
>>>>
>>>> So what are the options? Is this an unusual use case? If this is not
>>>> an unusual use case, should we add the reference attribute in some of
>>>> those elements so that these can be optionally configured separately
>>>> and referenced?
>>>>
>>>> Your comments are appreciated.
>>>>
>>>
>>> I've had a chance to deal with tlsClientParameters few days ago,
>>> I've seen
>>> the examples of the references like
>>> <sec:keyStore type="JKS" password="sspass"
>>> url="mtprotocol://mystorejks"/>
>>>
>>> Are you thinking of having something like
>>>
>>> ref="mybean" ? I guess it makes sense, we'd probably need to have some
>>> interface like KeyResourceStore introduced, sorry if I misunderstood
>>>
>>
>>
>> Hi Sergey,
>>
>> yes. I was thinking about introducing an optional ref attribute in
>> some suitable places to do ref="mybean".
>> Here are some examples.
>>
>> The current configuration looks like this:
>> <http:conduit
>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>> <http:tlsClientParameters>
>> <sec:keyManagers keyPassword="password">
>> <sec:keyStore type="JKS" password="password"
>> file="my/file/dir/Morpit.jks"/>
>> </sec:keyManagers>
>> <sec:trustManagers>
>> <sec:keyStore type="JKS" password="password"
>> file="my/file/dir/Truststore.jks"/>
>> </sec:trustManagers>
>> ...
>>
>> Depending on where we allow this optional ref attribute, we could have
>> several variations in referencing.
>>
>> For example, we could allow this attribute in the root level as in
>> <http:conduit
>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>> <http:tlsClientParameters ref="mytlsbean">
>> ...
>> In this case, you could configure this bean directly and setting each
>> of its bean attributes. This may not be very convenient, but it is
>> simple and does not require any schema changes to its sub components.
>>
>> or we could allow the ref attribute in the key/trustManagers level,
>> as in
>> <http:conduit
>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>> <http:tlsClientParameters>
>> <sec:keyManagers ref="mykeymanagersbean"/>
>> <sec:trustManagers ref="mytrustmanagersbean"/>
>> ...
>>
>> or in the keystore level:
>> <http:conduit
>> name="{http://apache.org/hello_world}HelloWorld.http-conduit">
>> <http:tlsClientParameters>
>> <sec:keyManagers keyPassword="password">
>> <sec:keyStore ref="mykeystorebean"/>
>> ...
>>
>> I would like to hear if people want to have something like these.
>
> IMHO both options look good, +1 from me
>
> Thanks, Sergey
>
>>
>> Thanks.
>>
>> Regards, aki
>>
>>
>>> Cheers, Sergey
>>>
>>>
>>>> Thanks.
>>>>
>>>> Regards, Aki
>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>>
>>> Blog: http://sberyozkin.blogspot.com
>
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: more flexibility in configuring httpconduit's tlsClientParameters
in spring or blueprint?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki,
On 05/07/12 11:58, Aki Yoshida wrote:
> 2012/7/5 Sergey Beryozkin<sb...@gmail.com>:
>> Hi Aki
>>
>> On 04/07/12 11:59, Aki Yoshida wrote:
>>>
>>> Hi,
>>> I haven been wondering about this for a while and I would like to hear
>>> your thoughts.
>>>
>>> Concretely, I am wondering if people are happy with the current file
>>> or resource based keystore instantiation provided by the
>>> tlsClientParameters's configuration schema. The current schema does
>>> not allow any bean referencing from within that structure. So, using
>>> the http's spring or blueprint namespace handlers that are based on
>>> this schema, you need to configure this entire structure. This makes
>>> it difficult to use this configuration handler If you have your own
>>> mechanism to get keystores and you can provide it as a bean or
>>> factory-bean reference.
>>>
>>> In such cases, one could directly configure the httpConduit and its
>>> tlsClientParameter as beans directly. Unfortunately, this doesn't work
>>> in blueprint because the blueprint bean element does not have the name
>>> attribute that can be used to configure the conduit's matching
>>> pattern. So, this is not practical. Besides, I think it's pain to
>>> configure beans directly when the specific namespace handlers are
>>> available.
>>>
>>> So what are the options? Is this an unusual use case? If this is not
>>> an unusual use case, should we add the reference attribute in some of
>>> those elements so that these can be optionally configured separately
>>> and referenced?
>>>
>>> Your comments are appreciated.
>>>
>>
>> I've had a chance to deal with tlsClientParameters few days ago, I've seen
>> the examples of the references like
>> <sec:keyStore type="JKS" password="sspass"
>> url="mtprotocol://mystorejks"/>
>>
>> Are you thinking of having something like
>>
>> ref="mybean" ? I guess it makes sense, we'd probably need to have some
>> interface like KeyResourceStore introduced, sorry if I misunderstood
>>
>
>
> Hi Sergey,
>
> yes. I was thinking about introducing an optional ref attribute in
> some suitable places to do ref="mybean".
> Here are some examples.
>
> The current configuration looks like this:
> <http:conduit name="{http://apache.org/hello_world}HelloWorld.http-conduit">
> <http:tlsClientParameters>
> <sec:keyManagers keyPassword="password">
> <sec:keyStore type="JKS" password="password"
> file="my/file/dir/Morpit.jks"/>
> </sec:keyManagers>
> <sec:trustManagers>
> <sec:keyStore type="JKS" password="password"
> file="my/file/dir/Truststore.jks"/>
> </sec:trustManagers>
> ...
>
> Depending on where we allow this optional ref attribute, we could have
> several variations in referencing.
>
> For example, we could allow this attribute in the root level as in
> <http:conduit name="{http://apache.org/hello_world}HelloWorld.http-conduit">
> <http:tlsClientParameters ref="mytlsbean">
> ...
> In this case, you could configure this bean directly and setting each
> of its bean attributes. This may not be very convenient, but it is
> simple and does not require any schema changes to its sub components.
>
> or we could allow the ref attribute in the key/trustManagers level, as in
> <http:conduit name="{http://apache.org/hello_world}HelloWorld.http-conduit">
> <http:tlsClientParameters>
> <sec:keyManagers ref="mykeymanagersbean"/>
> <sec:trustManagers ref="mytrustmanagersbean"/>
> ...
>
> or in the keystore level:
> <http:conduit name="{http://apache.org/hello_world}HelloWorld.http-conduit">
> <http:tlsClientParameters>
> <sec:keyManagers keyPassword="password">
> <sec:keyStore ref="mykeystorebean"/>
> ...
>
> I would like to hear if people want to have something like these.
IMHO both options look good, +1 from me
Thanks, Sergey
>
> Thanks.
>
> Regards, aki
>
>
>> Cheers, Sergey
>>
>>
>>> Thanks.
>>>
>>> Regards, Aki
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
Re: more flexibility in configuring httpconduit's tlsClientParameters
in spring or blueprint?
Posted by Aki Yoshida <el...@googlemail.com>.
2012/7/5 Sergey Beryozkin <sb...@gmail.com>:
> Hi Aki
>
> On 04/07/12 11:59, Aki Yoshida wrote:
>>
>> Hi,
>> I haven been wondering about this for a while and I would like to hear
>> your thoughts.
>>
>> Concretely, I am wondering if people are happy with the current file
>> or resource based keystore instantiation provided by the
>> tlsClientParameters's configuration schema. The current schema does
>> not allow any bean referencing from within that structure. So, using
>> the http's spring or blueprint namespace handlers that are based on
>> this schema, you need to configure this entire structure. This makes
>> it difficult to use this configuration handler If you have your own
>> mechanism to get keystores and you can provide it as a bean or
>> factory-bean reference.
>>
>> In such cases, one could directly configure the httpConduit and its
>> tlsClientParameter as beans directly. Unfortunately, this doesn't work
>> in blueprint because the blueprint bean element does not have the name
>> attribute that can be used to configure the conduit's matching
>> pattern. So, this is not practical. Besides, I think it's pain to
>> configure beans directly when the specific namespace handlers are
>> available.
>>
>> So what are the options? Is this an unusual use case? If this is not
>> an unusual use case, should we add the reference attribute in some of
>> those elements so that these can be optionally configured separately
>> and referenced?
>>
>> Your comments are appreciated.
>>
>
> I've had a chance to deal with tlsClientParameters few days ago, I've seen
> the examples of the references like
> <sec:keyStore type="JKS" password="sspass"
> url="mtprotocol://mystorejks"/>
>
> Are you thinking of having something like
>
> ref="mybean" ? I guess it makes sense, we'd probably need to have some
> interface like KeyResourceStore introduced, sorry if I misunderstood
>
Hi Sergey,
yes. I was thinking about introducing an optional ref attribute in
some suitable places to do ref="mybean".
Here are some examples.
The current configuration looks like this:
<http:conduit name="{http://apache.org/hello_world}HelloWorld.http-conduit">
<http:tlsClientParameters>
<sec:keyManagers keyPassword="password">
<sec:keyStore type="JKS" password="password"
file="my/file/dir/Morpit.jks"/>
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS" password="password"
file="my/file/dir/Truststore.jks"/>
</sec:trustManagers>
...
Depending on where we allow this optional ref attribute, we could have
several variations in referencing.
For example, we could allow this attribute in the root level as in
<http:conduit name="{http://apache.org/hello_world}HelloWorld.http-conduit">
<http:tlsClientParameters ref="mytlsbean">
...
In this case, you could configure this bean directly and setting each
of its bean attributes. This may not be very convenient, but it is
simple and does not require any schema changes to its sub components.
or we could allow the ref attribute in the key/trustManagers level, as in
<http:conduit name="{http://apache.org/hello_world}HelloWorld.http-conduit">
<http:tlsClientParameters>
<sec:keyManagers ref="mykeymanagersbean"/>
<sec:trustManagers ref="mytrustmanagersbean"/>
...
or in the keystore level:
<http:conduit name="{http://apache.org/hello_world}HelloWorld.http-conduit">
<http:tlsClientParameters>
<sec:keyManagers keyPassword="password">
<sec:keyStore ref="mykeystorebean"/>
...
I would like to hear if people want to have something like these.
Thanks.
Regards, aki
> Cheers, Sergey
>
>
>> Thanks.
>>
>> Regards, Aki
>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
Re: more flexibility in configuring httpconduit's tlsClientParameters
in spring or blueprint?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki
On 04/07/12 11:59, Aki Yoshida wrote:
> Hi,
> I haven been wondering about this for a while and I would like to hear
> your thoughts.
>
> Concretely, I am wondering if people are happy with the current file
> or resource based keystore instantiation provided by the
> tlsClientParameters's configuration schema. The current schema does
> not allow any bean referencing from within that structure. So, using
> the http's spring or blueprint namespace handlers that are based on
> this schema, you need to configure this entire structure. This makes
> it difficult to use this configuration handler If you have your own
> mechanism to get keystores and you can provide it as a bean or
> factory-bean reference.
>
> In such cases, one could directly configure the httpConduit and its
> tlsClientParameter as beans directly. Unfortunately, this doesn't work
> in blueprint because the blueprint bean element does not have the name
> attribute that can be used to configure the conduit's matching
> pattern. So, this is not practical. Besides, I think it's pain to
> configure beans directly when the specific namespace handlers are
> available.
>
> So what are the options? Is this an unusual use case? If this is not
> an unusual use case, should we add the reference attribute in some of
> those elements so that these can be optionally configured separately
> and referenced?
>
> Your comments are appreciated.
>
I've had a chance to deal with tlsClientParameters few days ago, I've
seen the examples of the references like
<sec:keyStore type="JKS" password="sspass"
url="mtprotocol://mystorejks"/>
Are you thinking of having something like
ref="mybean" ? I guess it makes sense, we'd probably need to have some
interface like KeyResourceStore introduced, sorry if I misunderstood
Cheers, Sergey
> Thanks.
>
> Regards, Aki
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com