Skip to Content.
Sympa Menu

mace-opensaml-users - Re: [OpenSAML] HttpPostEncoder and HttpPostDecoder

Subject: OpenSAML user discussion

List archive

Re: [OpenSAML] HttpPostEncoder and HttpPostDecoder


Chronological Thread 
  • From: rangeli nepal <>
  • To:
  • Subject: Re: [OpenSAML] HttpPostEncoder and HttpPostDecoder
  • Date: Tue, 18 May 2010 21:31:49 -0400
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=eTV2xuF7tLn1TlDEtvwkRUrHAtqaZUQAknni7nV9NJW3Pi8UpqIQ4Vt0cF/vlNNxIK A4yZcFMa36pkFEGsqzOCHaO2f617z8NpK6OXTcoHb/WGuqOh+/q/afUFVKA5JH7AHJZz 9e5WlqLOkRvM4def+Z4jVvpsViM7t/pfWv6Ac=

Thank  you Brent for all these ideas. I am using saml2-post-binding.vm that comes with open saml.

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."

"SAMLRequest-" Dash at the end was my typo.

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.

Thanks again for your time
rn


On Tue, May 18, 2010 at 6:15 PM, Brent Putman <> wrote:

On 5/17/10 8:37 PM, rangeli nepal wrote:
> I was under similar impression. But two things proved me wrong:



Well, I don't know what else to suggest to you.  The form that you are
posting to the decoder does not contain those HTTP form parameters in
the form expected.  Either the form is corrupted or malformed in some
way, or else you are not actually posting what you think you are to the
actual decoder endpoint.

Could there be a redirect in there somewhere such that the form POST is
getting turned into a redirected GET, and losing the form data in the
process?

Or if you constructed your own template (you never answered my original
question) perhaps the form that's being submitted doesn't actually
contain the fields themselves (e.g. perhaps there are multiple <form>
elements and you are submitting the wrong one).



>
> 1. I could see the post data in firefox plugin.
> 2. If I take Inputstream of httpRequestservlet and convert to string I
> was able to get SAMLRequest-"....."
>


I'm assuming that's just a casual typo, but if the form literally has
"SAMLRequest-" (dash on the end) as the hidden <input> name, that is the
source of your problems, b/c that's not the correct field name, it's
"SAMLRequest".

Also, you should be able to validate this on the recipient side (where
the form is posted and the decoder runs) by simply calling:

HttpServletRequest#getParameter("SAMLRequest")

If that returns null, or empty, then that should prove that something is
wrong with the posted data.




Archive powered by MHonArc 2.6.16.

Top of Page