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 <freeman.f...@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<sberyoz...@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:ff...@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
>
>
>
>
>
>
>
>
>
>
