> SAML1 profiles are still valid in the InCommon federation mostly via > Shib, but what does that have to do with the way CAS 3.x is using > SAML1 markup via samlValidate?
It's important in my mind that we have built functionality around a current, relevant protocol. > I'd suggest little if any from a practical or interop perspective. I think that's a fair criticism, but it has little if anything to do with SAML 1.1 per se. > Charade in the sense that just using the SAML1.0 markup does not > afford interop with non-cas-SAML entities nor has it conferred any > significant benefit to the CAS3.x community. The attribute release mechanism of CAS is a huge benefit judging from volume of cas-user discussion on the topic; consequently SAML 1.1 has substantial value. Could the feature have been developed in another protocol? Sure. Could we ditch SAML for some hypothetical CAS 2.1 protocol? Sure. But note you'll be dumping and rewriting a substantial amount of code to do it. I believe the burden is on you to demonstrate the benefit. > The inclusion of SAML1.0 markup and endpoints has complicated that > overall CAS product and allowed the CAS protocol to stagnate. To be clear, you're claiming that a single URI, /samlValidate, and presumably the handful of related components have significantly complicated the product? Not buying it. > adding attributes to the CAS payload via extension of the CAS protocol > in hindsight seems like a better deal I think there are arguments to support this viewpoint, but I don't share it. Adopting a standard protocol like SAML was a wise choice for both marketing and interop reasons. Cutting our teeth on SAML 1.1 for attribute release and single sign out opened the door for interop with Google Apps via SAML 2. SAML protocol support has provided substantial functionality for reasonable complexity. > and is what many in the community have done in practice. Based on discussion on cas-user over the past couple years, I have the impression that as many have done this out of ignorance of the out-of-box SAML support as having a valid need. > It don't think it is as big a lift as you make > it out to be, what is missing is updates to the CAS protocol doc and > better support in the clients. It's a lift of some undermined effort for nothing gained. We already have SAML support in the clients and we've sunk substantial energy and engineering effort on making it work well. I'm simply not willing to throw that away for feature parity under some other implementation. For what it's worth, we have so much invested in SAML attribute release and single sign out that we would likely fork CAS before adopting a future version without. 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
