<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>Has anyone else had experience with using CAS? I followed a recipe from an earlier thread but ran into some issues. The original implementation had something like this in the config in each of the Location/LocationMatch blocks in the httpd configuration (using the yaml/generator thing):</div><div><br></div><div><div>AuthType CAS</div><div>AuthName "Private"</div><div>RequestHeader unset Authorization</div><div>AuthLDAPURL....<br></div><div>Require ldap-attribute host=....<br></div><div><br></div><div>This seemed to work until I tried going into interactive apps. They would throw various errors when you tried to launch them. Connection error in any vnc apps, and various auth errors in things like juptyer/rstudio server. After a try it would work just fine.</div><div><br></div><div>After some hair pulling, I noticed when launching an app the client was being bounced to the CAS validation server and back. The redirect was dropping authentication session data for the application (ie, the random password) and so I couldn't connect.</div><div><br></div><div>The issue seemed to be CAS Scope being written to the cookies. Each of the different Location/LocationMatch blocks would generate a different CAS cookie for that specific URI. So any time you jumped between the Location blocks CAS would bounce around cookies. So going from dashboard to an app would result in extra trips to CAS but then on the second load of an app it would be fine. Going back to the dashboard would do the same extra trip but you wouldn't notice since there isn't any session data to drop.</div><div><br></div><div>I found there is a CASScope option to specify the scope for a new cookie (rather than defaulting to the requesting URI), so I applied another setting in the config:</div><div><br></div><div>- 'CASScope /' </div><div><br></div><div>This helped but I was still seeing issue when trying to resume a session left up in a browser overnight or some hours. I could never quite tell if it was because of Cookies written in my browser before the Scope change but I was still seeing the cookies with specific scopes set.</div><div><br></div><div>I ended up going off-script on the httpd config and pulled all the CAS settings into a single <Location "/"> stanza. It felt like somehow I was falling out of the other stanzas and would get bad cookies. Or some old bad cookies were resurrected. Hard to tell. This seems to work, I haven't seen any issues at all since then.</div><div><br></div><div>I'm not totally convinced this last step was necessary but this was very hard to test. I could not reproduce the issue on demand. It only seemed to happen after letting it sit overnight and something timed out. Possibly on the CAS server side - with CAS being the central auth system at the university, it was very hard to avoid using it except overnight... and thus I'd only get one refresh to test changes per day. So I don't think I'm going to try to undo the last change and will leave it at that.</div><div><br></div><div>Anyway, I wanted to share my experiences and see if anyone else has seen anything similar. I'd feel a lot better moving forward with this solution knowing someone else had the same experience. I'm happy to share my complete CAS configuration if anyone is interested.</div><div><br></div><div>Thanks!</div><div><br></div><div>Dan</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Dan Dietz<br>Senior Scientific Applications Analyst<br>ITaP Research Computing, Purdue University</div></div></div></div></div></div></div></div>