XMLSecTool validateSchema states ID is not a valid value for 'NCName' using MDA 0.7

Ian Young ian at iay.org.uk
Fri Apr 12 07:31:27 EDT 2013


On 12 Apr 2013, at 02:04, Dan McLaughlin <dmclaughlin at tech-consortium.com> wrote:

> I'm seeing that the new stage does add the ID, but when I run the
> metadata through xmlsectool.sh --validateSchema --schemaDirectory
> /tmp/mda/xsd/ --inFile /tmp/mda/federation/federation-metadata.xml
> 
> I get the following error stating the ID is not valid for NCName.

Hi Dan,

Scott pretty much nailed the response to this one, but let me go through it anyway.

Your original problem was described in MDA-58:

https://issues.shibboleth.net/jira/browse/MDA-58

One thing you had hit was that not using an ID attribute when signing led to a failure in verification in xmlsectool:

https://issues.shibboleth.net/jira/browse/XSTJ-15

That particular issue is fixed in the release of xmlsectool that will come out next week, but you shouldn't rely on it because that ID attribute is a requirement of the SAML metadata spec anyway and you should definitely use one.

Chad's fix for this was to include a way to attach an appropriate but random ID attribute value, and a stage to do that was shipped in MDA 0.7.  Unfortunately the stage implementation relies on some code lower down in the V3 stack which can generate invalid XML ID values.  This bug at the MDA level is described here:

https://issues.shibboleth.net/jira/browse/MDA-90

The bug in the underlying library is described here:

https://issues.shibboleth.net/jira/browse/JSPT-24

This can affect any consumer which validates the XML, not just SAML ones.  As Scott mentioned, by a complete coincidence I noticed this problem myself just a couple of days ago and have already committed a fix.

> Any chance you are releasing a new version with this fix soon?

It's slightly trickier than you might imagine to do that, because the problem turned out to be in something lower down the stack and part of the V3 IdP, which is under rather furious development at the moment.  It might be possible to do a bug-fix release nevertheless, and I'll discuss this with the other developers today.  I think we'll prefer not to make a new release at this stage just for this.

As an alternative, which would work with both 0.6 and 0.7, I'd note that there's no requirement to use that particular stage to add an ID attribute, and that there's also no requirement for the ID value used to be random as long as you know that it isn't used as an ID anywhere else in the document.  So for example, a simple XSLT stage which pasted in a constant ID="hamburgefonstiv" would probably be a viable workround.  I think most people have been doing something like that (in the UKf, we place a timestamp in there), which may be why this has taken so long to show up.  Let me know if you need an example to follow.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20130412/17814811/attachment-0001.bin 


More information about the dev mailing list