3:27 p.m.
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