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

    Picketlink IdP and mod_mellon SP integration

    Simone Gotti Newbie



      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:






      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:




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



      and the signing worked.


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