Marvin, Thanks for the reply. I have IE6 and IE7 in my organization. I was recently testing IE8 and discovered the new window/tab behavior is different in IE8 then with IE6&7. In IE6 and 7 when I create a new window, or tab, the cookie store and SSL sessions are in sync with each other. So when I get a shared session from a previous window/tab, the cookies and SSL state are shared. In the cases where I get a new window/tab that requires a new SSL negotiation with CAS, the cookie state is empty so CAS will re-authenticate my client certificate.
In IE8 the cookie store is shared so new tabs will get the auth cookie, but gives the user a chance to select a different Client Certificate. I only noticed this was an issue because the application I use to let users manage their profile displays the current Client Certificate and it displayed a certificate that was not registered to anyone's account in CAS (this was in testing). But it displayed the authenticated user's profile information from another tab. Regarding your use case question, I must admit that I can only think of contrived instances where this issue would occur. For example, a shared operating system account where many people have installed their certificates. User A, with admin rights could log in to the browser, not log off. User B could then use the shared account (e.g. they both know the share accounts password to unlock the screen saver), and launch a new instance of IE8 from the desktop icon, taskbar icon, or even a new tab in instance of IE8 that User A left active. If User B went to a different CAS-ified application, he would be challenged for a Client certificate, he would pick his own cert and enter the private key password. CAS would see the TicketGrantingTicket from User A, because IE8 shares cookies, and would ignore the client certificate from user B. Essentially allowing User B to become User A. In my case, when I demonstrated this behavior to my security folks, they were concerned about this new behavior in IE8. I'm looking into writing an extra action in the login webflow to compare the TicketGrantingTicket cookie principal against the principal returned from looking up the certificate in my authentication store. If they are not the same I will destroy the TicketGrantingTicket and display a message to the user that the certificate doesn't match the authentication credentials of the TicketGrantingTicket. Do you think this is the correct preventative action to take? Is there another way to handle this condition? I will admit the probability of this occuring is probably small, but my security folks are concerned with the apparent ability to "spoof" CAS because it only checks for the presence of the ticketgrantingticket cookie when using IE8. -- 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
