<EntitiesDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:metadata ../schemas/sstc-saml-schema-metadata-2.0.xsd urn:mace:shibboleth:metadata:1.0 ../schemas/shibboleth-metadata-1.0.xsd"
+ xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
+ xmlns:shibmeta="urn:mace:shibboleth:metadata:1.0"
+ xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:metadata ../schemas/saml-schema-metadata-2.0.xsd urn:mace:shibboleth:metadata:1.0 ../schemas/shibboleth-metadata-1.0.xsd http://www.w3.org/2000/09/xmldsig# ../schemas/xmldsig-core-schema.xsd"
Name="urn:mace:inqueue"
validUntil="2010-01-01T00:00:00Z">
- <!--
- This is a starter set of metadata for the example system used within the
- InQueue test federation. The InQueue deployment guide describes how to use
- metadatatool or siterefresh to pick up the most current signed files.
- Ordinarily a single EntityDescriptor would contain IdP/AA or SP information,
- but not both.
- -->
-
- <Extensions>
- <KeyAuthority xmlns="urn:mace:shibboleth:metadata:1.0">
- <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
- <ds:X509Data>
- <ds:X509Certificate>MIICNDCCAaECEAKtZn5ORf5eV288mBle3cAwDQYJKoZIhvcNAQECBQAwXzELMAkG
+ <Extensions>
+ <!-- This extension contains the list of CAs used by InQueue entities. -->
+ <shibmeta:KeyAuthority VerifyDepth="1">
+ <!-- Verisign -->
+ <ds:KeyInfo>
+ <ds:X509Data>
+ <ds:X509Certificate>
+MIICNDCCAaECEAKtZn5ORf5eV288mBle3cAwDQYJKoZIhvcNAQECBQAwXzELMAkG
A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYD
VQQLEyVTZWN1cmUgU2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk0
MTEwOTAwMDAwMFoXDTEwMDEwNzIzNTk1OVowXzELMAkGA1UEBhMCVVMxIDAeBgNV
hvcNAQECBQADfgBl3X7hsuyw4jrg7HFGmhkRuNPHoLQDQCYCPgmc4RKz0Vr2N6W3
YQO2WxZpO8ZECAyIUwxrl0nHPjXcbLm7qt9cuzovk2C2qUtN8iD3zV9/ZHuO3ABc
1/p3yjkWWW8O6tO1g39NTUJWdrTJXwT4OPjr0l91X817/OWOgHz8UA==
-</ds:X509Certificate>
- </ds:X509Data>
- </ds:KeyInfo>
- </KeyAuthority>
- </Extensions>
+ </ds:X509Certificate>
+ </ds:X509Data>
+ </ds:KeyInfo>
+ <!-- Bossie -->
+ <ds:KeyInfo>
+ <ds:X509Data>
+ <ds:X509Certificate>
+MIIC6zCCAlSgAwIBAgICAlQwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
+MRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoT
+F1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJ
+bmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBNYXN0ZXIgQ0Eg
+LS0gMjAwMjA3MDFBMB4XDTAyMDYzMDIyMTYzOVoXDTI5MTExNjIyMTYzOVowgakx
+CzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlz
+b24xIDAeBgNVBAoTF1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJE
+aXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBL
+SSBNYXN0ZXIgQ0EgLS0gMjAwMjA3MDFBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
+iQKBgQDJ3FDZym9Ja94DP7TUZXf3Vu3CZwqZzYThgjUT2eBJBYVALISSJ+RjJ2j2
+CYpq3wesSgWHqfrpPnTgTBvn5ZZF9diX6ipAmC0H75nySDY8B5AN1RbmPsAZ51F9
+7Eo+6JZ59BFYgowGXyQpMfhBykBSySnvnOX5ygTCz20LwKkErQIDAQABoyAwHjAP
+BgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBpjANBgkqhkiG9w0BAQQFAAOBgQB1
+8ZXB+KeXbDVkz+b2xVXYmJiWrp73IOvi3DuIuX1n88tbIH0ts7dJLEqr+c0owgtu
+QBqLb9DfPG2GkJ1uOK75wPY6XWusCKDJKMVY/N4ec9ew55MnDlFFvl4C+LkiS2YS
+Ysrh7fFJKKp7Pkc1fxsusK+MBXjVZtq0baXsU637qw==
+ </ds:X509Certificate>
+ </ds:X509Data>
+ </ds:KeyInfo>
+ </shibmeta:KeyAuthority>
+ </Extensions>
-
+ <!--
+ This is a starter set of metadata for the example system used within the
+ InQueue test federation. The InQueue deployment guide describes how to use
+ metadatatool or siterefresh to pick up the most current signed files.
+ Ordinarily a single EntityDescriptor would contain IdP/AA or SP information,
+ but not both. The sample site for InQueue just happens to contain both.
+ -->
+ <!-- Each IdP or SP is given an EntityDescriptor with its unique providerId/entityID. -->
<EntityDescriptor entityID="urn:mace:inqueue:example.edu">
+
+ <!-- A Shib IdP contains this element with protocol support as shown. -->
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
<Extensions>
+ <!-- This is a Shibboleth extension to express attribute scope rules. -->
<shib:Scope xmlns:shib="urn:mace:shibboleth:metadata:1.0">example.edu</shib:Scope>
</Extensions>
+
+ <!--
+ One or more KeyDescriptors tell SPs how the IdP will authenticate itself. A single
+ descriptor can be used for both signing and for server-TLS. You can place an
+ X.509 certificate directly in this element for the simplest use cases. This
+ example is more advanced, with the key/certificate identified by common name.
+ The certificate is then validated using the KeyAuthority extension element up
+ above.
+ -->
<KeyDescriptor use="signing">
- <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
+ <ds:KeyInfo>
<ds:KeyName>wayf.internet2.edu</ds:KeyName>
</ds:KeyInfo>
</KeyDescriptor>
+
+ <!-- This tells SPs that you support only the Shib handle format. -->
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
+
+ <!-- This tells SPs how and where to request authentication. -->
<SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
Location="https://wayf.internet2.edu/shibboleth-1.2/HS"/>
</IDPSSODescriptor>
+
+ <!-- Most Shib IdPs also support SAML attribute queries, so this role is also included. -->
<AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
<Extensions>
+ <!-- This is a Shibboleth extension to express attribute scope rules. -->
<shib:Scope xmlns:shib="urn:mace:shibboleth:metadata:1.0">example.edu</shib:Scope>
</Extensions>
+
+ <!--
+ Note that because TLS with certificate validation is used, there is no KeyDescriptor
+ needed. Since server TLS is used to authenticate the AA, its "key name" is implicit
+ in the URL used to connect to it. If you were to place the certificate directly
+ in the metadata in the role above, you'll also need a copy here.
+ -->
+
+ <!-- This tells SPs how and where to send queries. -->
<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="https://wayf.internet2.edu/shibboleth-1.2/AA"/>
+
+ <!-- This tells SPs that you support only the Shib handle format. -->
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
</AttributeAuthorityDescriptor>
+
+ <!-- A Shib SP contains this element with protocol support as shown. -->
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
+
+ <!--
+ One or more KeyDescriptors tell IdPs how the SP will authenticate itself. A single
+ descriptor can be used for both signing and for client-TLS. You can place an
+ X.509 certificate directly in this element for the simplest use cases. This
+ example is more advanced, with the key/certificate identified by common name.
+ The certificate is then validated using the KeyAuthority extension element up
+ above.
+ -->
<KeyDescriptor>
- <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
+ <ds:KeyInfo>
<ds:KeyName>wayf.internet2.edu</ds:KeyName>
</ds:KeyInfo>
</KeyDescriptor>
+
+ <!-- This tells IdPs that you support only the Shib handle format. -->
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
+
+ <!--
+ This tells IdPs where and how to send authentication assertions. Mostly
+ the SP will tell the IdP what location to use in its request, but this
+ is how the IdP validates the location and also figures out which
+ SAML profile to use.
+ -->
<AssertionConsumerService index="0"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://wayf.internet2.edu/Shibboleth.shire"/>
</SPSSODescriptor>
+
+ <!-- This is just information about the entity in human terms. -->
<Organization>
<OrganizationName xml:lang="en">Example State University</OrganizationName>
<OrganizationDisplayName xml:lang="en">Example State University</OrganizationDisplayName>
<SurName>InQueue Support</SurName>
<EmailAddress>inqueue-support@internet2.edu</EmailAddress>
</ContactPerson>
+
</EntityDescriptor>
</EntitiesDescriptor>