cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
Date Fri, 06 Jul 2012 00:20:33 GMT
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<sberyozkin@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











Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message