Thanks for the thoughtful response. > The risk isn't with redirects, it's when the client web server contacts > the central weblogin server to verify the service cookie (ticket, in CAS > parlance, if I understand things correctly). CAS does this verification > via HTTPS, so that the client web server knows (by verifying the > certificate of the CAS login server when the HTTPS session is > established) that it is talking to a legitimate CAS login server rather > than to a man-in-the-middle or other imposter who might be lying about > the validity of the CAS ticket. The same is true with cosign: when a > client web server establishes a connection to a central weblogin server, > the connection is protected with TLS, and the client web server verifies > the certificate of the central weblogin server.
Sure, so these are equal so far, although the one doesn't require a separate communication channel. > In addition to the cosign client web server verifying the certificate of > the central weblogin server, the cosign client web server also presents > a certificate of its own which the central weblogin server verifies. > This way, the central weblogin server knows that it is in fact talking > to a legitimate whitelisted client web server, which provides stronger > assurance of the client webserver's identity than just IP and DNS > information. This stronger assurance is good especially when proxying > credentials such as Kerberos tickets from the central weblogin server to > the client web servers. This is exactly the same as the assurance > provided by HTTPS client certificates, if/when used. OK, but the only way the client site can get the ticket in the first place is via a redirect issued by the weblogin server, which won't issue one to any other site. > Note that while CAS client website uses HTTPS to query the CAS login > server, cosign client web servers query the central weblogin servers > using a cosign-specific protocol sent over a TLS session. This permits > the cosign client web servers to maintain persistent connections to each > of the central weblogin servers to avoid the overhead of frequent TLS > session establishment. OK, yes, I see there's a performance win there. The CAS callback protocol might benefit from HTTP keep-alive in practice, but if logins are spaced, say, 5 minutes apart, it probably won't. > Cosign > maintains its own list of trusted certificate authorities that is > separate from the list of certificate authorities trusted by web > browsers or web servers -- if cosign's trusted CA list is set to be only > the in-house certificate authority, attackers who compromise commercial > certificate authorities ( > https://www.google.com/#q=certificate+authority+compromised ) will not > be able to issue certificates to subvert cosign back-channel > communications. (Note that the University of Michigan currently uses > its own in-house CA for its central weblogin servers' back-channel > certificate; client web server back-channel certificates can be either > from the same CA or from a list of 3-4 specific trusted commercial CAs). Sure, but an attacker who could take advantage of this could also impersonate both the weblogin site and the web client site, and their browser would give them no indication that this was happening. So they would be able to steal your users' credentials anyway, at least in the common "logging in with a username and password on the web login server" case. Again, thanks for responding so thoughtfully! -- THOMAS BOUTELL, DEV & OPS P'UNK AVENUE | (215) 755-1330 | punkave.com ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
