camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Babak Vahdat <babak.vah...@swissonline.ch>
Subject Re: XML Signature DataFormat
Date Wed, 21 Aug 2013 06:33:11 GMT
Hi

I guess as this will be part of the upcoming 2.12.0 release, the users can
make use of it as a component even if we stick to a data format
implementation:

http://camel.apache.org/dataformat-component.html

Babak


Franz Paul Forsthofer wrote
> Hi Colm,
> 
> I made the proposal with the XML Signature component. I did not implement
> it as Data Formater because I found out that the signer needs quite
> different parameters than the verifier. For example, the signer needs as
> input a signature algorithm, canonicalization methods, transformation
> methods, whereas the verifier only needs a few input parameters like
> public
> key. A Data Formater would have the same paramerters for the marschaller
> and unmarschaller available, whereas in a component the different
> endpoints
> (signer and verifier) can have different parameters. At least that's my
> understanding.
> 
> Regards Franz
> 
> 
> On Tue, Aug 20, 2013 at 5:05 PM, Colm O hEigeartaigh &lt;

> coheigea@

> &gt;wrote:
> 
>> Hi Claus,
>>
>> I hadn't actually seen that JIRA when I wrote my original mail. An
>> immediate question that comes to mind on looking at the patch is whether
>> we
>> care about roughly aligning the configuration of the new functionality
>> with
>> the existing "XML Security" DataFormat?
>>
>> For example, the supplied patch uses configuration that looks like
>> "xmlsecurity:sign://enveloping?keyAccessor=#accessor", whereas the
>> existing
>> component uses ".marshal().secureXML(.....)". Should the new
>> functionality
>> be implemented as a DataFormat as well, or does this not matter?
>>
>> Colm.
>>
>>
>> On Fri, Aug 16, 2013 at 2:52 PM, Claus Ibsen &lt;

> claus.ibsen@

> &gt;
>> wrote:
>>
>> > Hi
>> >
>> > There is this ticket. I assume its likely related to your proposal
>> > https://issues.apache.org/jira/browse/CAMEL-6339
>> >
>> > As it was a big patch and also we should double check that the source
>> > code is fully ASF acceptable. I think there is some schema files or
>> > whatnot copied from SUN/Oracle which may be a problem? Though haven't
>> > had the time to dive in.
>> >
>> > Would be great if you had the time to check the patch on the ticket,
>> > and maybe align with your work.
>> >
>> >
>> >
>> > On Fri, Aug 16, 2013 at 3:47 PM, Colm O hEigeartaigh
>> > &lt;

> coheigea@

> &gt; wrote:
>> > > Would the Camel community be interested in a XML Signature
>> DataFormat?
>> It
>> > > would be quite similar to the existing XML Security DataFormat,
>> except
>> > that
>> > > it would offer XML Signature instead of XML Encryption. Both could be
>> > used
>> > > together to support "sign-before-encrypt" or "encrypt-before-sign"
>> type
>> > of
>> > > functionality.
>> > >
>> > > I have implemented a prototype, but don't want to waste any more time
>> in
>> > > case there are any objections?
>> > >
>> > > Thanks,
>> > >
>> > > Colm.
>> > >
>> > >
>> > > --
>> > > Colm O hEigeartaigh
>> > >
>> > > Talend Community Coder
>> > > http://coders.talend.com
>> >
>> >
>> >
>> > --
>> > Claus Ibsen
>> > -----------------
>> > Red Hat, Inc.
>> > Email: 

> cibsen@

>> > Twitter: davsclaus
>> > Blog: http://davsclaus.com
>> > Author of Camel in Action: http://www.manning.com/ibsen
>> >
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>





--
View this message in context: http://camel.465427.n5.nabble.com/XML-Signature-DataFormat-tp5737414p5737643.html
Sent from the Camel Development mailing list archive at Nabble.com.

Mime
View raw message