> For step2(logon to app1 use 'renew' through CAS again, get TGC2 (user2)), is > CAS single sign out TGC1 for all applications?
When you sign out, the session corresponding to the TGT you present in your TGC cookie will be destroyed. In your hypothetical scenario, this would be TGC2 exclusively; the CAS server will not associate the first and second TGTs in any way. After all, they're associated with distinct security principals, user1 and user2, by definition. > If not, there is a security hole there. You've not presented any evidence of that with the following. > For example, this following scenario: > a. logon to app1 though CAS, get TGC1 (user1) > b. go to app2 (protected by CAS), get user1 authorized info. > c. logon to app1 use 'renew' through CAS again, get TGC2 (user2). > d. go to app3 (protected by CAS), get user2 authorized info. > e. single sign out. ( will kill TGC2(app1, app3)) > f. app2(user1) is still alive. > > app2 is still alive because the session is out of TGC2 control. You're correct that the app2 session is not associated with TGC2, but there's no security vulnerability there. You haven't demonstrated a method for an attacker to obtain the TGT in TGC1; just because it's been replaced in the user's browser does _not_ mean it's liable to be obtained by an attacker. I want to emphasize that you are exploring an unusual use case by switching authentication credentials on reauthentication. Reauthentication aside, if CAS is presented two different sets of credentials that map to distinct security principals, then it is entirely reasonable to have two distinct SSO sessions represented by distinct TGTs. I would expect any other SSO product to behave similarly. M -- 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
