XML Canonicalization

[thomas....@gmail.com]

I have the unfortunate but necessary task of dealing with SAML in Go.

This requires primarily the ability to generate Canonical XML. Does xml.Encoder happen to generate canonical XML already? Am I going to need a different xml library for this?

Any help would be much appreciated.

Tom

[Ian Davis]

This is not an answer to your XML question, but I found a SAML client here:

 

https://github.com/mattbaird/gosaml

 

Might be enough for your needs or at least give you some inspiration.

 

Ian

 

[Chris Hines]

Caveat: What follows is not authoritative because I've only just now read http://en.wikipedia.org/wiki/Canonical_XML. However...

Having used xml.Encoder for a few different tasks I feel pretty confident that it does not produce canonical XML out of the box, but it does satisfy several of the requirements and most of the rest might be manageable with some helper functions or clever implementations of xml.Marshaller.

The area I would be most concerned about encountering real difficulties would be with the namespace handling, especially the requirement not to emit superfluous namespace declarations.

In one project I worked on there was a piece that streamed xml.Tokens emitted by xml.Decoder out through an xml.Encoder (while modifying a few specific cases we cared about). When the source document had namespace declarations the round trip through encoding/xml produced a lot of unnecessary namespace declarations. There may be a manageable work around for your use case, but encoding/xml does not handle this well on its own.

Chris

[James Bardin]

No, you're going to have trouble with canonical xml from the go encoding/xml library. (also github.com/mattbaird/gosaml looks very basic, and would be surprised if it worked with the majority of providers.)

SAML is a very deep hole to jump into, and I would recommend offloading it as long as possible. Though I worked with it in depth in the past, my knowledge may be a little out of date, Shibboleth has been the most complete and reliable implementation available (https://shibboleth.net). It was (and probably is still) apache based, but with some clever proxying you can get by only using it for authentication.

At a slightly lower level, the reference libraries are available in C++ and Java (I think there's info on the shibboleth site as well). 

If you are going to try and do this in go, I would at least let some of the industry standard libraries do the difficult xml lifting for you. XML canonicalization, security and signing are very complex, and there have been security holes in SAML2 itself in this area. I prefer to shell out to the xmlsec security tools when in doubt.  I'm not sure of the status if the libxml2 wrappers for go, but that may be worth looking into too (or wrapping just the functionality you need yourself).

[Eric Johnson]

If you have to support encryption & security, then canonicalization actually gets quite ugly.

I've worked on the Apache Santuario project, doing some rework it, which generated a few patches. Canonicalization ends up being complicated in the general case, because the support required for XML Signature uses XPath support for selecting the nodes of the XML tree to be canonicalized. So canonicalization ends up being a combination of:

• Exclusive vs. non-exclusive
• Whole document, vs. subset
• Node set vs. all children
• Namespaces to assume vs. not assumed

If all you need is whole document canonicalization, then that should be straightforward to implement even without help from another library. If what you need is support for XML Encryption & XML Signature, then best use another library if you possibly can. In the most diabolical scenarios, an XSLT transform can be applied to a document before it is signed/encrypted. So you end up needing a full XML processing toolkit to make the full capabilities of XML Signature available.

Not being familiar with SAML, I don't know if you realistically need the full support of XML Encryption & XML Signature.

Eric.

[James Bardin]

On Mon, Jul 28, 2014 at 6:25 PM, Eric Johnson <er...@tibco.com> wrote:

If you have to support encryption & security, then canonicalization actually gets quite ugly.

I've worked on the Apache Santuario project, doing some rework it, which generated a few patches. Canonicalization ends up being complicated in the general case, because the support required for XML Signature uses XPath support for selecting the nodes of the XML tree to be canonicalized. So canonicalization ends up being a combination of:

• Exclusive vs. non-exclusive
• Whole document, vs. subset
• Node set vs. all children
• Namespaces to assume vs. not assumed

If all you need is whole document canonicalization, then that should be straightforward to implement even without help from another library. If what you need is support for XML Encryption & XML Signature, then best use another library if you possibly can. In the most diabolical scenarios, an XSLT transform can be applied to a document before it is signed/encrypted. So you end up needing a full XML processing toolkit to make the full capabilities of XML Signature available.

Not being familiar with SAML, I don't know if you realistically need the full support of XML Encryption & XML Signature.

Yeah, this is my experience as well. SAML definitely requires signing and/or encryption of partial documents and makes heavy use of namespaces, so external libraries are pretty much required at this point. 

What portion of SAML (it's a huge spec) do you need to deal with? Some subsets are much easier to handle, for example an SP providing only the HTTP-POST-SimpleSign binding is relatively simple to implement, since the signature is on the entire request, and doesn't require any xml manipulation.

 

[tbur...@treetopllc.com]

I decided to work on adding the missing functionality I needed to golibxml at github.com/bfrog/golibxml and eventually possibly open sourcing the resulting saml marshaling/signing, unmarshaling/verifying stuff. I looked at xmlsec and decided that too was probably the right way to do this considering how unfriendly the entire xml-dsig spec is to making small implementations of it.

I appreciate all the help this list gave and hope I can announce a new helpful golib in the future so others don't have to go through the same painful process of doing a saml implementation from scratch!

Tom