configs/IQ-metadata.xml.in

   1 <EntitiesDescriptor
   2     xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
   3     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   4     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   5     xmlns:shibmd="urn:mace:shibboleth:metadata:1.0"
   6     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"
   7     Name="urn:mace:inqueue"
   8     validUntil="2010-01-01T00:00:00Z">
   9
  10     <Extensions>
  11         <!--
  12         This Shibboleth extension contains a list of CAs that InQueue entities trust as they
  13         evaluate the credentials they receive. They constitute the so-called "root store" or
  14         "trust list" when interacting with the entities included in this file. The VerifyDepth
  15         of "1" is PKIX-specified as the number of intermediaries permitted between the end-entity
  16         certificate and the trust anchor. Each CA certificate is placed in its own <ds:KeyInfo>
  17         container and is base64-encoded.
  18         -->
  19         <shibmd:KeyAuthority VerifyDepth="1">
  20             <!-- Verisign -->
  21             <ds:KeyInfo>
  22                 <ds:X509Data>
  23                     <ds:X509Certificate>
  24 MIICNDCCAaECEAKtZn5ORf5eV288mBle3cAwDQYJKoZIhvcNAQECBQAwXzELMAkG
  25 A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYD
  26 VQQLEyVTZWN1cmUgU2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk0
  27 MTEwOTAwMDAwMFoXDTEwMDEwNzIzNTk1OVowXzELMAkGA1UEBhMCVVMxIDAeBgNV
  28 BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYDVQQLEyVTZWN1cmUgU2Vy
  29 dmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGbMA0GCSqGSIb3DQEBAQUAA4GJ
  30 ADCBhQJ+AJLOesGugz5aqomDV6wlAXYMra6OLDfO6zV4ZFQD5YRAUcm/jwjiioII
  31 0haGN1XpsSECrXZogZoFokvJSyVmIlZsiAeP94FZbYQHZXATcXY+m3dM41CJVphI
  32 uR2nKRoTLkoRWZweFdVJVCxzOmmCsZc5nG1wZ0jl3S3WyB57AgMBAAEwDQYJKoZI
  33 hvcNAQECBQADfgBl3X7hsuyw4jrg7HFGmhkRuNPHoLQDQCYCPgmc4RKz0Vr2N6W3
  34 YQO2WxZpO8ZECAyIUwxrl0nHPjXcbLm7qt9cuzovk2C2qUtN8iD3zV9/ZHuO3ABc
  35 1/p3yjkWWW8O6tO1g39NTUJWdrTJXwT4OPjr0l91X817/OWOgHz8UA==
  36                     </ds:X509Certificate>
  37                  </ds:X509Data>
  38             </ds:KeyInfo>
  39             <!-- Bossie -->
  40             <ds:KeyInfo>
  41                 <ds:X509Data>
  42                     <ds:X509Certificate>
  43 MIIC6zCCAlSgAwIBAgICAlQwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
  44 MRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoT
  45 F1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJ
  46 bmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBNYXN0ZXIgQ0Eg
  47 LS0gMjAwMjA3MDFBMB4XDTAyMDYzMDIyMTYzOVoXDTI5MTExNjIyMTYzOVowgakx
  48 CzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlz
  49 b24xIDAeBgNVBAoTF1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJE
  50 aXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBL
  51 SSBNYXN0ZXIgQ0EgLS0gMjAwMjA3MDFBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
  52 iQKBgQDJ3FDZym9Ja94DP7TUZXf3Vu3CZwqZzYThgjUT2eBJBYVALISSJ+RjJ2j2
  53 CYpq3wesSgWHqfrpPnTgTBvn5ZZF9diX6ipAmC0H75nySDY8B5AN1RbmPsAZ51F9
  54 7Eo+6JZ59BFYgowGXyQpMfhBykBSySnvnOX5ygTCz20LwKkErQIDAQABoyAwHjAP
  55 BgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBpjANBgkqhkiG9w0BAQQFAAOBgQB1
  56 8ZXB+KeXbDVkz+b2xVXYmJiWrp73IOvi3DuIuX1n88tbIH0ts7dJLEqr+c0owgtu
  57 QBqLb9DfPG2GkJ1uOK75wPY6XWusCKDJKMVY/N4ec9ew55MnDlFFvl4C+LkiS2YS
  58 Ysrh7fFJKKp7Pkc1fxsusK+MBXjVZtq0baXsU637qw==
  59                     </ds:X509Certificate>
  60                  </ds:X509Data>
  61             </ds:KeyInfo>
  62             <!-- Bossie Intermediate -->
  63             <ds:KeyInfo>
  64                 <ds:X509Data>
  65                     <ds:X509Certificate>
  66 MIIC6zCCAlSgAwIBAgICAlYwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
  67 MRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoT
  68 F1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJ
  69 bmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBNYXN0ZXIgQ0Eg
  70 LS0gMjAwMjA3MDFBMB4XDTAyMDYzMDIyMzIxNFoXDTI3MDIyMDIyMzIxNFowgakx
  71 CzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlz
  72 b24xIDAeBgNVBAoTF1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJE
  73 aXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBL
  74 SSBTZXJ2ZXIgQ0EgLS0gMjAwMjA3MDFBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
  75 iQKBgQCvImusW7uaRS7xLsi2ZzZuUz6gbfATwxwvtQ+8cuyDpRlhvr1qnghC9Enj
  76 RH9qpq/Z5FVZ5bqyGziCy0kEPt+2WiZMGRiQEzloi5HNEtz1Nlc7FCJ0HATxtkEU
  77 hQ96v2DmoIEogPINqLICIqfiraPWFHOp6qDritrdj/fwLptQawIDAQABoyAwHjAP
  78 BgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBpjANBgkqhkiG9w0BAQQFAAOBgQAt
  79 txlP3fTyIVMAIm8ddE8Bvk0/5Bhn5KvMAOMtnlCEArcFd4/m+pU4vEDwK6JSIoKf
  80 N/ySLXlu5ItApeJMWhcqvrczq5BF4/WQZukC1ha6FS2cAmjy35jYWMfVWcdBi9Yi
  81 M4SJ6gjGf83y9axPpuHcjwxQ5fLqZfnvrWH+1owJhQ==
  82                     </ds:X509Certificate>
  83                  </ds:X509Data>
  84             </ds:KeyInfo>
  85         </shibmd:KeyAuthority>
  86     </Extensions>
  87
  88         <!--
  89         This is a starter set of metadata for the example system used within the
  90         InQueue test federation. The InQueue deployment guide describes how to use
  91         metadatatool or siterefresh to pick up the most current signed files.
  92         Ordinarily a single EntityDescriptor would contain IdP/AA or SP role information,
  93         but not both. The sample site for InQueue just happens to contain both.
  94         -->
  95
  96         <!-- Each IdP or SP is given an EntityDescriptor with its unique providerId/entityID. -->
  97         <EntityDescriptor entityID="urn:mace:inqueue:example.edu">
  98
  99                 <!-- A Shib IdP contains this element with protocol support as shown. -->
 100                 <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
 101                         <Extensions>
 102                                 <!-- This is a Shibboleth extension to express attribute scope rules. -->
 103                                 <shibmd:Scope>example.edu</shibmd:Scope>
 104                         </Extensions>
 105
 106                         <!--
 107                         One or more KeyDescriptors tell SPs how the IdP will authenticate itself. A single
 108                         descriptor can be used for both signing and for server-TLS. You can place an
 109                         X.509 certificate directly in this element for the simplest use cases, in which case
 110                         no <shibmd:KeyAuthority> extension is needed. This example is more advanced,
 111                         with the key/certificate identified indirectly using a <ds:KeyName> element
 112                         containing the common name (CN) from the certificate. The certificate is then
 113                         validated using the trust anchors found in the applicable <shibmd:KeyAuthority>
 114                         extension element(s).
 115
 116                         To identify certificates by name, you can use the CN attribute from the Subject,
 117                         a DNS or URI-valued subjectAltName extension value, or in special cases, the
 118                         entire Subject DN. We don't suggest the latter, because you must encode the DN
 119                         in a particular way (LDAP order, separated by commas) and because software is
 120                         unpredictable in how it will translate the RDN components into a text string.
 121                         -->
 122                         <KeyDescriptor use="signing">
 123                             <ds:KeyInfo>
 124                                 <ds:KeyName>wayf.internet2.edu</ds:KeyName>
 125                             </ds:KeyInfo>
 126                         </KeyDescriptor>
 127
 128                         <!-- This tells SPs where/how to resolve SAML 1.x artifacts into SAML assertions. -->
 129                         <ArtifactResolutionService index="1"
 130                                 Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
 131                                 Location="https://wayf.internet2.edu:8443/shibboleth-idp/Artifact"/>
 132
 133                         <!-- This tells SPs that you support only the Shib handle format. -->
 134                         <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
 135
 136                         <!-- This tells SPs how and where to request authentication. -->
 137                         <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
 138                             Location="https://wayf.internet2.edu/shibboleth-idp/SSO"/>
 139                 </IDPSSODescriptor>
 140
 141                 <!-- Most Shib IdPs also support SAML attribute queries, so this role is also included. -->
 142                 <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
 143                         <Extensions>
 144                                 <!-- This is a Shibboleth extension to express attribute scope rules. -->
 145                                 <shibmd:Scope>example.edu</shibmd:Scope>
 146                         </Extensions>
 147
 148                         <!--
 149                         Note that when TLS with certificate validation is used, there may be no <KeyDescriptor>
 150                         needed. Since server TLS is used to authenticate the AA, its <ds:KeyName> is implicit
 151                         in the URL used to connect to it. If you were to place the certificate directly
 152                         in the metadata in the role above, you'll also need a copy here. You'll also need
 153                         a <KeyDescriptor> if you want to allow the AA to sign assertions. For the latter reason,
 154                         as a precaution, we'll include it.
 155                         -->
 156                         <KeyDescriptor use="signing">
 157                             <ds:KeyInfo>
 158                                 <ds:KeyName>wayf.internet2.edu</ds:KeyName>
 159                             </ds:KeyInfo>
 160                         </KeyDescriptor>
 161
 162                         <!-- This tells SPs how and where to send queries. -->
 163                         <AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
 164                             Location="https://wayf.internet2.edu:8443/shibboleth-idp/AA"/>
 165
 166                         <!-- This tells SPs that you support only the Shib handle format. -->
 167                         <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
 168                 </AttributeAuthorityDescriptor>
 169
 170                 <!-- A Shib SP contains this element with protocol support as shown. -->
 171                 <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
 172
 173                         <!--
 174                         One or more KeyDescriptors tell IdPs how the SP will authenticate itself. A single
 175                         descriptor can be used for both signing and for server-TLS. You can place an
 176                         X.509 certificate directly in this element for the simplest use cases, in which case
 177                         no <shibmd:KeyAuthority> extension is needed. This example is more advanced,
 178                         with the key/certificate identified indirectly using a <ds:KeyName> element
 179                         containing the common name (CN) from the certificate. The certificate is then
 180                         validated using the trust anchors found in the applicable <shibmd:KeyAuthority>
 181                         extension element(s).
 182
 183                         To identify certificates by name, you can use the CN attribute from the Subject,
 184                         a DNS or URI-valued subjectAltName extension value, or in special cases, the
 185                         entire Subject DN. We don't suggest the latter, because you must encode the DN
 186                         in a particular way (LDAP order, separated by commas) and because software is
 187                         unpredictable in how it will translate the RDN components into a text string.
 188                         -->
 189                         <KeyDescriptor>
 190                             <ds:KeyInfo>
 191                                 <ds:KeyName>wayf.internet2.edu</ds:KeyName>
 192                             </ds:KeyInfo>
 193                         </KeyDescriptor>
 194
 195                         <!-- This tells IdPs that you support only the Shib handle format. -->
 196                         <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
 197
 198                         <!--
 199                         This tells IdPs where and how to send authentication assertions. Mostly
 200                         the SP will tell the IdP what location to use in its request, but this
 201                         is how the IdP validates the location and also figures out which
 202                         SAML profile to use. Each one must have a unique index attribute, mostly
 203                         for future use in SAML 2.0. The examples below show one endpoint supporting
 204                         the POST profile, and one endpoint supporting the Artifact profile.
 205                         -->
 206                         <AssertionConsumerService index="1"
 207                                 Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
 208                                 Location="https://wayf.internet2.edu/Shibboleth.sso/SAML/POST"/>
 209                         <AssertionConsumerService index="2"
 210                                 Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
 211                                 Location="https://wayf.internet2.edu/Shibboleth.sso/SAML/Artifact"/>
 212                 </SPSSODescriptor>
 213
 214                 <!-- This is just information about the entity in human terms. -->
 215                 <Organization>
 216                     <OrganizationName xml:lang="en">Example State University</OrganizationName>
 217                     <OrganizationDisplayName xml:lang="en">Example State University</OrganizationDisplayName>
 218                     <OrganizationURL xml:lang="en">http://shibboleth.internet2.edu/</OrganizationURL>
 219                 </Organization>
 220                 <ContactPerson contactType="technical">
 221                     <SurName>InQueue Support</SurName>
 222                     <EmailAddress>inqueue-support@internet2.edu</EmailAddress>
 223                 </ContactPerson>
 224
 225         </EntityDescriptor>
 226
 227 </EntitiesDescriptor>