The Shibboleth IdP V4 software will leave support on September 1, 2024.

CASServiceRegistry

File(s): conf/cas-protocol.xml

Format: Native Spring

The CAS service registry provides a simplified alternative to registering CAS relying parties in SAML metadata. A CAS service is verified in the relying party sense if there exists a definition for it in the CAS service registry. Verified relying parties are defined by regular expressions that describe the URL of the CAS service requesting a ticket. Regular expressions are used since a single logical group of services may consist of a number of related URIs, any of which may request CAS tickets. In the world of institutional SSO where CAS has thrived, it's common to permit SSO for all HTTPS services within the DNS domain of the institution; in that case an expression like the following might be used:

https:\/\/([A-Za-z0-9_-]+\.)*example\.org(:\d+)?\/.*

The "unverified" relying party configuration applies to CAS services that have no matching service registry entry, and it is common to have the CAS protocol disabled for unverified relying parties. The net result is one familiar to existing CAS adopters: unregistered services cannot participate in CAS SSO.

Registered services are configured via the cas.serviceRegistry bean in conf/cas-protocol.xml. The following configuration snippet provides an example.

<bean id="cas.serviceRegistry"
      class="net.shibboleth.idp.cas.service.PatternServiceRegistry">
    <property name="definitions">
        <list>
            <bean class="net.shibboleth.idp.cas.service.ServiceDefinition"
                  c:regex="https:\/\/([A-Za-z0-9_-]+\.)*example\.org(:\d+)?\/.*"
                  p:group="institutional-services"
                  p:authorizedToProxy="false" />
        </list>
    </property>
</bean>

The fields of ServiceDefinition are straightforward:

  1. regex - regular expression that defines the logical set of services, by endpoint URI, that belong to the group

  2. group - human-readable name of the group of services

  3. authorizedToProxy - whether members of the group are authorized to request CAS proxy tickets

It's worth noting that the authorizedToProxy flag provides a fine-grained proxy authorization control that interacts with the CAS.ProxyConfiguration profile bean. The flag only applies when the proxy profile is enabled for the affected relying party; in that case proxying may be enabled on a per-service group basis. If proxying is disabled for the relying party, authorizedToProxy=true has no effect.

Order Matters

The order in which service definitions appear in PatternServiceRegistry determines the evaluation order when a CAS service attempts authentication. If two definitions match an overlapping set of services, the first one to produce a match wins. In general, service definitions with more specific patterns should precede those with more general patterns.