IdP 3.4.0 provides a new facility to register CAS services in SAML metadata. The following CAS protocol configuration points are configurable via metadata:

One or more CAS service URLs associated with a single logical CAS service.
CAS proxy callback URL and trusted certificates.
CAS single logout participation.

The full specification is described in detail in the CAS metadata profile specification, but there are a few notable configuration points for creating a CAS protocol entry in SAML metadata.

Additionally, note that the resulting relying party "identifier" used throughout the IdP as a policy tool is now configurable. By default, it matches previous behavior and will be the CAS server URL, but the idp.cas.relyingPartyIdFromMetadata property can be enabled to allow the entityID from the SAML metadata instance to be exposed in its place. The use of this property is recommended and seems to be more intutive to most deployers.

CAS Protocol Support

The SPSSODescriptor is the container for all CAS protocol configuration bits. Add https://www.apereo.org/cas/protocol to the protocolSupportEnumeration attribute to identify an entity that supports the CAS protocol.

Service URLs

One or more AssertionConsumerService elements with the binding https://www.apereo.org/cas/protocol/login identify the base service URLs that will request service tickets from the IdP. "Starts with" matching is used to select a given service URL with a metadata ACS URL, but no wildcards are supported. Consider an example:

<AssertionConsumerService
    Binding="https://www.apereo.org/cas/protocol/login"
    Location="https://alpha.example.org/"
    index="1"/>

The entry above would match the following service URLs:

https://alpha.example.org/users
https://alpha.example.org/admins?grp=1
https://alpha.example.org/secure/dashboard

In order to index ACS endpoints to support the matching process, a CAS-specific index, shibboleth.CASMetadataIndices, must be applied to metadata sources that contain CAS protocol entries. The following configuration snippet from conf/metadata-providers.xml provides an example:

CAS Metadata Example

  <MetadataProvider id="CASMetadata"
    xsi:type="FileBackedHTTPMetadataProvider"
    backingFile="/var/run/idp/vt-metadata.xml"
    metadataURL="https://metadata.example.edu/cas.xml"
    indexesRef="shibboleth.CASMetadataIndices">

    <MetadataFilter xsi:type="EntityRole">
      <RetainedRole>samlmd:SPSSODescriptor</RetainedRole>
    </MetadataFilter>
  </MetadataProvider>

Proxy Configuration

One or more AssertionConsumerService elements with the binding https://www.apereo.org/cas/protocol/proxy identify proxy callback endpoints. The appearance of at least one ACS endpoint with the proxy binding is an implicit signal to permit proxying; conversely, if no there is no ACS element defined with the proxy binding, then the service is not authorized to proxy.

Using SAML metadata to register proxying CAS services is a best practice since it affords the most secure method of configuring TLS trust. A best practice for configuring CAS proxy callback endpoints is to generate a self-signed certificate for the HTTPS endpoint and register it in metadata as follows:

Per-service TLS trust configuration

<KeyDescriptor use="signing">
    <ds:KeyInfo>
        <ds:X509Data>
            <ds:X509Certificate>
                MIIDODCCAiCgAwIBAgIJAKpLQTw/WPXCMA0GCSqGSIb3DQEBCwUAMBwxGjAYBgNV
                BAMTEWFscGhhLmV4YW1wbGUub3JnMB4XDTE4MDYxODE2NDE0NVoXDTE4MDcxODE2
                NDE0NVowHDEaMBgGA1UEAxMRYWxwaGEuZXhhbXBsZS5vcmcwggEiMA0GCSqGSIb3
                DQEBAQUAA4IBDwAwggEKAoIBAQDHSzRUcM0WBtAjR3P1vHYkaaATjNKTxbNHn3zS
                3mLnEgukOVFrr+cRByKKUQQb8MIPkuvKrz3lnoCoOwlFMRPigtChjo3UJGTYEMY9
                2SQQr24U6nE/3d2qFaf2PNIW1SinSjxbE1xeT0bdLcTZHUcE2yEfHKFhcgXIJprv
                R1ceBJBvYYnATuPgUxMjq2ks4kXxG0nNlT13QwBfykBv6I1Wkkc06mEvkMzKNtzr
                ayBK1PygVBNVMUQAFn7Tv6c28BtVLFE9SIKj+5ZcpuWkujVNJF1dYdNmfAz3PiuE
                dPt2yl3t2r/v4CP+U8kBlQs6A83xYrA0MsHnUYOrfL3UTWtZAgMBAAGjfTB7MB0G
                A1UdDgQWBBT/5yBm3mXtsYDvz11kTHsPVGeRcDBMBgNVHSMERTBDgBT/5yBm3mXt
                sYDvz11kTHsPVGeRcKEgpB4wHDEaMBgGA1UEAxMRYWxwaGEuZXhhbXBsZS5vcmeC
                CQCqS0E8P1j1wjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQAb/o/M
                mt/nSHOfcjnNJS/LpouaewkoWkQn+FaXZOOvHDYhWur+mHVDpjoszUfgrTX2npmL
                e8Q94bHd+cQrJpZFiYRX8l0p7dAH5Q6Ya/AnHuzGeyQ9fXiDMSWcsg2INcWi7oL9
                h9+V3idcSzgAo1b7+ESSToPj7OG8tgjEp2C9jy0IKEwoApuQtRzxD1XHZFBFwwuH
                nIXWxgctJPU1C+1W9b4bkFSyEGz8/HM7D9feDHbn2AKuRgd99aaOY9D59topf2Zg
                t5sUTWWl54eaF5qoXKY/jdl84Tnmo8GeUufCrS0T6YQGI1LTpicPbqf7zHihQTao
                I1TQuJgghwPvPE9x
            </ds:X509Certificate>
        </ds:X509Data>
        ...
    </ds:KeyInfo>
</KeyDescriptor>

Single Logout

A CAS service registers its intent to participate in single logout by adding a SingleLogoutService element as follows.

Note that the location is a URN, which is intentional, since the CAS logout endpoint cannot be statically defined.

Identity Provider 4

CASServiceSAMLMetadata