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