[shibboleth-sp2] 05/119: Yank InQueue and old Wiki references, simplify defaults.
Ferenc Wágner
wferi-guest at moszumanska.debian.org
Tue Jan 26 21:29:44 UTC 2016
This is an automated email from the git hooks/post-receive script.
wferi-guest pushed a commit to annotated tag 1.3.1
in repository shibboleth-sp2.
commit 42c78603e63aac43722ff2156853efc2ad0f7a4f
Author: Scott Cantor <cantor.2 at osu.edu>
Date: Thu Dec 28 01:49:04 2006 +0000
Yank InQueue and old Wiki references, simplify defaults.
---
configs/AAP.xml.in | 2 +-
configs/IQ-metadata.xml.in | 227 ---------------------------------------------
configs/Makefile.am | 7 --
configs/inqueue.pem | 19 ----
configs/shibboleth.xml.in | 58 +-----------
5 files changed, 6 insertions(+), 307 deletions(-)
diff --git a/configs/AAP.xml.in b/configs/AAP.xml.in
index fb467ad..50861f5 100644
--- a/configs/AAP.xml.in
+++ b/configs/AAP.xml.in
@@ -25,7 +25,7 @@
make up names using it, because the urn:mace:dir namespace tree is
controlled. For help and advice on defining new attributes, refer to:
- https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/AttributeNaming
+ https://spaces.internet2.edu/display/SHIB/AttributeNaming
-->
<!-- First some useful eduPerson attributes that many sites might use. -->
diff --git a/configs/IQ-metadata.xml.in b/configs/IQ-metadata.xml.in
deleted file mode 100644
index 4c78c82..0000000
--- a/configs/IQ-metadata.xml.in
+++ /dev/null
@@ -1,227 +0,0 @@
-<EntitiesDescriptor
- 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: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 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>
-MIICNDCCAaECEAKtZn5ORf5eV288mBle3cAwDQYJKoZIhvcNAQECBQAwXzELMAkG
-A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYD
-VQQLEyVTZWN1cmUgU2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk0
-MTEwOTAwMDAwMFoXDTEwMDEwNzIzNTk1OVowXzELMAkGA1UEBhMCVVMxIDAeBgNV
-BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYDVQQLEyVTZWN1cmUgU2Vy
-dmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGbMA0GCSqGSIb3DQEBAQUAA4GJ
-ADCBhQJ+AJLOesGugz5aqomDV6wlAXYMra6OLDfO6zV4ZFQD5YRAUcm/jwjiioII
-0haGN1XpsSECrXZogZoFokvJSyVmIlZsiAeP94FZbYQHZXATcXY+m3dM41CJVphI
-uR2nKRoTLkoRWZweFdVJVCxzOmmCsZc5nG1wZ0jl3S3WyB57AgMBAAEwDQYJKoZI
-hvcNAQECBQADfgBl3X7hsuyw4jrg7HFGmhkRuNPHoLQDQCYCPgmc4RKz0Vr2N6W3
-YQO2WxZpO8ZECAyIUwxrl0nHPjXcbLm7qt9cuzovk2C2qUtN8iD3zV9/ZHuO3ABc
-1/p3yjkWWW8O6tO1g39NTUJWdrTJXwT4OPjr0l91X817/OWOgHz8UA==
- </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>
- <!-- Bossie Intermediate -->
- <ds:KeyInfo>
- <ds:X509Data>
- <ds:X509Certificate>
-MIIC6zCCAlSgAwIBAgICAlYwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
-MRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoT
-F1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJ
-bmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBNYXN0ZXIgQ0Eg
-LS0gMjAwMjA3MDFBMB4XDTAyMDYzMDIyMzIxNFoXDTI3MDIyMDIyMzIxNFowgakx
-CzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlz
-b24xIDAeBgNVBAoTF1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJE
-aXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBL
-SSBTZXJ2ZXIgQ0EgLS0gMjAwMjA3MDFBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
-iQKBgQCvImusW7uaRS7xLsi2ZzZuUz6gbfATwxwvtQ+8cuyDpRlhvr1qnghC9Enj
-RH9qpq/Z5FVZ5bqyGziCy0kEPt+2WiZMGRiQEzloi5HNEtz1Nlc7FCJ0HATxtkEU
-hQ96v2DmoIEogPINqLICIqfiraPWFHOp6qDritrdj/fwLptQawIDAQABoyAwHjAP
-BgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBpjANBgkqhkiG9w0BAQQFAAOBgQAt
-txlP3fTyIVMAIm8ddE8Bvk0/5Bhn5KvMAOMtnlCEArcFd4/m+pU4vEDwK6JSIoKf
-N/ySLXlu5ItApeJMWhcqvrczq5BF4/WQZukC1ha6FS2cAmjy35jYWMfVWcdBi9Yi
-M4SJ6gjGf83y9axPpuHcjwxQ5fLqZfnvrWH+1owJhQ==
- </ds:X509Certificate>
- </ds:X509Data>
- </ds:KeyInfo>
- </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 role 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. -->
- <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, 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-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. -->
- <shibmd:Scope>example.edu</shibmd:Scope>
- </Extensions>
-
- <!--
- 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. 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:8443/shibboleth-idp/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 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>
- <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. 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="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. -->
- <Organization>
- <OrganizationName xml:lang="en">Example State University</OrganizationName>
- <OrganizationDisplayName xml:lang="en">Example State University</OrganizationDisplayName>
- <OrganizationURL xml:lang="en">http://shibboleth.internet2.edu/</OrganizationURL>
- </Organization>
- <ContactPerson contactType="technical">
- <SurName>InQueue Support</SurName>
- <EmailAddress>inqueue-support at internet2.edu</EmailAddress>
- </ContactPerson>
-
- </EntityDescriptor>
-
-</EntitiesDescriptor>
diff --git a/configs/Makefile.am b/configs/Makefile.am
index b5b92d8..12fbe4a 100644
--- a/configs/Makefile.am
+++ b/configs/Makefile.am
@@ -23,7 +23,6 @@ BUILTCONFIGFILES = \
native.logger \
shibd.logger \
AAP.xml \
- IQ-metadata.xml \
example-metadata.xml
# While BUILTCONFIGFILES are processed, these are not; so we should pull
@@ -78,9 +77,6 @@ shibboleth.xml: ${srcdir}/shibboleth.xml.in Makefile ${top_builddir}/config.stat
AAP.xml: ${srcdir}/AAP.xml.in Makefile ${top_builddir}/config.status
$(MAKE) do-build-file FILE=$@
-IQ-metadata.xml: ${srcdir}/IQ-metadata.xml.in Makefile ${top_builddir}/config.status
- $(MAKE) do-build-file FILE=$@
-
example-metadata.xml: ${srcdir}/example-metadata.xml.in Makefile ${top_builddir}/config.status
$(MAKE) do-build-file FILE=$@
@@ -115,7 +111,6 @@ CLEANFILES = \
native.logger \
shibboleth.xml \
AAP.xml \
- IQ-metadata.xml \
example-metadata.xml
EXTRA_DIST = .cvsignore \
@@ -133,8 +128,6 @@ EXTRA_DIST = .cvsignore \
metadataError.html \
sslError.html \
AAP.xml.in \
- IQ-metadata.xml.in \
example-metadata.xml.in \
- inqueue.pem \
sp-example.key \
sp-example.crt
diff --git a/configs/inqueue.pem b/configs/inqueue.pem
deleted file mode 100644
index be637d6..0000000
--- a/configs/inqueue.pem
+++ /dev/null
@@ -1,19 +0,0 @@
------BEGIN CERTIFICATE-----
-MIIDczCCAlsCBD1z2EAwDQYJKoZIhvcNAQEEBQAwfjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE1p
-Y2hpZ2FuMRIwEAYDVQQHEwlBbm4gQXJib3IxDjAMBgNVBAoTBVVDQUlEMQ0wCwYDVQQLEwRNQUNF
-MSkwJwYDVQQDEyBJbnRlcm5ldDIgU2hpYmJvbGV0aCBTaXRlIFNpZ25lcjAeFw0wMjA5MDIyMTI5
-MzZaFw0wMzA5MDIyMTI5MzZaMH4xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjESMBAG
-A1UEBxMJQW5uIEFyYm9yMQ4wDAYDVQQKEwVVQ0FJRDENMAsGA1UECxMETUFDRTEpMCcGA1UEAxMg
-SW50ZXJuZXQyIFNoaWJib2xldGggU2l0ZSBTaWduZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
-ggEKAoIBAQDc2T68rjx89gaWW6BVp0uj1lem8RkMjG2hbCl3pl9DxK3OFeUVVD0+nOV6i8VLKjIs
-ilOtXqfw/uimj/v3DQLX7AcHiKxTiJAohI+CNvdKZw10LnwB9+uAUh23NQr+rFWhd510X6Ebq/xG
-oPYkeUg4pjMdTtGhKADXC0QuW+cDnJ9AmITeIjY65xtZFf9SR/vckxKsN3nvmhbjFAVYjc6HuZyr
-D9Wu/D5SgCGedND/6sBcIJ6OCdAwdLTgG17Nmd0+vqBpgydWronLbCXtqHw/PMTtep3uTMq8oGRR
-ES/f3YD8E+52r6E2pMakGLOkJogmkha5RJZ2YIIZo7zsGUxpAgMBAAEwDQYJKoZIhvcNAQEEBQAD
-ggEBAML0c77SAqYp24by4xQ9G3KJfrVcHl16wZ74uN4K+tdwVKEDDnXix1Ft1SS6cyzzxycsQ88A
-JzyiLLvlvATygwyBf9uNQp/hP3lG2jKkS6C9mk/VquQVfuNavOUq0iRsUWqPpGEOWirABhpIK4sa
-mjRCBcSGIOHJVHQFO57nehfl/8R3Gs6vkwTea4MZ9iFLJHWSSFn+RcpqcwNoOYV1u+KBkTXtlkl7
-frgiSchqNFAiWR8yN7Qks/SlXQe/7UDr5rY379cUl6ufltHWkGkI+JijUupRGDeVGhUB+gWizzFY
-eC2SFpxb57X77xH5/2CHkzT7CsYgPMUDC60FY07741E=
------END CERTIFICATE-----
-
diff --git a/configs/shibboleth.xml.in b/configs/shibboleth.xml.in
index aa977c0..8989b82 100644
--- a/configs/shibboleth.xml.in
+++ b/configs/shibboleth.xml.in
@@ -57,7 +57,7 @@
<Local logger="@-PKGSYSCONFDIR-@/native.logger" localRelayState="true">
<!--
To customize behavior, map hostnames and path components to applicationId and other settings.
- See: https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/RequestMap
+ See: https://spaces.internet2.edu/display/SHIB/RequestMap
-->
<RequestMapProvider type="edu.internet2.middleware.shibboleth.sp.provider.NativeRequestMapProvider">
<RequestMap applicationId="default">
@@ -88,18 +88,8 @@
having to cover every possible DNS/IP combination the user might enter.
The port and scheme can usually be omitted, so the HTTP request's port and
scheme will be used.
-
- <Alias> elements can specify alternate permissible client-specified server names.
- If a client request uses such a name, normalized redirects will use it, but the
- request map processing is still based on the default name attribute for the
- site. This reduces duplicate data entry in the request map for every legal
- hostname a site might permit. In the example below, only sp.example.org needs a
- <Host> element in the map, but spalias.example.org could be used by a client
- and those requests will map to sp.example.org for configuration settings.
-->
- <Site id="1" name="sp.example.org">
- <Alias>spalias.example.org</Alias>
- </Site>
+ <Site id="1" name="sp.example.org"/>
</ISAPI>
</Implementation>
</Local>
@@ -147,13 +137,7 @@
Binding="urn:mace:shibboleth:sp:1.3:SessionInit"
wayfURL="https://idp.example.org/shibboleth-idp/SSO"
wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/>
-
- <!-- This example directs users to a specific federation's WAYF service. -->
- <SessionInitiator id="IQ" Location="/WAYF/InQueue"
- Binding="urn:mace:shibboleth:sp:1.3:SessionInit"
- wayfURL="https://wayf.internet2.edu/InQueue/WAYF"
- wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/>
-
+
<!--
md:AssertionConsumerService elements replace the old shireURL function with an
explicit handler for particular profiles, such as SAML 1.1 POST or Artifact.
@@ -190,12 +174,7 @@
styleSheet="/shibboleth-sp/main.css"/>
<!-- Indicates what credentials to use when communicating -->
- <CredentialUse TLS="defcreds" Signing="defcreds">
- <!-- RelyingParty elements can customize credentials for specific IdPs/sets. -->
- <!--
- <RelyingParty Name="urn:mace:inqueue" TLS="inqueuecreds" Signing="inqueuecreds"/>
- -->
- </CredentialUse>
+ <CredentialUse TLS="defcreds" Signing="defcreds"/>
<!-- Use designators to request specific attributes or none to ask for all -->
<!--
@@ -208,25 +187,14 @@
<!-- Operational config consists of metadata and trust providers. Can be external or inline. -->
- <!-- Dummy metadata for private testing, delete for production deployments. -->
+ <!-- Example metadata for private testing, delete for production deployments. -->
<MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata"
uri="@-PKGSYSCONFDIR-@/example-metadata.xml"/>
- <!-- InQueue pilot federation, delete for production deployments. -->
- <MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata"
- uri="@-PKGSYSCONFDIR-@/IQ-metadata.xml"/>
-
<!-- The standard trust provider supports SAMLv2 metadata with path validation extensions. -->
<TrustProvider type="edu.internet2.middleware.shibboleth.common.provider.ShibbolethTrust"/>
<!--
- Zero or more SAML Audience condition matches (mainly for Shib 1.1 compatibility).
- If you get "policy mismatch errors, you probably need to supply metadata about
- your SP to the IdP if it's running 1.2. Adding an element here is only a partial fix.
- -->
- <saml:Audience>urn:mace:inqueue</saml:Audience>
-
- <!--
You can customize behavior of specific applications here. The default elements inside the
outer <Applications> element generally have to be overridden in an all or nothing fashion.
That is, if you supply a <Sessions> or <Errors> override, you MUST include all attributes
@@ -265,22 +233,6 @@
<Path>@-PKGSYSCONFDIR-@/sp-example.crt</Path>
</Certificate>
</FileResolver>
-
- <!--
- Mostly you can define a single keypair above, but you can define and name a second
- keypair to be used only in specific cases and then specify when to use it inside a
- <CredentialUse> element.
- -->
- <!--
- <FileResolver Id="inqueuecreds">
- <Key>
- <Path>@-PKGSYSCONFDIR-@/inqueue.key</Path>
- </Key>
- <Certificate>
- <Path>@-PKGSYSCONFDIR-@/inqueue.crt</Path>
- </Certificate>
- </FileResolver>
- -->
</Credentials>
</CredentialsProvider>
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-shibboleth/shibboleth-sp2.git
More information about the Pkg-shibboleth-devel
mailing list