OpenSAML user discussion

[Brent Putman <>]

On 5/18/2010 9:31 PM, rangeli nepal wrote:

 I am using saml2-post-binding.vm that comes with open saml.

Ok.  That template is known to work just fine, it's what we use in the Shibboleth IdP.  Just wanted to eliminate something obvious.
 

I think your suspicions could be true. I am using CXF and restful APIS on top of SAML.
It could be possible that CXF does something that hinders the proper functioning of getParameter function of
HttpServletRequest. I do not have depth in CXF internals but this comments come from that fact that in documentation
of getParameter function itself  has been metioned:

" if the parameter data was sent in the request body, such as occurs with an HTTP POST request,
then reading the body directly via getInputStream() or getReader() can interfere with the execution of this method."

Ok, that does make sense.  If CXF or some other framework code is doing things with the HttpServletRequest before you get access to it (e.g. reading from the InputStream or Reader) and pass it to the decoder (through the HttpServletRequestAdapter), that could account for the issue you are seeing.  You could confirm like I suggested previously, by calling getParameter(String) on the HttpServletRequest before you attempt to use the decoder, and see whether it's null or empty.

If that proves to be the case, then offhand I can think of 2 possible solutions (short of just not using the framework in front of the decoder in the first place):

1) it *might* work to call reset() on the HttpServletRequest's InputStream or Reader before you pass it to the decoder.  Some streams and readers support reset(), others don't. And here the InputStream impl is supplied by the container, as a ServletInputStream. Can't hurt to try, but I have no idea whether that will work.  Might also not be portable between servlet containers.

2) Create your own impl of our HTTPInTransport, probably by just extending our HttpServletRequestAdapter, and pass to its constructor both the HttpServletRequest and whatever CXF or framework data structure(s) provide access to the HTTP POST parameters, and then override the transport/adapter methods to pull the HTTP parameters from the latter rather than the servlet request itself.

Is there a reason why url decoding is not done before base64 decoding.? I am under the impression that form posted
data will be url encoded.  I think it is harmless too.

You mean the values of the individual HTTP POST parameters?  IIRC the HttpServletRequest#getParameter(String) automatically URL decodes the parameter value that it returns.  I may be wrong on that, but I had the same question once and looked it up and thought that's what I discovered.