Unfortunatly, I never got resolution on this. Here is my ticket for the OneLogin PHP-SAML lib: https://github.com/onelogin/php-saml/issues/390
OneLogin quoted this from the SAML spec: 3.5.4 Message Encoding Messages are encoded for use with this binding by encoding the XML into an HTML form control and are transmitted using the HTTP POST method. A SAML protocol message is form-encoded by applying the base-64 encoding rules to the XML representation of the message and placing the result in a hidden form control within a form as defined by [HTML401] Section 17. The HTML document MUST adhere to the XHTML specification, [XHTML]. The base64-encoded value MAY be line-wrapped at a reasonable length in accordance with common practice. I'm fairly confident that we have other clients using CAS as an IdP and they are sending base64 encoded responses. Perhaps this is a configuration (though I have not been able to locate such a setting) or something that is only an issue on specific versions of CAS. On Thursday, November 21, 2019 at 12:48:33 PM UTC-5, Robert Bond wrote: > > I have been running into this same issue for quite a while now. Have not > been able to identify the source. > > On Thu, Nov 21, 2019 at 11:25 AM Chris G <[email protected] <javascript:>> > wrote: > >> I'm just wondering if anyone figured this out. I have the same >> issue--SAML Responses from CAS are NOT base64 encoded, but all the clients >> I have seem to expect the SAML Response to be base64 encoded. >> >> Is this a SAML spec, that it should be base64 encoded and CAS isn't >> implementing it properly? >> >> >> On Wednesday, September 18, 2019 at 4:55:58 PM UTC-4, Chris H wrote: >>> >>> >>> I am working with client who's running a CAS server (a backpatched >>> version of 3.4.12) as their IdP. We are trying to connect this with our >>> product, a SAML SP implemented with OneLogin's PHP client. >>> >>> The issue we are having is that the "SAMLResponse" POST parameter is >>> coming over in raw form, ie it is not base64 encoded. The OneLogin lib >>> appears to assume that this value is base64 encoded and throws an exception >>> when it is not. I do not see any configuration to override this behaviour. >>> >>> Is it possible to configure CAS to base64 encode this value before >>> sending? >>> >>> Any idea why this would be happening? We have several active SAML2 >>> integrations with other clients who use CAS as their IdP. >>> >>> Thanks! >>> Chris >>> >> -- >> - Website: https://apereo.github.io/cas >> - Gitter Chatroom: https://gitter.im/apereo/cas >> - List Guidelines: https://goo.gl/1VRrw7 >> - Contributions: https://goo.gl/mh7qDG >> --- >> You received this message because you are subscribed to the Google Groups >> "CAS Community" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/a/apereo.org/d/msgid/cas-user/464a638f-6566-474b-b2d3-74202141986d%40apereo.org >> >> <https://groups.google.com/a/apereo.org/d/msgid/cas-user/464a638f-6566-474b-b2d3-74202141986d%40apereo.org?utm_medium=email&utm_source=footer> >> . >> > > > -- > Robert Bond > Network Administrator > (918) 444-5886 > Northeastern State University > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/74cf1a4d-1d61-41d8-8bb1-1fd5204b31d3%40apereo.org.
