Recent changes to the Shibboleth implementation have revealed a number of issues with metadata production by federations that resulted in failures due to increased strictness in rejecting certain invalid XML constructs. To aid federations in the generation of correct metadata, this is a summary of known issues with implementations of interest.
| Table of Contents | ||
|---|---|---|
|
General Statements
Before getting into the details, understand that to be "correct", a SAML metadata file needs to follow a number of syntactic and semantic rules. If it doesn't do so, a software product is free to reject it. You will find that different SAML products behave in vastly different ways, some very strict and some very accepting. The best approach you can take is to be very rigorous about what you produce, and be very wary of accommodating actual bugs in products that require you to "break" your metadata to get them to consume it. If you follow that path, you'll end up maintaining dedicated files in no time, so be sure that's what you want to do.
...
| No Format |
|---|
xmlsectool.sh --validateSchema --schemaDirectory /usr/share/xml/opensaml/ --inFile example-metadata.xml |
xmllint
On RedHatRed Hat, xmllint is included in the package libxml2, which will already be installed if you're using the RedHat Red Hat Network (since it's required by rhn-client-tools). On Debian and derivatives, xmllint can be installed via apt-get install libxml2-utils.
...
| No Format |
|---|
xmlsec1 --verify --pubkey-cert-pem metadata-signing.crt example-metadata.xml |
On RedHat Red Hat install via yum install xmlsec1 xmlsec1-openssl. Note that on a current RHEL5.5 system Unlicensed user additionally had to create a symlink for the openssl engine library, e.g.:
...