Update: Hadn't run across this before. The CAS client was sending an SSO request with the HTTP POST binding, but with the SAMLRequest as a query parameter on the URL, i.e. they were mixing bindings.
https://.../SAML2/POST/SSO?SAMLRequest=... instead of either https://.../SAML2/Redirect/SSO?SAMLRequest=... or https://.../SAML2/POST/SSO with an XHTML form POSTing the SAMLRequest. Tom. On 08/27/2015 01:32 PM, Tom Poage wrote: > Thank you. Discovered some of the non-CAS integrations a little earlier > today. > > So we set up our IdP to treat the vendor like Google (SAML 2.0, no > encryption, etc.). No joy yet. Vendor claims their CAS 3.5.1 is heavily > modified, so the issue is in their lap at the moment. > > Thanks! > Tom. > > On 08/27/2015 12:55 PM, Misagh Moayyed wrote: >> The CAS SAML implementation can work with non-CAS SAML implementations, >> namely Google Apps, JICS portal and few others. It depends, but it's safe >> to say that SAML2 support in CAS specifically is very limited. It may >> receive some attention in future versions. >> >> In terms of (2), I think you'll find the situation with SAML >> implementations almost the same if not slightly worse. Unless the vendor >> is using an implementation you know of and can "trust", like the >> Shibboleth SP software, all bets are off...and since the protocol is more >> difficult to understand, troubleshooting would be more challenging too, >> IMO. > -- 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
