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.