[security-dev] SAML SSO with signatures error

[Pedro Igor Silva]

You'r right Eric. Both SP and IdP filters need some love. We've discussed about that before Final and the idea is work on that for the next releases.

Regarding the property, it is a system property.

----- Original Message -----
From: "Eric Wittmann" <eric.wittmann at redhat.com>
To: "Anil Saldhana" <Anil.Saldhana at redhat.com>, security-dev at lists.jboss.org
Sent: Wednesday, June 25, 2014 10:27:53 AM
Subject: Re: [security-dev] SAML SSO with signatures error

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
>
_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev