...
To improve the workability of the current CAS SSOut, a lot of improvement would have to be added to existing CAS clients.
- Java cas client --- easy to implement but the uportal integration not working.
- End your browser session.
- Cas does not maintain sessions for applications
- If it did then it would be capable
- Then there is the cas single sign out approach
- It's harder then you can imagine because there are sooo many scenarios that have to be considered
- Cheap trick done in the portal…. Logout page that hit the logout of the applications. It's easier because it's done browser side where you clobber out of the application by executing the logout scripts for the application
- User-education solution and more reliable if best-practices are used by the user "Log out" and "Close Browser People"
- Kiosk browser is not exactly secure…data is still cached to disk and will be obtainable.
- Vendors available to zap disk back to baseline --- costs money
- Enumerate some urls (configured through a text file) that will go through the logout process upon closing the browser (?)
- Shouldn't be a portal-centric thing but a cas-scenric thing where the sign out of cas will know which apps you were using and will go do the right thing to log-out
- Where did the cas implementation start from? It started from the logic of SAML
-. Java: create a mapping between service ticket and the session identifier
- (Adam) session identifier from the app that receives the code block from cas you fake a code block to itself using a cookie and if have a load balancer …
- What kind of effort to get this working: Academus code segments to modernize. Cas side would be more work but more valuable
- Why spend the effort if users are not using the labs since users typically have their laptops? Political Environment
- Cas service registry idea
- Get with Jen and Benito to work on the uPortal cas client integration not working.