2 Replies Latest reply on Oct 3, 2014 11:07 PM by Pedro Igor

    Picketlink IdP and mod_mellon SP integration

    Simone Gotti Newbie

      Hi,

       

      before opening some issues on jira, I'd like to explain them here.

       

      mod_mellon is using lasso as the underlying saml library.

       

      To make mod_mellon work with a picketlink idp I faced two issues:

       

      1) mod_mellon does not set the AssertionConsumerServiceURL attribute in the AuthnRequest. In picketlink the SAML2AuthenticationHandler is expecting this attribute and fail with a NullPointerException.

       

      I took a look at the saml2 spec in saml-core-2.0-os.pdf and tried to understand how it should behave. I tried to fix this in these 3 patches.

       

      The first one (https://github.com/motaboy/federation/commit/466cb8147cdfdc49dd6837770729ebcb777fdd15) introduces a test case. It will fail with the current picketlink version.

       

      The second one (https://github.com/motaboy/federation/commit/7513c1f021a4ecdad63372132131678ceb984dba) changes the SAMLEntityDescriptorParser as the spec says that if the isDefault attribute, if not specified, should default to false (now it's left to null).

       

      The third one (https://github.com/motaboy/federation/commit/4eae2fcf136a1adb71eb7906d8bb2378222acf2b) tries to implement the handling of AssertionConsumerServiceURL, AssertionConsumerServiceIndex and the values provided by the metadata as I can understand from the specs. It also adds two logger functions to return an exception when a valid url  cannot be found and when both AssertionConsumerServiceURL and AssertionConsumerServiceIndex are provided by the AuthnRequest.

       

      This patch adds a getAssertionConsumerServiceEndpoint that will return an endpoint. I'm returning and endpoint instead of the url string because in future also the provided protocolbinding should be considered; while now, from what I understand, the post or redirect method are always used based on other assumptions instead of the one provided by the request or by the metadata (see to TODO I added).

       

      The logic is this:

       

      *) If the request provides the AssertionConsumerServiceURL then create and EndpointType with the location set to it and the optional protocolbinding value provided by the request

      *) If the request provides the AssertionConsumerServiceIndex then search the AssertionConsumerServices from the metadata with that index. If not found just stop and return null

      *) If nothing is provided search the AssertionConsumerService from the metadata that is marked as default. If not found:

      *) Return the first AssertionConsumerService in the metadata (does the optional protocolBinding in the request should be considered?).

       

      Please let me know what do you think about it so I'll open a jira and make a pull request.

       

       

      2) This one is not related to a Picketlink problem, I'm reporting it just for completeness:

       

      after the above fix a Response is sent but lasso fails to validate the message. Lasso, by default, only accepts 3 canonicalizations:

       

      "http://www.w3.org/2001/10/xml-exc-c14n#"

      "http://www.w3.org/2000/09/xmldsig#dsa-sha1"

      "http://www.w3.org/2000/09/xmldsig#enveloped-signature"

       

      while picketlink by default uses CanonicalizationMethod.EXCLUSIVE_WITH_COMMENTS = "http://www.w3.org/2001/10/xml-exc-c14n#WithComments"

       

      So i forced the "http://www.w3.org/2001/10/xml-exc-c14n#" method:

       

       

      {noformat}

      <PicketLinkIDP xmlns="urn:picketlink:identity-federation:config:1.0" SupportsSignatures="true" CanonicalizationMethod="http://www.w3.org/2001/10/xml-exc-c14n#">

      {noformat}

       

      and the signing worked.

       

      Another solution is to modify lasso to also accept the picketlink's default CanonicalizationMethod.