Add a New SP to an IdP

The amount of configuration required to interoperate with a new SP depends heavily on the current configuration environment and the amount of custom behavior needed to interact with this SP. In the best-case scenario where the new SP is part of a federation with which existing trust relationships have been established and release parameters defined, no new configuration is required at all. Other configuration changes needed to communicate with a new SP are listed below according to the functionality needed.

Different Attribute Release
No Mutual Federation
Different Credentials

Different Attribute Release

To specify a new set of attributes to be released to this SP, the only configuration files that need to change are the attribute release policy configuration (often arp.site.xml). If there are new attributes to be defined for this SP, you'll also need to change the attribute resolver configuration (resolver.xml). You will need to know the URN of the attribute, which is defined in resolver.xml , and the providerId for this SP, found in its metadata.

Define a new attribute release rule for this provider that contains the release information desired. For example, to supply EPPN to the SP https://www.evil.edu/webmail , a rule like the following would be used:

<Rule>
	<Target>
		<Requester>https://www.evil.edu/webmail</Requester>
	</Target>
	<Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName">
		<AnyValue release="permit"/>
	</Attribute>
</Rule>

Remember that this SP will also inherit all attribute release rules defined for <AnyTarget/> . Any attribute release enabled there that should not be applied to this SP must be overruled by a deny .

Special instructions will be available for defining this release using ShARPE when it emerges from beta.

No Mutual Federation

If the SP is not a member of a common federation, special metadata will need to be created for it. The distribution contains example-metadata.xml , which is a good template. In general, the SP should provide its own metadata, but if it doesn't, you'll have to write it yourself. You will need to know:

The full URL of the AssertionConsumerService endpoints, such as https://www.evil.edu/Shibboleth.sso/SAML/POST , and which bindings this SP prefers. If this provider is not using Shibboleth, be careful of NameIDFormat too.
The certificate used by this service provider in PEM-encoded form. The CN of the server running the services can be used as well, but using PKI for this has been more difficult in practice than simply sharing certificates.
The providerId this SP will be using.

A full metadata file defining a new SP might look like the following:

<EntityDescriptor entityID="https://www.evil.edu/shibboleth">
	<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">

		<KeyDescriptor use="signing">
			<ds:KeyInfo>
			<ds:X509Data>
				<ds:X509Certificate>
MIIDKDCCApGgAwIBAgICBkowDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
MRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoT
F1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJ
bmZvcm1hdGlvbiBUZWNobm9sb2d5MSUwIwYDVQQDExxIRVBLSSBTZXJ2ZXIgQ0Eg
LS0gMjAwMjA3MDFBMB4XDTA1MTAyNjE3MDMzMloXDTA5MTIwNTE3MDMzMlowZjEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCElsbGlub2lzMRMwEQYDVQQHEwpNZXRyb3Bv
bGlzMRgwFgYDVQQKEw9FdmlsIFVuaXZlcnNpdHkxFTATBgNVBAMTDHd3dy5ldmls
LmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAONdSxUIpcShnGcn
pu+9kiTjaARv4Vn8qM1NDRRg8HlZfAE1uLXmFwqlrg1rB1Z53v/kIkS/CbZMLVFu
wyFvVByTBG0Ouka+seNZSRqa8XtkjGx72JLyoqPRCQd5RCMouJPq/TrSm719wZ9a
fHV3MG/9IrvL1z80+b9gCICqE+VTE4/LXzRvxWThklZKVocSgbKTvNrbGqeRrKXh
mwvWxvze72iTIxw1O4O2xgQI0+2gocpNf45jSDHIEFumgZkL0EW9Dr5Qk6JkcDKm
b+l9SxD/G+WxzbWUXZFM0SJUCQ99H4k8UAv3L7Igxf0+yfXane59emnzS6MVXOIC
YvPlpUkCAwEAAaMdMBswDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCBaAwDQYJKoZI
hvcNAQEEBQADgYEATqtr4/tI4DqxnwAusgxjpCnMxRIVEzTgKLNE0kFxQdH3VOUo
aRnmxi8w/C0oz92xIGuFVGi4fgkvGh8T/xfH0iCKGH/lGPFSwXUsfdz+prOzV8vq
m5G+kv7jBIW+tmoMy1TF1E3fTq7d1gjpooYLt2wejWx72Ow6gjX07C0X2u0=
				</ds:X509Certificate>
			</ds:X509Data>
			</ds:KeyInfo>
		</KeyDescriptor>

		<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>

		<AssertionConsumerService index="1" isDefault="true" 
			Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" 
			Location="https://www.evil.edu/Shibboleth.sso/SAML/POST"/>
		<AssertionConsumerService index="2"
			Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
			Location="https://www.evil.edu/Shibboleth.sso/SAML/Artifact"/>

	</SPSSODescriptor>

	<Organization>
		<OrganizationName xml:lang="en">The Exalted Academie of Evil</OrganizationName>
		<OrganizationDisplayName xml:lang="en">Evil University</OrganizationDisplayName>
		<OrganizationURL xml:lang="en">https://www.evil.edu/</OrganizationURL>
	</Organization>
	<ContactPerson contactType="technical">
		<SurName>Erik Magnus Lehnsherr</SurName>
		<EmailAddress>magneto@evil.edu</EmailAddress>
	</ContactPerson>

</EntityDescriptor>

The resulting metadata file must be referenced by a <MetadataProvider> element in idp.xml .

Different Credentials

In some situations, the IdP may need to use a separate key and certificate to authenticate itself to this SP. This can be painful because certificate and key configuration is split between Apache/Tomcat and Shibboleth, and should be avoided at all costs.

idp.xml
- Add a new <FileResolver> or <KeystoreResolver> element to the <Credentials> element, and give it a unique ID.
- Add a new <RelyingParty> element with name equal to the providerId of the SP and signingCredential equal to the unique ID just defined. Add a <NameID nameMapping="shm"/> element to it.

If the new SP will be making attribute queries of this IdP, a new <VirtualHost> protecting the AA must be defined in httpd.conf on a separate port pointing to these credentials, a new <ProtocolHandler> must be added to idp.xml , and this new endpoint must be added to the IdP's metadata used by this SP.