Shibboleth IdP 4.0.1 and CAS

[Max]

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 
requests.

Best Regards,
Max


On Thu, 21 Jan 2021 11:08:00 -0800
  IAM David Bantz <dabantz at alaska.edu> wrote:
> If the incoming requests are addressed to the IdP as 
>cas.myu.edu while the
> IdP is known to SAML services as idp.myu.edu, 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 idp.myu.edu 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 oregonstate.edu>
> 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$ 
>>/idp/profile/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 
>>[R,NE,L]
>>
>> We still have these in place today, working fine.
>>
>> Andy
>>
>>
>> ------------------------------
>> *From:* users <users-bounces at shibboleth.net> on behalf 
>>of Cantor, Scott <
>> cantor.2 at osu.edu>
>> *Sent:* Thursday, January 21, 2021 9:31 AM
>> *To:* Shib Users <users at shibboleth.net>
>> *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 shibboleth.net on behalf of 
>>users at shibboleth.net> 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
>> https://wiki.shibboleth.net/confluence/x/coFAAg
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>> --
>> For Consortium Member technical support, see
>> https://wiki.shibboleth.net/confluence/x/coFAAg
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>