Added KeyDescriptor for AA in case it signs.
[java-idp.git] / src / conf / IQ-metadata.xml
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 ../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"
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 Root -->
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                 <Organization>
215                     <OrganizationName xml:lang="en">Example State University</OrganizationName>
216                     <OrganizationDisplayName xml:lang="en">Example State University</OrganizationDisplayName>
217                     <OrganizationURL xml:lang="en">http://shibboleth.internet2.edu/</OrganizationURL>
218                 </Organization>
219                 <ContactPerson contactType="technical">
220                     <SurName>InQueue Support</SurName>
221                     <EmailAddress>inqueue-support@internet2.edu</EmailAddress>
222                 </ContactPerson>
223         </EntityDescriptor>
224
225 </EntitiesDescriptor>