Shib IDP/ECP and input error

[Edwards, Wendy A]

Thanks, Scott.

We¹ve updated the CiLogon page with a version of the testecp.sh script
that works.
http://www.cilogon.org/ecp

However, we did need to modify relying-party.xml to make IDP 3 work with
this script:
<bean id="shibboleth.UnverifiedRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
            <!-- <bean parent="SAML2.SSO" p:encryptAssertions="false" />
-->
                <ref bean="SAML2.ECP" />
                <ref bean="SAML2.Logout" />
                <ref bean="SAML2.AttributeQuery" />
                <ref bean="SAML2.ArtifactResolution" />
          </list>
        </property>
    </bean>


We also had to set idp.encryption.optional = true in idp.properties




On 4/27/15, 9:07 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 4/28/15, 1:47 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
>
>>Wendy, I'm afraid you'll have to look into what you're doing, but our
>>Tomcat-hosted IdP on shibboleth.net is working exactly like one in Jetty
>>does. Any content type set, it works, no content type and it throws the
>>error you're getting.
>
>Refining this, it's actually not behaving unusually at all. It's not an
>empty content-type that's buggy, but sending a totally incorrect
>content-type of application/x-www-form-urlencoded.
>
>What's happening is just a curl thing. Not setting a Content-Type header
>on the command line results in a default of
>application/x-www-form-urlencoded, and that fails as it should since
>that's not true. If you set an empty Content-Type parameter, it doesn't
>break it.
>
>So this whole mess is really just a curl command line quirk.
>
>-- Scott
>
>-- 
>To unsubscribe from this list send an email to
>dev-unsubscribe at shibboleth.net