Page Comparison

...

<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
    <property name="profileConfigurations">
        <list>
            <ref bean="Shibboleth.SSO" />
            <ref bean="SAML1.AttributeQuery" />
            <ref bean="SAML1.ArtifactResolution" />
            <ref bean="SAML2.SSO" />
            <ref bean="SAML2.ECP" />
            <ref bean="SAML2.Logout" />
            <ref bean="SAML2.AttributeQuery" />
            <ref bean="SAML2.ArtifactResolution" />
            <ref bean="CAS.LoginConfiguration" />
            <ref bean="CAS.ProxyConfiguration" />
            <ref bean="CAS.ValidateConfiguration" />
        </list>
    </property>
</bean> 

Define Relying Party Metadata

...

Relying parties that authenticate to the IdP via the CAS protocol are called "services." CAS services don't have any of the configuration concerns of a SAML relying party, but there is a need to define peer entities and related metadata all the same. The service registry provides a CAS analogue to 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.

Code Block
<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.

Service Definition Order

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.

Configure Proxy Trust (Optional)

The IdP uses the PKIX trust model to validate a service that requests a proxy ticket. When the service provides a pgtUrl protocol parameter at ticket validation time, the IdP attempts an HTTP connection to that URL. (The IdP will immediately reject a non-HTTPS proxy callback URL.) Note that the URL is not necessarily the same as that of the requesting service; they are logically separate to allow configuration of different certificate credentials (among other reasons). The proxy callback endpoint must present a certificate that is trusted by the IdP, which requires explicit configuration. The IdP does not use the default Java truststore for this purpose since that would not provide adequate security. The IdP configuration machinery for proxy trust is designed to force deployers to consider what hosts they trust. While this approach requires more effort, it provides the additional security intended for proxy validation.

There are two approaches to proxy trust configuration:

1. List the end-entity certificates of the hosts that are permitted to proxy.
2. List the issuer certificates of hosts that are permitted to proxy.

The second approach only provides meaningful security when you have a small number of certificate authorities that issue Web server certificates with a high degree of identity vetting. If that requirement is not met, configuring end-entity certificates is the recommended approach, but it obviously comes at the cost of additional maintenance as certificates are replaced on the proxying endpoints.

CAS proxy trust is configured in relying-party.xml as part of the profile configuration for a particular relying party. The following configuration excerpt demonstrates configuring CAS to accept proxy callback certificates issued by a handful of trusted issuers for the default relying party.

     <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
                <ref bean="Shibboleth.SSO" />
                <ref bean="SAML1.AttributeQuery" />
                <ref bean="SAML1.ArtifactResolution" />
                <ref bean="SAML2.SSO" />
                <ref bean="SAML2.ECP" />
                <ref bean="SAML2.Logout" />
                <ref bean="SAML2.AttributeQuery" />
                <ref bean="SAML2.ArtifactResolution" />
                <ref bean="CAS.LoginConfiguration" />
                <ref bean="CAS.ProxyConfiguration" />
                <ref bean="CAS.ValidateConfiguration.default" />
            </list>
        </property>
    </bean>
    <bean id="CAS.ValidateConfiguration.default" parent="CAS.ValidateConfiguration">
        <property name="securityConfiguration">
            <bean class="net.shibboleth.idp.profile.config.SecurityConfiguration"
                  c:skew="PT5M"
                  p:clientTLSValidationConfiguration-ref="standardProxyTLSConfig">
                <constructor-arg name="generator">
                    <bean class="net.shibboleth.idp.cas.ticket.impl.TicketIdentifierGenerationStrategy"
                          c:prefix="PGT"
                          c:randomLength="50" />
                </constructor-arg>
            </bean>
        </property>
    </bean>
    <bean id="standardProxyTLSConfig"
          class="org.opensaml.security.x509.tls.impl.BasicClientTLSValidationConfiguration">
        <property name="x509TrustEngine">
            <bean class="org.opensaml.security.x509.impl.PKIXX509CredentialTrustEngine" c:nameEvaluator="#{null}">
                <constructor-arg name="resolver">
                    <bean class="org.opensaml.security.x509.impl.StaticPKIXValidationInformationResolver" c:names="#{null}">
                        <constructor-arg name="info">
                            <bean class="org.opensaml.security.x509.impl.BasicPKIXValidationInformation" c:crls="#{null}" c:depth="5">
                                <constructor-arg name="anchors">
                                    <list>
                                        <bean class="net.shibboleth.ext.spring.factory.X509CertificateFactoryBean"
                                              p:resource="%{idp.home}/credentials/vtgsca.pem" />
                                        <bean class="net.shibboleth.ext.spring.factory.X509CertificateFactoryBean"
                                              p:resource="%{idp.home}/credentials/vtgqsca.pem" />
                                        <bean class="net.shibboleth.ext.spring.factory.X509CertificateFactoryBean"
                                              p:resource="%{idp.home}/credentials/vtgqsca256.pem" />
                                    </list>
                                </constructor-arg>
                            </bean>
                        </constructor-arg>
                    </bean>
                </constructor-arg>
                <constructor-arg name="pkixEvaluator">
                    <bean class="org.opensaml.security.x509.impl.CertPathPKIXTrustEvaluator" />
                </constructor-arg>
            </bean>
        </property>
    </bean>

Service Ticket Expiration (Optional)

CAS Service tickets issued by the Shibboleth IdP are single use tickets with a default validity period of 15 seconds. It is possible to extend the validity period by altering the profile configuration in relying-party.xml as follows:

...

...

Two mechanisms are supported for registering services:

1. Service registry
2. SAML metadata ^3.4

For IdP versions that support SAML metadata, by default the IdP checks all SAML metadata sources first then proceeds to the service registry if and only if no match is found.

Configure Proxy Trust (Optional)

When the service provides a pgtUrl protocol parameter at ticket validation time and the service is authorized to proxy, the IdP attempts an HTTPS connection to that URL. (The IdP will immediately reject a non-HTTPS proxy callback URL.) The proxy callback endpoint must present a certificate that is trusted by the IdP, which requires explicit configuration; in other words, the IdP does not use the default Java truststore for trust material since that would not provide adequate security. The IdP configuration machinery for proxy trust is designed to force deployers to consider what hosts they trust. While this approach requires more effort, it is justified on a few counts:

1. Proxying is a substantial increase in authorization afforded to a service.
2. The callback endpoint receives a credential, so authentication and trust are paramount.
3. TLS authentication is the sole authentication mechanism used to authenticate proxy callback endpoints.

Since certificate trust underpins the last point, it requires adequate treatment to garner meaningful security. The IdP offers two approaches to proxy trust configuration in order of decreasing security:

1. Registration of service-specific end-entity certificates via SAML metadata ^3.4
2. PKIX validation of end-entity certificates based on a set of CA trust anchors.
   
   1. Configure via relying-party.xml ^{3.0,3.1,3.2,3.3}
   2. Configure via cas-protocol.xml ^3.4.2

The second approach only provides meaningful security when you have a small number of certificate authorities that issue Web server certificates with a high degree of identity vetting. If that requirement is not met, configuring end-entity certificates via metadata is the recommended approach.

Alternate cas:user in the validation response (Optional)

CAS validation responses include the user's username. This is generally the normalized username the user logged in with. It is possible to substitute the username in the response with a value from another IdP attribute using the p:userAttribute attribute of CAS.ValidateConfiguration profile in a Relying Party Override.

...