AWS + ECP?

[Brent Putman]

On 2/4/16 5:23 PM, Brent Putman wrote:
>
> Yeah, so with the right content type, does the IdP still log the same
> XML parsing error?  If so, I'm at a loss.  Need to confirm, b/c it's
> entirely possible that it's getting past the parsing but then throwing
> a fatal error which results in the 500 and SOAP fault you previously
> posted, for example something specific to the authN or ECP case.  For
> example, not sure off-hand what that would return if for example basic
> authN isn't configured correctly and so there's no REMOTE_USER visible
> in the request.


I hate flying blind, so I grabbed that aws.plugin.bash script, ripped
out what wasn't relevant to just making the ECP request, and ran it
against my v3 IdP.  With no explicit content type header, it sends
application/x-www-form-urlencoded, and that results in the XML parsing
error.

With the text/xml, it actually "works", in that it gets past the XML
parsing and the decoding step.  (It then fails with a 500 and SOAP fault
b/c I don't have other stuff configured, but that's ok, that's expected.)

So I don't know *why* the parsing fails with the wrong content type;
IdP/OpenSAML doesn't look at it AFAIK.  I suspect it's something
non-obvious in the servlet container layer, or Spring MVC or SWF that's
mucking with what we see in the request.  Which IIRC is what we thought
before, but can't remember if anyone actually figured it out yet.  But
the workaround for now is to explicitly send the content type and that
should work as far as the fundamental message processing goes.

I suspect you've now got that part working, and you've now got some
other issues with ECP or authN or profile config that's resulting in the
500 and fault, that you need to sort out. So the logs are your friend
there...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160204/ede2b306/attachment.html>