[C++] Full XKMS Message Set Implemented

[Berin Lautenbach <be...@wingsofhermes.org>]

WooHoo!

Have finally finished the last of the XKMS messages in the C++ library,
so we now have all messages represented.

I'm now going to work towards a C++ 1.3 release.  So tell me now if
there is anything else people want in the release.  I'll be aiming to
hold a release vote in the next week or two once I've done some cleaning up.

Cheers,
	Berin

Re: Question about WS-Security

[Tech Rams <te...@yahoo.com>]

You will have to look at the feasibility of putting
everything in the body as well as achieving SOAP
intermediary functionality. 
WS-Security is an elegant and generalized solution.
The concept of security tokens pertains to username ,
X.509, or SAML tokens. For encryption, having
EncryptedKey separate from EncryptedData is also an
elegant and required feature. For Signature also,
having signature separate from content makes sense.
And think of what you can do once you have separated
out tokens, EncryptedKey, and Signature - you can
perform operations on them without damaging the
original content - for example, you can sign the
tokens, or encrypt them - tokens can be referred to in
encryption or signatures - all these offer the
advantages of brevity that you claim can be achieved
by putting things directly in the body!

And, of course, you still have to address SOAP
intermediary functionality even if you have achieved
elegance and generalization.

-rams

> *question 1) * Is there other reasons why 
> WS-Security defines 
> especially security elments in header part of SOAP
> message.
> 
> As I mentioned in an original e-mail, I believe that
> security element  
> defined with XML-Signature and XML-Encryption could
> be located in
> either header part or body part in SOAP messages.
> 
> If it is possible,  the former approach(using
> WS-Security) could contain 
> more information in header and the latter would be
> reverse.
> 
> In web services applications, the flow of message
> transactions could be 
> passed to an intended recipient by way of several
> intemediaries.
> In this case, which approach would be better from
> the viewpoints of 
> message processing and decryption ?
> 
> *question 2)* trade-off between two approaches(from
> the viewpoints of 
> implementation or performance)  ?
> 
> Il-Gon Kim
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Question about WS-Security

[IL GON KIM <ik...@irisa.fr>]

Davanum Srinivas wrote:

>my 2 cents, whatever is in the soap body is destined for the
>application that consumes/needs the soap request/response. the header
>is a location where intermediate nodes or the soap engine(s) at the
>end can add custom information independent of the application that
>sends/receives the soap request/response.
>
>-- dims
>  
>
Thanks for your good opinion.

I agree with your idea that header where any supplementary information 
such as address and id/passwd is generally located .
So, I think this might be one reason why security element is included in 
header part of SOAP messages, in WS-Security.

*question 1) * Is there other reasons why  WS-Security defines 
especially security elments in header part of SOAP message.

As I mentioned in an original e-mail, I believe that security element  
defined with XML-Signature and XML-Encryption could be located in
either header part or body part in SOAP messages.

If it is possible,  the former approach(using WS-Security) could contain 
more information in header and the latter would be reverse.

In web services applications, the flow of message transactions could be 
passed to an intended recipient by way of several intemediaries.
In this case, which approach would be better from the viewpoints of 
message processing and decryption ?

*question 2)* trade-off between two approaches(from the viewpoints of 
implementation or performance)  ?

Il-Gon Kim

>On 3/14/06, IL GON KIM <ik...@irisa.fr> wrote:
>  
>
>>I am studying on WS-Security and have a question about it.
>>As far as I understand it, WS-Security defines security elements in
>>header part of the SOAP messages, by combining WS-Signature and
>>WS-Encryption standards.
>>
>>I think it is possible to define security elements in body part of the
>>SOAP message, not in header part.
>>In my opinon, there would be a reason why security elment is described
>>in header part in WS-Security.
>>
>>If there is anyone who knows this reason or trade-off between two
>>approaches, please give me your opinion.
>>
>>
>>Regards
>>Il-Gon Kim
>>
>>
>>    
>>
>
>
>--
>Davanum Srinivas : http://wso2.com/blogs/
>
>
>  
>

Re: Question about WS-Security

[Davanum Srinivas <da...@gmail.com>]

my 2 cents, whatever is in the soap body is destined for the
application that consumes/needs the soap request/response. the header
is a location where intermediate nodes or the soap engine(s) at the
end can add custom information independent of the application that
sends/receives the soap request/response.

-- dims

On 3/14/06, IL GON KIM <ik...@irisa.fr> wrote:
> I am studying on WS-Security and have a question about it.
> As far as I understand it, WS-Security defines security elements in
> header part of the SOAP messages, by combining WS-Signature and
> WS-Encryption standards.
>
> I think it is possible to define security elements in body part of the
> SOAP message, not in header part.
> In my opinon, there would be a reason why security elment is described
> in header part in WS-Security.
>
> If there is anyone who knows this reason or trade-off between two
> approaches, please give me your opinion.
>
>
> Regards
> Il-Gon Kim
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

Re: Question about WS-Security

[William Bathurst <wi...@oracle.com>]

IL GON KIM wrote:

> I am studying on WS-Security and have a question about it.
> As far as I understand it, WS-Security defines security elements in 
> header part of the SOAP messages, by combining WS-Signature and 
> WS-Encryption standards.
>
> I think it is possible to define security elements in body part of the 
> SOAP message, not in header part.
> In my opinon, there would be a reason why security elment is described 
> in header part in WS-Security.
>
> If there is anyone who knows this reason or trade-off between two 
> approaches, please give me your opinion.

If you look at the history of messaging, there has always been the need 
to separate metadata from the actual payload. MQSeries and JMS are prime 
examples. They leverage information in the message headers for message 
correlation, priority, etc... This normalizes the message, and provides 
the ability to optimize message processing. The reasons are the same for 
SOAP where one can reduce the the amount of clutter that could go into 
the actual payload, and normalize the message content for ease of 
processing.

When it comes to WS-Security, there are many reasons for using SOAP 
headers. For example, if you wish to sign the message body, would you 
put the wsse element into the message body or header? What if there are 
multiple signatures within the body. Seems to me that putting the 
WS-Security wsse elements into the message body is a nightmare.

Finally, there is performance. If there isn't any headers, there is no 
need to process WS-Security, WS-Addressing, etc... If everything is in 
the body, it is more difficult to determine whether metadata processing 
will need to be made or not.

Regards,
Bill

Question about WS-Security

[IL GON KIM <ik...@irisa.fr>]

I am studying on WS-Security and have a question about it.
As far as I understand it, WS-Security defines security elements in 
header part of the SOAP messages, by combining WS-Signature and 
WS-Encryption standards.

I think it is possible to define security elements in body part of the 
SOAP message, not in header part.
In my opinon, there would be a reason why security elment is described 
in header part in WS-Security.

If there is anyone who knows this reason or trade-off between two 
approaches, please give me your opinion.


Regards
Il-Gon Kim

RE: [C++] Full XKMS Message Set Implemented

[Scott Cantor <ca...@osu.edu>]

> Hmm.  Don't have a 64 bit system to do a build on.  Must try and see if
> I can track something down.

I've gotten access to an Opteron, so I can report back. I'll try and get to
it this week. But the Microsoft build by default will report 64 bit issues
as warnings to help identify problems with int sizes and that sort of thing,
so it helps catch things.

> The original idea was that it could re-use objects rather than
> completely deleting and re-allocating all the time.  That was the idea -
> but I haven't yet had time to make it work.

Ok. I'm not sure in practice how valuable it would be, but at a minimum it
seems like that could be handled without actually tracking the objects in a
big list while they're in use.

> The other part was as a message factory - I'm trying to hide the
> implementation from the user.  If you look at the XKMS classes they are
> completely interface only now.  That's where I want the Signature
> classes to be as well.

Understood, my new code has a similar design.

> The message factory side of it could potentially
> be done using static methods, but I wanted to avoid that to keep thread
> handling simpler in complex applications.  (Mind you, if we passed
> ownership straight to the caller then thread issues are pretty much
> non-existant - it's only an issue if we continue to keep a memory of all
> signatures we have allocated.)

Right, I think the factories should be stateless singletons anyway, if
possible.

> Where are you seeing an XSECEnv?  That should be completely hidden
> unless you are manipulating the implementation classes directly!

Well, I am at times because I needed to manipulate ds:KeyInfo information. I
rapidly figured out that this wasn't really fully supported yet, but the
DSIGKeyInfoList stuff uses an XSECEnv internally, so I had to work around
that a little.

I think I'm satisfied for the moment that I need to wrap the KeyInfo stuff
myself. My XML handling classes are more flexible than the stuff in this
library, so while it's a little more work for me up front, it will be better
than relying on, as you say, implementation classes here.

> If you are having to manipulate the Env class directly for normal
> operations then I have a bug somewhere.  For encryption the only things 
> you should need are the Cipher and provider classes.

I haven't touched that stuff yet. I think the problem was that I was pushing
out past the boundaries you had intended and trying to reuse some of the
signature wrapping classes for my own needs.

> Really it just encapsulates all the information that is common for all
> the objects that make up an EncryptedType object.  There is probably a
> nicer way to do it, but I couldn't see it :<.

If it's not supposed to be affecting me, then that tells me where I'm
misusing some of the current classes and where I need to code my own
wrappers.

Thanks,
Scott

Re: [C++] Full XKMS Message Set Implemented

[Berin Lautenbach <be...@wingsofhermes.org>]

Scott Cantor wrote:

> Most of the 64-bit warnings are probably from Xerces, but if you have
> anything you can fix there, it would also be appreciated. I'm getting more
> demand for 64-bit builds lately.

Hmm.  Don't have a 64 bit system to do a build on.  Must try and see if
I can track something down.

> That's part of it, particularly making sure things are as stateless as
> possible. Right now, I have this extra XSECProvider thing I'm lugging around
> as a (nearly) global variable just to create and release signatures, but it
> doesn't seem to add any actual value.

The original idea was that it could re-use objects rather than
completely deleting and re-allocating all the time.  That was the idea -
but I haven't yet had time to make it work.

The other part was as a message factory - I'm trying to hide the
implementation from the user.  If you look at the XKMS classes they are
completely interface only now.  That's where I want the Signature
classes to be as well.  The message factory side of it could potentially
be done using static methods, but I wanted to avoid that to keep thread
handling simpler in complex applications.  (Mind you, if we passed
ownership straight to the caller then thread issues are pretty much
non-existant - it's only an issue if we continue to keep a memory of all
signatures we have allocated.)

> 
> I've also been looking ahead to the encryption stuff, and I'm not sure I
> understand the implications of the XSECEnv yet. I'm generally sensitive to
> lugging around other objects I need to manage because of the hairiness of
> DOM management in Xerces-C.
> 
> Anyway, I don't have much to suggest yet, and it wouldn't be on this
> timeline.

Where are you seeing an XSECEnv?  That should be completely hidden
unless you are manipulating the implementation classes directly!  If you
are having to manipulate the Env class directly for normal operations
then I have a bug somewhere.  For encryption the only things you should
need are the Cipher and provider classes.

I need the env class within the implementation classes to link the
various parts of a Cipher object together.  As an example, if we need to
create a CipherReference, it needs to be a part of the document for the
EncryptedType.  Similarly, I needed a place to store information about
namespace qnames without having to look at the owning object.

I started out by always going back to the parent class, but that gets
really ugly in a few places (some objects can have different parent
classes in the message sense) and I found the easiest way to handle
things was to have an environment object that exists as a part of a
particular message.  There is a super object from which all the others
are derived during message creation (to keep consistent qnames and the
like), but again you shouldn't have to worry about it.  Generally only
the EncryptedType has an actual env object - all the sub-objects have a
link only.

Really it just encapsulates all the information that is common for all
the objects that make up an EncryptedType object.  There is probably a
nicer way to do it, but I couldn't see it :<.

Cheers,
	Berin

RE: [C++] Full XKMS Message Set Implemented

[Scott Cantor <ca...@osu.edu>]

> Yup - already working on it.  I tend to do most of my work on Linux and
> VC 6.0 and then when it's all looking OK build up the other
> compilers/platforms.  Otherwise I waste a lot of cycles doing point
> fixes to projects.

I understand, just wanted to check. I think the only actual error I got was
a missing const on a strstr call.

Most of the 64-bit warnings are probably from Xerces, but if you have
anything you can fix there, it would also be appreciated. I'm getting more
demand for 64-bit builds lately.

> Most interested to hear thoughts.  I have been wanting for a while to
> head back to DSIGSignature and rework that into more of a factory
> approach than currently exists but I think you mean more than that?

That's part of it, particularly making sure things are as stateless as
possible. Right now, I have this extra XSECProvider thing I'm lugging around
as a (nearly) global variable just to create and release signatures, but it
doesn't seem to add any actual value.

I've also been looking ahead to the encryption stuff, and I'm not sure I
understand the implications of the XSECEnv yet. I'm generally sensitive to
lugging around other objects I need to manage because of the hairiness of
DOM management in Xerces-C.

Anyway, I don't have much to suggest yet, and it wouldn't be on this
timeline.

-- Scott

Re: [C++] Full XKMS Message Set Implemented

[Berin Lautenbach <be...@wingsofhermes.org>]

Scott Cantor wrote:

> At a minimum, I'd suggest some minor fixes needed so the code will build
> cleanly on the latest MS compiler (VS 2005), which I can supply for the
> no-xalan build, at least. Also optionally check in some project files for
> that version instead of forcing people to convert the 7.0 projects files,
> although that mostly works fine.

Yup - already working on it.  I tend to do most of my work on Linux and
VC 6.0 and then when it's all looking OK build up the other
compilers/platforms.  Otherwise I waste a lot of cycles doing point
fixes to projects.

> 
> There were some new source files not added to the MS project in svn as well,
> but that's easy to fix also.
> 
> I'd also suggest copying some more of the Xerces version header machinery
> into the XMLSec one. That makes it easier for people to do autoconf version
> checks, and since 1.3 has some good new APIs, I know I at least need to
> check for it.

Hmm.  Good idea.  Will have a look-see.

> 
> Most of the rest of my thoughts center on a bit of reworking of the whole
> document management approach, the XSECProvider concept, and some of that,
> but I haven't had a chance to really formally propose anything, so I'd say
> do a 1.3 and then maybe look at that stuff later if anybody is so inclined.

Most interested to hear thoughts.  I have been wanting for a while to
head back to DSIGSignature and rework that into more of a factory
approach than currently exists but I think you mean more than that?

Cheers,
	Berin

Re: [C++] Full XKMS Message Set Implemented

[Scott Cantor <ca...@osu.edu>]

Berin Lautenbach wrote:
> No - fairly easy.  Xalan on the other hand is a beast to convert.  Not
> going to bother.  Unless someone else volunteers to do the work (:>) VC
> 2005 support will only be for a Xerces build until Xalan 1.11 (or 2.0)
> is released.

Doesn't affect me yet, so no problem.

-- Scott

Re: [C++] Full XKMS Message Set Implemented

[Berin Lautenbach <be...@wingsofhermes.org>]

Scott Cantor wrote:

> Berin Lautenbach wrote:
> 
>>
>> Have you built Xerces 2.7.0 on VS 2005?  If so - did you just convert
>> the 7.0 project files?  Or are you linking against Xerces 2.7 built on
>> 7.0 or 6.0?
> 
> 
> Yes, I rebuilt it on 2005 by converting the projects. I don't recall any
> major trouble with it.

No - fairly easy.  Xalan on the other hand is a beast to convert.  Not
going to bother.  Unless someone else volunteers to do the work (:>) VC
2005 support will only be for a Xerces build until Xalan 1.11 (or 2.0)
is released.

Cheers,
	Berin

Re: [C++] Full XKMS Message Set Implemented

[Scott Cantor <ca...@osu.edu>]

Berin Lautenbach wrote:
> 
> Have you built Xerces 2.7.0 on VS 2005?  If so - did you just convert
> the 7.0 project files?  Or are you linking against Xerces 2.7 built on
> 7.0 or 6.0?

Yes, I rebuilt it on 2005 by converting the projects. I don't recall any 
major trouble with it.

> As an aside, I've been having a look at the svn version of Xerces and
> there appears to be a fair few changes in preparation for a 3.0 release.
>  So I'm currently planning to support 2.7, not 3.0.  I think we can
> release another 1.3.x version once Xerces 3.0 is released.

I think that's sensible, I haven't looked into 3.0 at all myself.

-- Scott

Re: [C++] Full XKMS Message Set Implemented

[Berin Lautenbach <be...@wingsofhermes.org>]

Scott Cantor wrote:

> At a minimum, I'd suggest some minor fixes needed so the code will build
> cleanly on the latest MS compiler (VS 2005), which I can supply for the
> no-xalan build, at least. Also optionally check in some project files for
> that version instead of forcing people to convert the 7.0 projects files,
> although that mostly works fine.

Have you built Xerces 2.7.0 on VS 2005?  If so - did you just convert
the 7.0 project files?  Or are you linking against Xerces 2.7 built on
7.0 or 6.0?

As an aside, I've been having a look at the svn version of Xerces and
there appears to be a fair few changes in preparation for a 3.0 release.
 So I'm currently planning to support 2.7, not 3.0.  I think we can
release another 1.3.x version once Xerces 3.0 is released.

Cheers,
	Berin

RE: [C++] Full XKMS Message Set Implemented

[Scott Cantor <ca...@osu.edu>]

> I'm now going to work towards a C++ 1.3 release.  So tell me now if
> there is anything else people want in the release.  I'll be aiming to
> hold a release vote in the next week or two once I've done 
> some cleaning up.

At a minimum, I'd suggest some minor fixes needed so the code will build
cleanly on the latest MS compiler (VS 2005), which I can supply for the
no-xalan build, at least. Also optionally check in some project files for
that version instead of forcing people to convert the 7.0 projects files,
although that mostly works fine.

There were some new source files not added to the MS project in svn as well,
but that's easy to fix also.

I'd also suggest copying some more of the Xerces version header machinery
into the XMLSec one. That makes it easier for people to do autoconf version
checks, and since 1.3 has some good new APIs, I know I at least need to
check for it.

Most of the rest of my thoughts center on a bit of reworking of the whole
document management approach, the XSECProvider concept, and some of that,
but I haven't had a chance to really formally propose anything, so I'd say
do a 1.3 and then maybe look at that stuff later if anybody is so inclined.

-- Scott