xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
- xmlns:shibmeta="urn:mace:shibboleth:metadata:1.0"
+ xmlns:shibmd="urn:mace:shibboleth:metadata:1.0"
xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:metadata @-PKGXMLDIR-@/saml-schema-metadata-2.0.xsd urn:mace:shibboleth:metadata:1.0 @-PKGXMLDIR-@/shibboleth-metadata-1.0.xsd http://www.w3.org/2000/09/xmldsig# @-PKGXMLDIR-@/xmldsig-core-schema.xsd"
Name="urn:mace:inqueue"
validUntil="2010-01-01T00:00:00Z">
<Extensions>
- <!-- This extension contains the list of CAs used by InQueue entities. -->
- <shibmeta:KeyAuthority VerifyDepth="1">
+ <!--
+ This Shibboleth extension contains a list of CAs that InQueue entities trust as they
+ evaluate the credentials they receive. They constitute the so-called "root store" or
+ "trust list" when interacting with the entities included in this file. The VerifyDepth
+ of "1" is PKIX-specified as the number of intermediaries permitted between the end-entity
+ certificate and the trust anchor. Each CA certificate is placed in its own <ds:KeyInfo>
+ container and is base64-encoded.
+ -->
+ <shibmd:KeyAuthority VerifyDepth="1">
<!-- Verisign -->
<ds:KeyInfo>
<ds:X509Data>
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
- </shibmeta:KeyAuthority>
+ </shibmd: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,
+ Ordinarily a single EntityDescriptor would contain IdP/AA or SP role information,
but not both. The sample site for InQueue just happens to contain both.
-->
<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>
+ <shibmd:Scope>example.edu</shibmd: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.
+ X.509 certificate directly in this element for the simplest use cases, in which case
+ no <shibmd:KeyAuthority> extension is needed. This example is more advanced,
+ with the key/certificate identified indirectly using a <ds:KeyName> element
+ containing the common name (CN) from the certificate. The certificate is then
+ validated using the trust anchors found in the applicable <shibmd:KeyAuthority>
+ extension element(s).
+
+ To identify certificates by name, you can use the CN attribute from the Subject,
+ a DNS or URI-valued subjectAltName extension value, or in special cases, the
+ entire Subject DN. We don't suggest the latter, because you must encode the DN
+ in a particular way (LDAP order, separated by commas) and because software is
+ unpredictable in how it will translate the RDN components into a text string.
-->
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:KeyName>wayf.internet2.edu</ds:KeyName>
</ds:KeyInfo>
</KeyDescriptor>
+
+ <!-- This tells SPs where/how to resolve SAML 1.x artifacts into SAML assertions. -->
+ <ArtifactResolutionService index="1"
+ Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
+ Location="https://wayf.internet2.edu:8443/shibboleth-idp/Artifact"/>
<!-- 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"/>
+ Location="https://wayf.internet2.edu/shibboleth-idp/SSO"/>
</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>
+ <shibmd:Scope>example.edu</shibmd: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
+ Note that when TLS with certificate validation is used, there may be no <KeyDescriptor>
+ needed. Since server TLS is used to authenticate the AA, its <ds:KeyName> 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.
+ in the metadata in the role above, you'll also need a copy here. You'll also need
+ a <KeyDescriptor> if you want to allow the AA to sign assertions. For the latter reason,
+ as a precaution, we'll include it.
-->
+ <KeyDescriptor use="signing">
+ <ds:KeyInfo>
+ <ds:KeyName>wayf.internet2.edu</ds:KeyName>
+ </ds:KeyInfo>
+ </KeyDescriptor>
<!-- 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"/>
+ Location="https://wayf.internet2.edu:8443/shibboleth-idp/AA"/>
<!-- This tells SPs that you support only the Shib handle format. -->
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<!--
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.
+ 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, in which case
+ no <shibmd:KeyAuthority> extension is needed. This example is more advanced,
+ with the key/certificate identified indirectly using a <ds:KeyName> element
+ containing the common name (CN) from the certificate. The certificate is then
+ validated using the trust anchors found in the applicable <shibmd:KeyAuthority>
+ extension element(s).
+
+ To identify certificates by name, you can use the CN attribute from the Subject,
+ a DNS or URI-valued subjectAltName extension value, or in special cases, the
+ entire Subject DN. We don't suggest the latter, because you must encode the DN
+ in a particular way (LDAP order, separated by commas) and because software is
+ unpredictable in how it will translate the RDN components into a text string.
-->
<KeyDescriptor>
<ds:KeyInfo>
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.
+ SAML profile to use. Each one must have a unique index attribute, mostly
+ for future use in SAML 2.0. The examples below show one endpoint supporting
+ the POST profile, and one endpoint supporting the Artifact profile.
-->
- <AssertionConsumerService index="0"
- Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
- Location="https://wayf.internet2.edu/Shibboleth.shire"/>
+ <AssertionConsumerService index="1"
+ Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
+ Location="https://wayf.internet2.edu/Shibboleth.sso/SAML/POST"/>
+ <AssertionConsumerService index="2"
+ Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
+ Location="https://wayf.internet2.edu/Shibboleth.sso/SAML/Artifact"/>
</SPSSODescriptor>
<!-- This is just information about the entity in human terms. -->
projects / shibboleth / sp.git / blobdiff