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(a)redhat.com>
To: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>,
security-dev(a)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/s...
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/1b4f88c6f86fcc4a313618c27...
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(a)redhat.com>
>> To: security-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev