SAML metadata validation try two

Fri Jun 7 09:04:25 EDT 2013

Brian,

I tried the xmllint command on three unrelated systems and all gave me that error.

Yes, that's because the problem isn't your systems -- it's that (ironically) W3 is a very slow host and xmllint has aggressive timeout defaults.  I can consistently download the schema on three unrelated systems… each in 15 seconds or more.

$ time curl http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd
...
real 0m15.044s
...
real 0m15.086s
…
real 0m15.412s

> The surefire way to debug those is to just try loading the file into an IdP or an SP and seeing whether it complains.

I'm not sure how to do that.  I just have a test SP, UCOP will be my IdP.  I just figured out how to get my metadata out of /Shibboleth.sso/Metadata -- are you saying I should have <MetadataProvider type="XML" in my shibboleth2.xml that point to my own metadata and then shibd -t? Just for testing, or should it be that way in production?

Just for testing, but yeah, that is the easiest way to get an idea whether it's "loadable" metadata.  It won't tell you whether everything is right -- only end-to-end testing will tell you that -- but it'll tell you whether you're off on the right path.  A command line tool would expedite the process and make it cleaner, so I hope Scott finds the time to package that up.

If I have this set, then will /Shibboleth.sso/Metadata  return my good metadata rather than generated metadata?

Nope.  That's just a dynamic handler that will return metadata generated from polling the configuration files.  You can host this metadata file anywhere you'd like; at your entityID, https://nuxeo.cdlib.org/sp, would be a common place.  It can be anywhere you like and the IdP knows.  Your IdP may even prefer to host the file itself.

Am I on the right track as far as repeating the Complex Type EndpointType elements with redundant Binding attributes and Location attributes that point to -dev, -stg, and production, assuming the one entityID per application scenario?

Yes, right on, but you probably only need a small subset of the ones you're generating.  If you won't be using or don't support the SAML 2.0 Single Logout Profile in your application, then you don't need those endpoints.  If you're not doing artifact requests, you don't need the artifact endpoints, etc. etc.  If you're just doing "normal" Shibboleth 2.x, then you only need the POST endpoints.

There are almost too many options enabled by SAML 2.0 and the Shibboleth SP and it's not immediately obvious from a quick glance which ones you can prune here, but because some of those options are used in some deployments, we include them by default and can't provide blanket guidance about what to remove.

The below example probably has everything you'll need for basic interop with the UCOP IdP.

<md:EntityDescriptor
  xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
  xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:metadata http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd"

  ID="_ae6d076f856a2002ad755a3574c7204ddc9424b4"
  entityID="https://nuxeo.cdlib.org/sp"
  cacheDuration="P1D"
>
  <!-- 'P1D' = one day in xsd:duration, who knew? -->
  <!-- xmlns:init info at http://docs.oasis-open.org/security/saml/Post2.0/sstc-request-initiation-cd-01.html -->
  <!-- xmlns:md info at http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf -->
  <md:SPSSODescriptor
    protocolSupportEnumeration="
      urn:oasis:names:tc:SAML:2.0:protocol
      urn:oasis:names:tc:SAML:1.1:protocol
      urn:oasis:names:tc:SAML:1.0:protocol
    "
  >

<md:KeyDescriptor>

      <ds:KeyInfo>
        <ds:KeyName>nuxeo-dev</ds:KeyName>
        <ds:X509Data>
          <ds:X509SubjectName>CN=nuxeo-dev</ds:X509SubjectName>
          <ds:X509Certificate>MIIC4jCCAcqgAwIBAgIJAKHzEISxgVpsMA0GCSqGSIb3DQEBBQUAMBQxEjAQBgNV
BAMTCW51eGVvLWRldjAeFw0xMzA2MDEwMzQ5NDBaFw0yMzA1MzAwMzQ5NDBaMBQx
EjAQBgNVBAMTCW51eGVvLWRldjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALTNY5nzZ004HavyagcNTvHJmOlB9Tvh9xPnaGn2O92lRqMWaR3NKXMUSmnR
FjXTXYdQAnT0xkCS/Wkvur3XfzsN/c1qNlrxFRKtKOgqDDw3t6ttpCnwrxJcWIxF
F6cYTPW/E8GtimiSVv9GAYzzGmFhx+E5oeIdv6H8SiRw333cORoe5Ux4vMoTY6in
uNfecw6Fz1I5kQ/6O0kSSTGjJmIjgFQx0tpw8XJhL2E+jahu9sl3CZLYuqhsdBx9
/srtQBZ/Cem5WBUBtuFnJCiEVw4pDfTzTOe9WBCoVFDQQgOOa/wHbTD6W0kDIKWg
pF6A+ydiKE7aRpkt5Qo5NuZ9AKcCAwEAAaM3MDUwFAYDVR0RBA0wC4IJbnV4ZW8t
ZGV2MB0GA1UdDgQWBBRIbfPEefybNux8qxZ0jnw6V2/D7TANBgkqhkiG9w0BAQUF
AAOCAQEAAROxkv2qnDCmdeYr2cWCX7fO6BRMixZ1KfjUWRdMWnB79/LzZVQDnjgN
SsbYd+MDyaE5Wem67WMp2gwaEkG6bBMBxOa7YwRetPKfdw7DRJ60GXEepdECbXPU
0+TkdRWsAy5QYTotQJaA6/tc8vEAmH3l8BNo7NGCUA1bOXl3m2I+XU5b6j5GKY+e
1PuXw4V7VBEs/Myk7XZSNrEmil39l1x0cheshhLxgweb/a9xVTRSI5ZtTF0srTo8
pQv01Kmdgn6qPCI80/XRg0WWPG5lhR06Hcf9o0bhAF5HV2tdxiCQJn6ieEZ+gz/K
H+OplCprRz65+a5uj0Zv4ed77/rvXw==
</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://nuxeo.cdlib.org/Shibboleth.sso/SAML2/POST" index="0" isDefault="true"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://nuxeo-dev.cdlib.org/Shibboleth.sso/SAML2/POST" index="1"/>`

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://nuxeo-stg.cdlib.org/Shibboleth.sso/SAML2/POST" index="2"/>

  </md:SPSSODescriptor>

</md:EntityDescriptor>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130607/fc808ad4/attachment-0001.html 