[security-dev] SAML SSO with signatures error

[Eric Wittmann]

Well, we are trying to support a variety of containers:

   EAP,Tomcat,Jetty,Fuse

I switched to the SPFilter in an attempt to make the configuration of 
our various container-specific WARs as similar as possible.

In any case - I have some updated information on this issue.  First of 
all, I got it working in EAP by reverting back to the sp valve instead 
of the sp filter.

The SPFilter is failing here:

https://github.com/picketlink/picketlink/blob/master/modules/federation/src/main/java/org/picketlink/identity/federation/web/filters/SPFilter.java#L594

It seems that you are right, Anil, and this code simply hasn't been 
tested/updated in awhile.  The problem is the "IDness" of the ID 
attribute (whatever that means).  :)  This was fixed in the 
SAML2SignatureValidationHandler with this commit:

https://github.com/picketlink/picketlink/commit/1b4f88c6f86fcc4a313618c270ce6737980e19d1

So I think the SPFilter would need to use a SAML2Signature to validate 
the signature rather than calling XMLSignatureUtil.validate directly. 
That said, I don't really understand why SPFilter is validating the 
signature at all, since there is a handler to do that.  Perhaps that's 
just an artifact of an old impl.

Bottom line I think is that SPFilter may need some love.  For us, I need 
something that will work in non-EAP containers like jetty and fuse.  So 
I need to use the SPFilter I think.  Which means I may need to make a 
local copy of it and fix the signature problem.

Finally (on an unrelated note) the picketlink.xml file allows the URLs 
to be configured via property interpolation (with a default) like so:

<IdentityURL>${overlord-idp.url::http://localhost:8080/overlord-idp/}</IdentityURL>

Is "overlord-idp.url" assumed to be a system property?  Or is there some 
other place where that property should be defined?

-Eric

On 6/24/2014 5:59 PM, Anil Saldhana wrote:
> Eric,
>     if you are on EAP/WildFly, it is better to use the deeper bindings on
> the SP side such
> as the valves or the authentication mechanisms.
>
> I don't think we have spent a lot of time on keeping the SPFilter
> updated and tested well.
> Pedro and I have been planning to take a look at it for sometime now. :(
>
> Regards,
> Anil
>
> On 06/24/2014 04:57 PM, Eric Wittmann wrote:
>> We never enabled signatures when we were using the SP valve.  If it's
>> useful I could try switching from the SPFilter to the SP valve and
>> giving that a try...
>>
>> -Eric
>>
>> On 6/24/2014 4:41 PM, Pedro Igor Silva wrote:
>>> Did you have the same behavior when using the SP Valve ?
>>>
>>> ----- Original Message -----
>>> From: "Eric Wittmann" <eric.wittmann at redhat.com>
>>> To: security-dev at lists.jboss.org
>>> Sent: Tuesday, June 24, 2014 3:52:25 PM
>>> Subject: [security-dev] SAML SSO with signatures error
>>>
>>> Hi guys.
>>>
>>> I'm using the EAP IDP Valve with the SPFilter servlet filter running on
>>> EAP 6.3.0 to implement web SSO.  It works fine without signatures, but
>>> now I'm trying to enable signatures on the IDP (meaning I want the IDP
>>> to sign the saml response and I want the SPFilter to verify the sig).
>>> I'm using picketlink 2.5.3.SP1 packaged into the SP WAR.  I'm using
>>> whatever picketlink version comes with EAP 6.3 (2.5.3.SP5 I think).
>>>
>>> I currently have two problems.  The first is that the SPFilter does this
>>> in the verifySignature() method:
>>>
>>>             URL issuerURL;
>>>             try {
>>>                 issuerURL = new URL(issuerID);
>>>             } catch (MalformedURLException e1) {
>>>                 throw new IssuerNotTrustedException(e1);
>>>             }
>>>
>>> This code fails for me because the issuerID in the saml response is
>>> "/overlord-idp/".  I haven't dug into this yet, but I imagine I need to
>>> tweak something on the IDP to get it to put in a full issuer into the
>>> saml response.
>>>
>>> I can get past that with the debugger (by modifying the issuerID value)
>>> but when I do I hit the following stack trace:
>>>
>>> https://gist.github.com/EricWittmann/f05b65689367ba321fc8
>>>
>>> The Signature in the saml response seems ok when I eyeball it.  That
>>> stack trace is pretty opaque to me - does anyone have any insight into it?
>>>
>>> -Eric
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>