> Could we then consider this a bug, create JIRAs to make the code changes as > well as updates to the protocol?
I think both would be helpful. Since a potential fix involves protocol improvements, there are additional points of clarification in the proxy aspect of the protocol that could be addressed in this effort. The following text in particular is problematic: This URL MUST be HTTPS, and CAS MUST verify both that the SSL certificate is valid and that its name matches that of the service. The security strength of that check as written is worthless. Strictly speaking a validity check has only to do with the signature and expiration window of the certificate; it does not explicitly or implicitly mention peer trust. Trust is the core premise of security afforded by PKI: you can specify whom you trust and the magic of cryptography provides assurance a peer is within that scope of trust. The Jasig CAS server piggy backs off JSSE and container trust, so in practice peers are validated through secure means. But the protocol spec should at least mention "PKIX trust" or similar to indicate that a stronger check is performed than simply "here's a certificate," which is all that's covered by the text above. Additionally, I recall the following statement didn't provide enough implementation details: CAS uses an HTTP GET request to pass the HTTP request parameters "pgtId" and "pgtIou" to the pgtUrl. These entities are discussed in Sections 3.3 and 3.4, respectively. When working on the Shib-CAS plugin, I had to review CAS server source to fill in some blanks. I don't recall exactly what was unclear, but I believe it related to the exact mechanics of constructing the callback URL and what to do with the server-side identifiers on success. M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
