Strict post binding and context.xml parsing error

[micgus]

Hi!

Still a bit new to all this with JBoss, Java and PicketLink so bear with me.

I´m trying to use the quickstarts (both the 2.0.1 and at the moment 2.1.4 - "employee-redirect-valve") but I cannot get this little configuration to work: https://issues.jboss.org/browse/PLFED-271

The setup is: non-PicketLink IdP and hence: redirect and strict post binding is required. A JBoss AS5.

But as soon as I put that the little configuration to my context.xml this is what I get back:

ERROR [JBossContextConfig] XML error parsing: WEB-INF/context.xml

org.jboss.xb.binding.JBossXBException: Failed to parse source: Param not found as a child of Valve in unordered_sequence: attributes?

          at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)

          at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:183)

          at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:133)

          at org.jboss.web.tomcat.service.deployers.JBossContextConfig.processContextConfig(JBossContextConfig.java:573)

Noticed that the "Valve" was case sensitive but the param/Param will not be parsed small or big .

Thanks in advance

/Mike

[micgus]

Just to clearify, this is what I´ve been trying to configure it with:

<Context>

  <Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.SPRedirectFormAuthenticator>

  <param>

                                   <param-name>strictPostBinding</param-name>

       <pram-value>true</param-value>

  </param>

  </Valve>

</Context>

When I tried this variant of the configuration file it at least was parsed without error:

<Context>

  <Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.SPRedirectFormAuthenticator"

  param-name="strictPostBinding"

  param-value="true"/>

</Context>

Sadly I still got the: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect is not supported" from the my external IdP. I´m a bit stuck here now .

One really ugly workaround would be to use a filter to change that manually.... but still, when signing is activated it will mess it up and perhaps the SP need that flag working to be able to accept the SAML Response as POST?