{"type":"doc","content":[{"type":"paragraph","content":[{"text":"File(s):","type":"text","marks":[{"type":"strong"}]},{"text":" ","type":"text"},{"text":"conf/idp.properties","type":"text","marks":[{"type":"em"}]},{"text":", ","type":"text"},{"text":"conf/relying-party.xml, conf/cas-protocol.xml","type":"text","marks":[{"type":"em"}]},{"type":"hardBreak"},{"text":"Format:","type":"text","marks":[{"type":"strong"}]},{"text":" Native Spring","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Overview","type":"text"}]},{"type":"paragraph","content":[{"text":"Shibboleth supports most of the CAS protocol v2 specification including attribute release and CAS proxy support.","type":"text"}]},{"type":"paragraph","content":[{"text":"Other notable features include:","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"The XML response delivered by the ","type":"text"},{"text":"/serviceValidate","type":"text","marks":[{"type":"code"}]},{"text":" URI includes the ","type":"text"},{"text":"","type":"text","marks":[{"type":"code"}]},{"text":" extension supported by most CAS clients.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"CAS proxy support with SSL/TLS trust configuration provided by Shibboleth IdP trust engine.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Simple metadata facility to configure verified relying parties modeled on Jasig/Apereo CAS service registry.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Advanced metadata support using SAML metadata via our ","type":"text"},{"text":"CASMetadataProfile","type":"text","marks":[{"type":"link","attrs":{"href":"/wiki/spaces/SC/pages/1879344655"}}]},{"text":".","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"The CAS protocol requires a server-side ","type":"text"},{"text":"StorageService","type":"text","marks":[{"type":"link","attrs":{"href":"/wiki/spaces/IDP4/pages/1265631707"}}]},{"text":" implementation for the CAS protocol ticket store and the IdP session store ","type":"text"},{"text":"if","type":"text","marks":[{"type":"strong"}]},{"text":" ","type":"text"},{"text":"support for proxy granting tickets is a requirement","type":"text","marks":[{"type":"strong"}]},{"text":". This is relaxed in part with V4.1, with support for initial PGTs but not nested/chained PGTs.","type":"text"}]},{"type":"paragraph","content":[{"text":"Standard tickets can be handled using a ticket store that encodes the necessary data into the ticket, at the cost of slightly reduced ticket security due to lack of one-time-use enforcement.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"CAS Quickstart","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"(V4.1+) Enable CAS module.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Configure suitable storage service.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Add CAS protocol profiles to the default relying party by editing ","type":"text"},{"text":"conf/relying-party.xml","type":"text","marks":[{"type":"em"}]},{"text":".","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Add verified CAS relying parties by editing ","type":"text"},{"text":"conf/cas-protocol.xml","type":"text","marks":[{"type":"em"}]},{"text":".","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Configure SSL/TLS trust (optional; only required for CAS proxy support).","type":"text"}]}]}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Enabling Module (V4.1+)","type":"text"}]},{"type":"paragraph","content":[{"text":"For V4.1+, configuring and using this feature requires that you first enable the \"idp.profile.CAS\" module if it isn't already enabled. Systems upgraded from older releases generally come pre-enabled due to the prior state of the configuration tree.","type":"text"}]},{"type":"codeBlock","content":[{"text":"(Windows)\nC:\\opt\\shibboleth-idp> bin\\module.bat -t idp.profile.CAS || bin\\module.bat -e idp.profile.CAS\n \n(Other)\n$ bin/module.sh -t idp.profile.CAS || bin/module.sh -e idp.profile.CAS","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Configure Storage Service","type":"text"}]},{"type":"paragraph","content":[{"text":"The following properties define the storage service used for IdP sessions and CAS tickets, respectively:","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"idp.session.StorageService","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"idp.cas.StorageService","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"The former is global to all session use, and the latter is used for proxy-granting ticket management and/or if the ","type":"text"},{"text":"SimpleTicketService","type":"text","marks":[{"type":"code"}]},{"text":" component is used (it is not the default).","type":"text"}]},{"type":"paragraph","content":[{"text":"Modify ","type":"text"},{"text":"conf/idp.properties","type":"text","marks":[{"type":"em"}]},{"text":" accordingly to define suitable storage service beans for each subsystem.","type":"text"}]},{"type":"heading","attrs":{"level":5},"content":[{"text":"Sample idp.properties excerpt for CAS","type":"text","marks":[{"type":"strong"}]}]},{"type":"codeBlock","content":[{"text":"idp.session.StorageService=shibboleth.StorageService\nidp.cas.StorageService=shibboleth.StorageService","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Enable CAS Protocol","type":"text"}]},{"type":"paragraph","content":[{"text":"The CAS protocol support is represented with a set of profile configuration beans, one for each of the primary CAS protocol URIs:","type":"text"}]},{"type":"table","attrs":{"layout":"default","localId":"6f6cddaf-a6f7-477d-a59e-d32966095757"},"content":[{"type":"tableRow","content":[{"type":"tableHeader","attrs":{"colspan":1,"rowspan":1,"colwidth":[293.0]},"content":[{"type":"paragraph","content":[{"text":"Profile Bean Name","type":"text"}]}]},{"type":"tableHeader","attrs":{"colspan":1,"rowspan":1,"colwidth":[466.0]},"content":[{"type":"paragraph","content":[{"text":"URI Path","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[293.0]},"content":[{"type":"paragraph","content":[{"text":"CAS.LoginConfiguration","type":"text","marks":[{"type":"strong"}]}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[466.0]},"content":[{"type":"paragraph","content":[{"text":"/login","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[293.0]},"content":[{"type":"paragraph","content":[{"text":"CAS.ProxyConfiguration","type":"text","marks":[{"type":"strong"}]}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[466.0]},"content":[{"type":"paragraph","content":[{"text":"/proxy","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[293.0]},"content":[{"type":"paragraph","content":[{"text":"CAS.ValidateConfiguration","type":"text","marks":[{"type":"strong"}]}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[466.0]},"content":[{"type":"paragraph","content":[{"text":"/serviceValidate, /proxyValidate, /samlValidate","type":"text"}]}]}]}]},{"type":"paragraph","content":[{"text":"Each deals with configuration concerns around the related URI. The profiles are enabled as a function of relying party or relying party group as described in ","type":"text"},{"text":"Profiles and Per-RelyingParty Behavior","type":"text","marks":[{"type":"link","attrs":{"href":"/wiki/spaces/IDP4/pages/1265631678"}}]},{"text":". While each profile may be enabled individually, the only configuration that provides meaningful behavior is one that includes at least ","type":"text"},{"text":"CAS.LoginConfiguration","type":"text","marks":[{"type":"strong"}]},{"text":" and ","type":"text"},{"text":"CAS.ValidateConfiguration.","type":"text","marks":[{"type":"strong"}]},{"text":" The ","type":"text"},{"text":"CAS.ProxyConfiguration","type":"text","marks":[{"type":"strong"}]},{"text":" profile bean is truly optional since omitting it disables proxy support for the relying party, which is a meaningful configuration capability. The following configuration example demonstrates how to enable all CAS protocols for the default relying party.","type":"text"}]},{"type":"heading","attrs":{"level":5},"content":[{"text":"CAS enabled for default relying party","type":"text","marks":[{"type":"strong"}]}]},{"type":"codeBlock","attrs":{"language":"xml"},"content":[{"text":"\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n ","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Define Relying Party Metadata","type":"text"}]},{"type":"paragraph","content":[{"text":"Relying parties that authenticate to the IdP via the CAS protocol are called \"services.\" Two mechanisms are supported for registering services:","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"SAML metadata","type":"text","marks":[{"type":"link","attrs":{"href":"/wiki/spaces/IDP4/pages/1265631632"}}]}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Service registry","type":"text","marks":[{"type":"link","attrs":{"href":"/wiki/spaces/IDP4/pages/1265631631"}}]}]}]}]},{"type":"paragraph","content":[{"text":"By default the IdP checks all SAML metadata sources first then proceeds to the service registry if and only if no match is found. You can adjust this configuration to include only one of these options or reverse the order if desired, per the commented section in ","type":"text"},{"text":"conf/cas-protocol.xml","type":"text","marks":[{"type":"em"}]},{"text":".","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Configure Proxy Trust (Optional)","type":"text"}]},{"type":"paragraph","content":[{"text":"When the service provides a ","type":"text"},{"text":"pgtUrl","type":"text","marks":[{"type":"em"}]},{"text":" 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 ","type":"text"},{"text":"not","type":"text","marks":[{"type":"em"}]},{"text":" 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:","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Proxying is a substantial increase in authorization afforded to a service.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"The callback endpoint receives a credential, so authentication and trust are paramount.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"TLS authentication is the sole authentication mechanism used to authenticate proxy callback endpoints.","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"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:","type":"text"}]},{"type":"orderedList","attrs":{"order":1},"content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Registration of service-specific end-entity certificates via ","type":"text"},{"text":"SAML metadata","type":"text","marks":[{"type":"link","attrs":{"href":"/wiki/spaces/IDP4/pages/1265631632"}}]}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"PKIX validation of end-entity certificates based on a set of CA trust anchors, via","type":"text"},{"text":" cas-protocol.xml","type":"text","marks":[{"type":"link","attrs":{"href":"/wiki/spaces/IDP4/pages/1265631630"}}]}]}]}]},{"type":"paragraph","content":[{"text":"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.","type":"text"}]},{"type":"paragraph","content":[{"text":"Alternate ","type":"text","marks":[{"type":"textColor","attrs":{"color":"#000000"}}]},{"text":"cas:user","type":"text","marks":[{"type":"em"}]},{"text":" in the validation response (Optional)","type":"text","marks":[{"type":"textColor","attrs":{"color":"#000000"}}]}]},{"type":"paragraph","content":[{"text":"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 ","type":"text"},{"text":"p:userAttribute","type":"text","marks":[{"type":"em"}]},{"text":" attribute of ","type":"text"},{"text":"CAS.ValidateConfiguration","type":"text","marks":[{"type":"em"}]},{"text":" profile in a Relying Party Override.","type":"text"}]},{"type":"paragraph","content":[{"text":"In this example, 3 services will get the value of the studentId attribute instead of the standard username. Note that these services are identified by Regex strings instead of standard literal strings.","type":"text"}]},{"type":"codeBlock","attrs":{"language":"xml"},"content":[{"text":"\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\n \t\t\t\n\t \n\t","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"External client configuration","type":"text"}]},{"type":"paragraph","content":[{"text":"As CAS is configured as a new profile for the default relying party, CAS clients should be configured with these values","type":"text"}]},{"type":"table","attrs":{"layout":"default","localId":"2558541e-f158-4ff7-b42a-c0d8d82405aa"},"content":[{"type":"tableRow","content":[{"type":"tableHeader","attrs":{"colspan":1,"rowspan":1,"colwidth":[340.0]},"content":[{"type":"paragraph","content":[{"text":"Property","type":"text"}]}]},{"type":"tableHeader","attrs":{"colspan":1,"rowspan":1,"colwidth":[419.0]},"content":[{"type":"paragraph","content":[{"text":"Value","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[340.0]},"content":[{"type":"paragraph","content":[{"text":"$cas_host","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[419.0]},"content":[{"type":"paragraph","content":[{"text":"idp.example.org","type":"text"}]}]}]},{"type":"tableRow","content":[{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[340.0]},"content":[{"type":"paragraph","content":[{"text":"$cas_context","type":"text"}]}]},{"type":"tableCell","attrs":{"colspan":1,"rowspan":1,"colwidth":[419.0]},"content":[{"type":"paragraph","content":[{"text":"/idp/profile/cas","type":"text"}]}]}]}]},{"type":"paragraph","content":[{"text":"This example is based on PHP CAS Client from Jasig.","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"Ticket Service","type":"text"}]},{"type":"paragraph","content":[{"text":"A stateless ticket service component, ","type":"text"},{"text":"EncodingTicketService","type":"text","marks":[{"type":"code"}]},{"text":", is the default ticket producer and consumer. This component stores ticket metadata in the random part of the ticket identifier using a ","type":"text"},{"text":"DataSealer","type":"text","marks":[{"type":"code"}]},{"text":" component. This component has a couple advantages:","type":"text"}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"No dependency on a ","type":"text"},{"text":"StorageService","type":"text","marks":[{"type":"code"}]},{"text":" component","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","content":[{"text":"Back-channel limitations are removed such that there is no requirement for shared storage between IdP nodes","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"This component should be used where possible. Note that deployers that need CAS proxy support still require stateful ticket storage, so the advantages of ","type":"text"},{"text":"EncodingTicketService","type":"text","marks":[{"type":"code"}]},{"text":" are diminished in that case and the original component ","type":"text"},{"text":"SimpleTicketService","type":"text","marks":[{"type":"code"}]},{"text":" is recommended.","type":"text"}]},{"type":"paragraph","content":[{"text":"It should be noted that some CAS clients cannot accommodate the long identifiers produced by ","type":"text"},{"text":"EncodingTicketService","type":"text","marks":[{"type":"code"}]},{"text":"; ","type":"text"},{"text":"phpCAS","type":"text","marks":[{"type":"em"}]},{"text":" and ","type":"text"},{"text":"mod_auth_cas","type":"text","marks":[{"type":"em"}]},{"text":" are notable clients that can't support the identifiers as of this writing.","type":"text"}]},{"type":"paragraph","content":[{"text":"The choice of ticket service is controlled by configuration in ","type":"text"},{"text":"conf/cas-protocol.xml","type":"text","marks":[{"type":"em"}]},{"text":". Simply comment/uncomment the appropriate configuration for the ticket service you want to use. The default configuration is shown below:","type":"text"}]},{"type":"heading","attrs":{"level":5},"content":[{"text":"Ticket Service Configuration in cas-protocol.xml","type":"text","marks":[{"type":"strong"}]}]},{"type":"codeBlock","attrs":{"language":"xml"},"content":[{"text":"\n\n\n\n","type":"text"}]},{"type":"paragraph","content":[{"type":"hardBreak"}]}],"version":1}