Fixed inconsistent shib metadata prefix.
[shibboleth/sp.git] / 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         <!-- This extension contains the list of CAs used by InQueue entities.  -->
12         <shibmd:KeyAuthority VerifyDepth="1">
13             <!-- Verisign -->
14             <ds:KeyInfo>
15                 <ds:X509Data>
16                     <ds:X509Certificate>
17 MIICNDCCAaECEAKtZn5ORf5eV288mBle3cAwDQYJKoZIhvcNAQECBQAwXzELMAkG
18 A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYD
19 VQQLEyVTZWN1cmUgU2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk0
20 MTEwOTAwMDAwMFoXDTEwMDEwNzIzNTk1OVowXzELMAkGA1UEBhMCVVMxIDAeBgNV
21 BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYDVQQLEyVTZWN1cmUgU2Vy
22 dmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGbMA0GCSqGSIb3DQEBAQUAA4GJ
23 ADCBhQJ+AJLOesGugz5aqomDV6wlAXYMra6OLDfO6zV4ZFQD5YRAUcm/jwjiioII
24 0haGN1XpsSECrXZogZoFokvJSyVmIlZsiAeP94FZbYQHZXATcXY+m3dM41CJVphI
25 uR2nKRoTLkoRWZweFdVJVCxzOmmCsZc5nG1wZ0jl3S3WyB57AgMBAAEwDQYJKoZI
26 hvcNAQECBQADfgBl3X7hsuyw4jrg7HFGmhkRuNPHoLQDQCYCPgmc4RKz0Vr2N6W3
27 YQO2WxZpO8ZECAyIUwxrl0nHPjXcbLm7qt9cuzovk2C2qUtN8iD3zV9/ZHuO3ABc
28 1/p3yjkWWW8O6tO1g39NTUJWdrTJXwT4OPjr0l91X817/OWOgHz8UA==
29                     </ds:X509Certificate>
30                  </ds:X509Data>
31             </ds:KeyInfo>
32             <!-- Bossie -->
33             <ds:KeyInfo>
34                 <ds:X509Data>
35                     <ds:X509Certificate>
36 MIIC6zCCAlSgAwIBAgICAlQwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
37 MRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoT
38 F1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJ
39 bmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBNYXN0ZXIgQ0Eg
40 LS0gMjAwMjA3MDFBMB4XDTAyMDYzMDIyMTYzOVoXDTI5MTExNjIyMTYzOVowgakx
41 CzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlz
42 b24xIDAeBgNVBAoTF1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJE
43 aXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBL
44 SSBNYXN0ZXIgQ0EgLS0gMjAwMjA3MDFBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
45 iQKBgQDJ3FDZym9Ja94DP7TUZXf3Vu3CZwqZzYThgjUT2eBJBYVALISSJ+RjJ2j2
46 CYpq3wesSgWHqfrpPnTgTBvn5ZZF9diX6ipAmC0H75nySDY8B5AN1RbmPsAZ51F9
47 7Eo+6JZ59BFYgowGXyQpMfhBykBSySnvnOX5ygTCz20LwKkErQIDAQABoyAwHjAP
48 BgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBpjANBgkqhkiG9w0BAQQFAAOBgQB1
49 8ZXB+KeXbDVkz+b2xVXYmJiWrp73IOvi3DuIuX1n88tbIH0ts7dJLEqr+c0owgtu
50 QBqLb9DfPG2GkJ1uOK75wPY6XWusCKDJKMVY/N4ec9ew55MnDlFFvl4C+LkiS2YS
51 Ysrh7fFJKKp7Pkc1fxsusK+MBXjVZtq0baXsU637qw==
52                     </ds:X509Certificate>
53                  </ds:X509Data>
54             </ds:KeyInfo>
55             <!-- Bossie Intermediate -->
56             <ds:KeyInfo>
57                 <ds:X509Data>
58                     <ds:X509Certificate>
59 MIIC6zCCAlSgAwIBAgICAlYwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
60 MRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoT
61 F1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJ
62 bmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBNYXN0ZXIgQ0Eg
63 LS0gMjAwMjA3MDFBMB4XDTAyMDYzMDIyMzIxNFoXDTI3MDIyMDIyMzIxNFowgakx
64 CzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlz
65 b24xIDAeBgNVBAoTF1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJE
66 aXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBL
67 SSBTZXJ2ZXIgQ0EgLS0gMjAwMjA3MDFBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
68 iQKBgQCvImusW7uaRS7xLsi2ZzZuUz6gbfATwxwvtQ+8cuyDpRlhvr1qnghC9Enj
69 RH9qpq/Z5FVZ5bqyGziCy0kEPt+2WiZMGRiQEzloi5HNEtz1Nlc7FCJ0HATxtkEU
70 hQ96v2DmoIEogPINqLICIqfiraPWFHOp6qDritrdj/fwLptQawIDAQABoyAwHjAP
71 BgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBpjANBgkqhkiG9w0BAQQFAAOBgQAt
72 txlP3fTyIVMAIm8ddE8Bvk0/5Bhn5KvMAOMtnlCEArcFd4/m+pU4vEDwK6JSIoKf
73 N/ySLXlu5ItApeJMWhcqvrczq5BF4/WQZukC1ha6FS2cAmjy35jYWMfVWcdBi9Yi
74 M4SJ6gjGf83y9axPpuHcjwxQ5fLqZfnvrWH+1owJhQ==
75                     </ds:X509Certificate>
76                  </ds:X509Data>
77             </ds:KeyInfo>
78         </shibmd:KeyAuthority>
79     </Extensions>
80
81         <!--
82         This is a starter set of metadata for the example system used within the
83         InQueue test federation. The InQueue deployment guide describes how to use
84         metadatatool or siterefresh to pick up the most current signed files.
85         Ordinarily a single EntityDescriptor would contain IdP/AA or SP role information,
86         but not both. The sample site for InQueue just happens to contain both.
87         -->
88
89         <!-- Each IdP or SP is given an EntityDescriptor with its unique providerId/entityID. -->
90         <EntityDescriptor entityID="urn:mace:inqueue:example.edu">
91                 
92                 <!-- A Shib IdP contains this element with protocol support as shown. -->
93                 <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
94                         <Extensions>
95                                 <!-- This is a Shibboleth extension to express attribute scope rules. -->
96                                 <shibmd:Scope>example.edu</shibmd:Scope>
97                         </Extensions>
98                         
99                         <!--
100                         One or more KeyDescriptors tell SPs how the IdP will authenticate itself. A single
101                         descriptor can be used for both signing and for server-TLS. You can place an
102                         X.509 certificate directly in this element for the simplest use cases. This
103                         example is more advanced, with the key/certificate identified by common name.
104                         The certificate is then validated using the KeyAuthority extension element up
105                         above.
106                         -->
107                         <KeyDescriptor use="signing">
108                             <ds:KeyInfo>
109                                 <ds:KeyName>wayf.internet2.edu</ds:KeyName>
110                             </ds:KeyInfo>
111                         </KeyDescriptor>
112
113                         <!-- This tells SPs where/how to resolve SAML 1.x artifacts into SAML assertions. -->
114                         <ArtifactResolutionService index="1"
115                                 Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
116                                 Location="https://wayf.internet2.edu:8443/shibboleth-idp/Artifact"/>
117                         
118                         <!-- This tells SPs that you support only the Shib handle format. -->
119                         <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
120                         
121                         <!-- This tells SPs how and where to request authentication. -->
122                         <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
123                             Location="https://wayf.internet2.edu/shibboleth-idp/SSO"/>
124                 </IDPSSODescriptor>
125                 
126                 <!-- Most Shib IdPs also support SAML attribute queries, so this role is also included. -->
127                 <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
128                         <Extensions>
129                                 <!-- This is a Shibboleth extension to express attribute scope rules. -->
130                                 <shibmd:Scope>example.edu</shibmd:Scope>
131                         </Extensions>
132                         
133                         <!--
134                         Note that because TLS with certificate validation is used, there is no KeyDescriptor
135                         needed. Since server TLS is used to authenticate the AA, its "key name" is implicit
136                         in the URL used to connect to it. If you were to place the certificate directly
137                         in the metadata in the role above, you'll also need a copy here.
138                         -->
139                         
140                         <!-- This tells SPs how and where to send queries. -->
141                         <AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
142                             Location="https://wayf.internet2.edu:8443/shibboleth-idp/AA"/>
143                             
144                         <!-- This tells SPs that you support only the Shib handle format. -->
145                         <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
146                 </AttributeAuthorityDescriptor>
147                 
148                 <!-- A Shib SP contains this element with protocol support as shown. -->
149                 <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
150                 
151                         <!--
152                         One or more KeyDescriptors tell IdPs how the SP will authenticate itself. A single
153                         descriptor can be used for both signing and for client-TLS. You can place an
154                         X.509 certificate directly in this element for the simplest use cases. This
155                         example is more advanced, with the key/certificate identified by common name.
156                         The certificate is then validated using the KeyAuthority extension element up
157                         above.
158                         -->
159                         <KeyDescriptor>
160                             <ds:KeyInfo>
161                                 <ds:KeyName>wayf.internet2.edu</ds:KeyName>
162                             </ds:KeyInfo>
163                         </KeyDescriptor>
164                         
165                         <!-- This tells IdPs that you support only the Shib handle format. -->
166                         <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
167                     
168                         <!--
169                         This tells IdPs where and how to send authentication assertions. Mostly
170                         the SP will tell the IdP what location to use in its request, but this
171                         is how the IdP validates the location and also figures out which
172                         SAML profile to use.
173                         -->
174                         <AssertionConsumerService index="1"
175                                 Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
176                                 Location="https://wayf.internet2.edu/Shibboleth.sso/SAML/POST"/>
177                         <AssertionConsumerService index="2"
178                                 Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
179                                 Location="https://wayf.internet2.edu/Shibboleth.sso/SAML/Artifact"/>
180                 </SPSSODescriptor>
181                 
182                 <!-- This is just information about the entity in human terms. -->
183                 <Organization>
184                     <OrganizationName xml:lang="en">Example State University</OrganizationName>
185                     <OrganizationDisplayName xml:lang="en">Example State University</OrganizationDisplayName>
186                     <OrganizationURL xml:lang="en">http://shibboleth.internet2.edu/</OrganizationURL>
187                 </Organization>
188                 <ContactPerson contactType="technical">
189                     <SurName>InQueue Support</SurName>
190                     <EmailAddress>inqueue-support@internet2.edu</EmailAddress>
191                 </ContactPerson>
192                 
193         </EntityDescriptor>
194
195 </EntitiesDescriptor>