Metadata format
Roy Spectech
roygspectech8 at gmail.com
Fri Sep 13 13:27:28 EDT 2013
ShibUsers,
We're finally getting around to cleaning up our metadata file.
We're SP only so this is the file that we'd have our partner/customer
IdPservers install.
We've looked at examples for everywhere and we're still confused.
The ../Shibboleth.sso/Metadata generated file has a familiar structure:
(We know this will not be the final file, but just a starting point)
<!--
This is example metadata only. Do *NOT* supply it as is without review,
and do *NOT* provide it in real time to your partners.
-->
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="_7f02024667d46287aafdd4ecdfd0627d2010938b" entityID="
https://app1.corp.com/Shibboleth.sso">
<md:Extensions xmlns:alg="urn:oasis:names:tc:SAML:metadata:algsupport">
<alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>
<alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig
-more#sha384"/>
<alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig
-more#sha224"/>
<alg:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa
-sha512"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa
-sha384"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa
-sha256"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2009/xmldsig11#dsa
-sha256"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa
-sha1"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa
-sha1"/>
</md:Extensions>
<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:Extensions>
<init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:
SSO:request-init" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init"
Location="https://app1.corp.com/Shibboleth.sso/Login"/>
</md:Extensions>
<md:KeyDescriptor>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyName>CBRDWEBP07</ds:KeyName>
<ds:X509Data>
<ds:X509SubjectName>CN=CBRDWEBP07</ds:X509SubjectName>
<ds:X509Certificate>dklsfjklsdfkljslf;fjsfjweiorjds;f;JSDFSDFJ;
ASDFSJDF
<CERT LINES HERE>
dklsfjklsdfkljslf;fjsfjweiorjds;f;JSDFSDFJ;ASDFSJDF==
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc
#aes128-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc
#aes192-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc
#aes256-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#
tripledes-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#rsa-
oaep"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-
oaep-mgf1p"/>
</md:KeyDescriptor>
<md:ArtifactResolutionService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://app1.corp.com/Shibboleth.sso/Artifact/SOAP" index="1"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://app1.corp.com/Shibboleth.sso/SLO/SOAP"/>
<md:SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://app1.corp.com/Shibboleth.sso/SLO/Redirect"/>
<md:SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://app1.corp.com/Shibboleth.sso/SLO/POST"/>
<md:SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://app1.corp.com/Shibboleth.sso/SLO/Artifact"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://app1.corp.com/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML
:2.0:bindings:HTTP-POST-SimpleSign" Location="
https://app1.corp.com/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://app1.corp.com/Shibboleth.sso/SAML2/Artifact" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML
:2.0:bindings:PAOS" Location="https://app1.corp.com/Shibboleth.sso/SAML2/ECP"
index="4"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://app1.corp.com/Shibboleth.sso/SAML/POST" index="5"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
Location="https://app1.corp.com/Shibboleth.sso/SAML/Artifact" index="6"/>
</md:SPSSODescriptor>
<Organization>
<OrganizationName xml:lang="en">Corp.Com</OrganizationName>
<OrganizationDisplayName xml:lang="en">Corp.Com</OrganizationDisplayName
>
<OrganizationURL xml:lang="en">https://www.corp.com</OrganizationURL>
</Organization>
<ContactPerson contactType="administrative">
<GivenName>Mr. Administrator</GivenName>
<EmailAddress>adm at corp.com</EmailAddress>
</ContactPerson>
<ContactPerson contactType="support">
<GivenName>Support Group</GivenName>
<EmailAddress>support at corp.com</EmailAddress>
</ContactPerson>
</md:EntityDescriptor>
This worked just fine with our partners and customers.
Notice all the "<md: ... </md: pairs.
We then added the endpoints and CERT for one of new customers. We generated
their CERT pair with KEYGEN and their metadata file with METAGEN. When we
went to add this new meta file to the existing metadata file things blew up.
<!-- customer2301 -->
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:
ds="http://www.w3.org/2000/09/xmldsig#" entityID="
https://app1.corp.com/customer2301/Shibboleth.sso">
<md:SPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol
urn:oasis:names:tc:SAML:1.1:protocol">
<md:KeyDescriptor>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
<ds:X509Certificate>dklsfjklsdfkljslf;fjsfjweiorjds;f;JSDFSDFJ;
ASDFSJDF
<CERT LINES HERE>
dklsfjklsdfkljslf;fjsfjweiorjds;f;JSDFSDFJ;ASDFSJDF==
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://app1.corp.com/customer2301/Shibboleth.sso/SAML2/POST"
index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML
:2.0:bindings:HTTP-POST-SimpleSign" Location="
https://app1.corp.com/customer2301/Shibboleth.sso/SAML2/POST-SimpleSign"
index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML
:2.0:bindings:PAOS" Location="https://app1.corp.com/customer2301/Shibboleth.
sso/SAML2/ECP" index="3"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://app1.corp.com/customer2301/Shibboleth.sso/SAML/POST"
index="4"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
<!-- customer2301 -->
This metadata also has the same <md:..</md pairs. However, none of our
partners or customers could import the new file. All complained that the
XML was rejected.
We tried a XML validation tool, and it reported the problem starting at the
new addition (not surprising) right at the first "<md: " element.
So 2 questions:
We're using the supplied tools (keygen.sh, metagen.sh) to create
metadatafiles for new customers (who appear as a different path in our
application
tree). We want to add the customer endpoints and entityID's to the main
metadata file that we publish. We know we have to care/craft/adjust/edit
our metadata. Clearly the supplied tools are just a starting point, but
what guides to people use to make sure the XML is correct for Shibboleth
IdP's to "consume." Is there a "generic metadata file" or documented guide
that we can refer to for this type of additional meta?
2) Would just stripping off the " <md: .. </md pairs be enough to correct
the problem? Meaning that only one pair of <md:EntityDescriptor>...</md:
EntityDescriptor> is allowed and subsequent lines cannot have the <md: .. </
md: notation.
-- RGS
==================================
Roy G. Specter
roygspectech8 at gmail.com
========================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130913/dd4b74b9/attachment-0001.html
More information about the users
mailing list