Let me clarify that I'm not saying CAS is deficient or that the extra stuff done by cosign is strictly necessary. I'm just saying why cosign does some of the things the way it does; there are, of course, other ways to do things.
On 2015-02-07 11:35, Tom Boutell wrote: >> 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. Yes, but how does the client site know that the ticket is legitimate? In the case of cosign service cookies, they are just random numbers. If a malicious party sends a request to the client web server with a fake cosign service cookie and somehow manages to intercept and reply to the validation request (such as man in the middle attack between the client web server and the central weblogin server) then they can say that the fake cosign service cookie is valid and get the client web server to give access to user data for arbitrary users. In the case of CAS, this attack is thwarted by verifying the CAS login server HTTPS certificate during the validation request; in the case of cosign, the attack is thwarted by verifying the central weblogin server back-channel certificate (which could be the same as the weblogin server HTTPS certificate, if you wanted) when the connection to the central weblogin server is established. >> 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. It's not just about logins: I don't know the details of CAS, but in addition to cosign checking the service cookie during when the user first accesses the client web server, the service cookie is checked with the central weblogin server for any future HTTPS request the user makes to the client web server, if the cookie has not been checked in the previous 60 seconds. These checks are how the client web server knows if the user has centrally logged out, among other things. It's also about load balancing and fault tolerance: a single client web server will attempt to keep persistent connections open to all central weblogin servers. The central weblogin servers make a "best effort" attempt to replicate all login session data between all of them, but in theory the central weblogin servers could become get out of sync with one another temporarily due to network failures / partitioning or other problems. When checking a cosign service cookie (either on first access or if 60 seconds have passed since a check caused by a previous access), the client web server will check with each of the central weblogin servers in turn until it finds one that can supply a definitive answer to the check. Since the connections to the central weblogin servers are persistent, these checks are very quick and efficient since TLS session establishment only needs to be attempted if a particular connection has failed AND if none of the other, still-open, connections returned a definitive answer. >> 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 > 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. Yep, but just because that's possible on the front end due to the broken nature of CA trusts for HTTPS certificates doesn't mean that having the option to configure things to prevent a CA-based attack on the back end is bad. I imagine you could achieve the same thing with CAS by configuring all of the non-user HTTPS traffic to go to a separate web virtual host on the CAS login server that used an in-house CA, required a valid HTTPS client certificate from the client web server signed by the same in-house CA for all requests, and had the client web servers only trust the in-house CA for the CAS login server requests that they sent. To do this, CAS would have to allow server/ports in the URL for user logins than for client web server requests, and would have to have a directive via which the client web server could specify which CAs it will trust for requests sent to the CAS login server. -- Mark Montague m...@catseye.org ------------------------------------------------------------------------------ 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
