Sol, If you look at your CAS installation, the file that describes the flow is login-webflow.xml. All of the states have really verbose names, so they should be understandable. I have a rough finite state diagram of it right beside me, however it is on paper and don't have access to a scanner.
1. Setup necessary SWF variables from cookies, HTTP request parameters, etc 2. Check to see if the user might be logged in and if they are but don't want anything, send them to the generic login page 3. If they are logged in and want a service but they have the renew check, make them login again. 4. If they are logged in, want a service, and don't have the renew check, then give them a ST and send them on their way. 5. If they don't have a TGT but have a gateway request, send them back to wherever they came from without forcing CAS login 6. Otherwise, make the user login and upon validation, create the TGT 7. If there was a service specified, create the ST and redirect them back to the application that referred them 8. Otherwise send them to the generic login page There is a bit more to it, but I think you can get the rest by going through /WEB-INF/login-webflow.xml A- -- Andrew Feller, Analyst LSU University Information Services 200 Frey Computing Services Center Baton Rouge, LA 70803 Office: 225.578.3737 Fax: 225.578.6400 -----Original Message----- From: sol myr [mailto:[email protected]] Sent: Thu 2/19/2009 4:34 AM To: [email protected] Subject: [cas-user] comparing the flow of CAS versus OpenSSO Hi, I'm very new to CAS/SSO, and where wondering about its design choise. I'd be grateful if someone has the time to explain: I gather CAS flow is essentially: - Browser authenticates to the SSO server, and receives a reusable TGC cookie. - With this TGC, it can now obtain one-time ST's (ST per application). - With the ST, the browser can connect to the application (the ServletFilter validate the ST against the SSO server). Now, I had a look at OpenSSO. I'm a newbie there too, but I *think* OpenSSO has a shorter flow, kind of like a "reusable ST" shared for all applications: - Browser authenticates to the SSO server, and receives a reusable SsoToken cookie. - With this SsoToken, the browser can connect to all applications (the ServletFilter validates the SsoToken against the SSO server). So I was wondering - why did CAS designers prefer the more 'sophisticated' flow? The best I could come up with was, that if some eavedropping Bad Guy gets hold of an ST (in CAS), he can only break into a single application, and even that requires speed and luck (because ST is one-time)... but then again, if Bad Guy gets hold of the TGC, he can still break into all applications, can't he...? So that is the advantage ? Thanks! -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
