Shibboleth IdP 4.0.1 and CAS

Max florima at
Fri Jan 29 15:49:31 UTC 2021

Thank you all for the explanations and suggestions.
Looking more closely at the previous Tomcat 7 configuration, I realized that 
I clamorously missed that a second webapp was also present.
In our case, it's that app that maps the /cas ContextRoot and handles those 

Best Regards,

On Thu, 21 Jan 2021 11:08:00 -0800
  IAM David Bantz <dabantz at> wrote:
> If the incoming requests are addressed to the IdP as 
> while the
> IdP is known to SAML services as, you need 
>to worry about
> internal representation of the server/host name to make 
>the SSO session
> cookie available across protocols. If the cas services 
>are( re-)configured
> to use you don’t have that problem, but for 
>us at least, no
> re-configuration of the cad-based services was important 
>enabler of merging
> cas and saml and turning down the dedicated cas servers.
> David St. Pierre Bantz
> UAlaska IAM
> On 21Jan, 2021 at 09:58:12, Andrew Jason Morgan 
><morgan at>
> wrote:
>> A long time ago, we had /cas as our endpoint when we 
>>used Apereo CAS.
>> When we migrated to Shibboleth, we used these Apache 
>>rewrite rules:
>>         # Rewrite cas URLs to Shibboleth
>>         RewriteRule ^/cas/+serviceValidate$
>> /idp/profile/cas/serviceValidate [PT]
>>         RewriteRule ^/cas/+proxyValidate$ 
>> [PT]
>>         RewriteRule ^/cas/+samlValidate$ 
>>/idp/profile/cas/samlValidate [PT]
>>         RewriteRule ^/cas/+validate$ 
>>/idp/profile/cas/validate [PT]
>>         RewriteRule ^/cas/+(.+)$ /idp/profile/cas/$1 
>> We still have these in place today, working fine.
>> Andy
>> ------------------------------
>> *From:* users <users-bounces at> on behalf 
>>of Cantor, Scott <
>> cantor.2 at>
>> *Sent:* Thursday, January 21, 2021 9:31 AM
>> *To:* Shib Users <users at>
>> *Subject:* Re: Shibboleth IdP 4.0.1 and CAS
>> [This email originated from outside of OSU. Use caution 
>>with links and
>> attachments.]
>> On 1/21/21, 11:54 AM, "users on behalf of Max via users" 
>> users-bounces at on behalf of 
>>users at> wrote:
>> >    It seems that the /cas and /sCAS Context Roots are 
>>no longer present.
>> Neither have ever existed. CAS flows live under 
>>/idp/profile/cas and are
>> automatically registered and logged at startup. Trying 
>>to run them at other
>> locations is something that theoretically can be done 
>>but has never been
>> tested to my knowledge.
>> >    In the file %{idp.home}/conf/services.xml the
>> CASServiceRegistryResources is
>> >    enabled:
>> That has nothing to do with the processing of requests 
>>in the path
>> handling sense, a 404 is a fundamentally broken 
>>container or webapp not
>> starting up to begin with.
>> >    These are the entries we have in the 
>>idp-process.log file related to
>> CAS
>> >    during startup:
>> It logs all the flow definitions and their locations at 
>>startup before
>> that ever happens, but the literal notion of anything 
>>but /idp as a context
>> root (or I guess anything else, doesn't literally have 
>>to be /idp), that
>> doesn't exist. There's one context root and it usually 
>>lives at /idp
>> -- Scott
>> --
>> For Consortium Member technical support, see
>> To unsubscribe from this list send an email to
>> users-unsubscribe at
>> --
>> For Consortium Member technical support, see
>> To unsubscribe from this list send an email to
>> users-unsubscribe at

More information about the users mailing list