ADFS with shib SP metadata problem

[Luke Alexander]

On Mon, May 11, 2015 at 04:06:55PM +0200, Peter Schober wrote:
> * Luke Alexander <luke at brandwatch.com> [2015-05-11 15:48]:
> > I have attached an image which will hopefully you'll receive on the
> > list?
> 
> Got it at
> http://shibboleth.net/pipermail/users/attachments/20150511/46c9adb4/attachment-0001.png
> (Copy/pasting the actual text of the error message -- "Digest
> verification failed for reference ..." -- makes things easier for
> others, jfyi.)
> 
> > Yes, I've tried the aleksey online tool and the xmlsec1 command line
> > tool, both say the same thing:
> > 
> [...]
> > xmlsec1 --verify --id-attr:ID urn:oasis:names:tc:SAML:2.0:metadata:EntitiesDescriptor --pubkey-cert-pem /etc/shibboleth/sp-cert.pem sp-live_meta_url.xml 
> 
> If sp-live_meta_url.xml originally came from your Shib SP it won't
> have an EntitiesDescriptor root element, only an EntitiyDescriptor
> one.
> Also it won't be signed by default, so you must have changed that.
> 
Yeah, in our shibboleth.xml we have:

<Handler type="MetadataGenerator" Location="/Metadata" signing="true"
http="false" https="true" template="metadata-template.xml"
mimeType="application/xml" />

Although it's commented out now as was only enabled to generate the
metadata file before going into production - since we edited the file
that would explain the signature being invalid then?

> Of course signing the SP's metadata with the same cert the SP
> publishes as it's truct fabric cert doesn't give any additional trust
> to anyone having to validate that signature on the metadata: You
> either trust the local file (containing that same key) or you don't.
> 
> Slapping a signature from that same contained key onto that metadata
> will not change that. (E.g. I could easily replace the contained
> certificate with my own, and sign the metadata with that key too. To
> anyone needing to make decision whether to trust any of the info in
> the metadata that's exactly as trustworthy as your data with the
> real/correct key.
> 
> So I'd doubt you signing the metadata (and trying to feed that to
> MS-ADFS) actually makes any sense.

Yeah, I agree, though it looks to me like ADFS will likely accept the
metadata file if it is well formed _and_ has a valid signature - even if
the signature itself doesn't give additional trust...

> 
> > ERROR
> > SignedInfo References (ok/all): 0/1
> > Manifests References (ok/all): 0/0
> > Error: failed to verify file "sp-live_meta_url.xml"
> 
> Maybe that's just the consequence of the incorrect element referenced
> in the xmlsec1 command line. Also you can probbaly forgo signing
> completely. Finally try XmlSecTool which this group can support.

I've now used the xmlsectool, it too finds the metadata to be invalid,
it also finds the staging SP metadata to be valid, so that fits with
ADFS, too.

Given that the metadata signature is invalid for our production SP I
assumed that creating a new metadata file using the shib-metagen script
would be simply:

shib-metagen -2AOLN -o Brandwatch -c /etc/shibboleth/sp-cert.pem -h \
'sp.brandwatch.com' > Metadata.script

xmlsectool.sh --certificate /etc/shibboleth/sp-cert.pem --key \
/etc/shibboleth/sp-key.pem --sign --inFile Metadata.script --outFile \
Metadata.xml

But that gives:

INFO  XmlSecTool - Reading XML document from file 'Metadata.script'
[Fatal Error] :1:70: The prefix "md" for element "md:EntityDescriptor" is not bound.
ERROR XmlSecTool - XML document was not well formed
org.xml.sax.SAXParseException: The prefix "md" for element "md:EntityDescriptor" is not bound.
	at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) ~[na:na]
	at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) ~[na:na]
	at javax.xml.parsers.DocumentBuilder.parse(Unknown Source) ~[na:1.4.01]
	at edu.internet2.middleware.security.XmlSecTool.parseXML(XmlSecTool.java:223) [xmlsectool-1.2.0.jar:na]
	at edu.internet2.middleware.security.XmlSecTool.main(XmlSecTool.java:181) [xmlsectool-1.2.0.jar:na]

Once again, thanks for your help with this!
Luke