[security-dev] SPFilter should check principal in POST calls

Sun Oct 26 00:12:30 EDT 2014

Hi Pedro,

I have already used SP Authenticator valve at context.xml, still issue persists.

<?xml version="1.0" encoding="UTF-8"?>
<!--
    Context configuration file for the JBOSS Manager Web App
-->
<Context reloadable="true">
        <Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator" />
</Context>

Regards,
Manoharr

-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com]
Sent: Friday, October 24, 2014 6:10 PM
To: Manohara Raju
Cc: Claudio Miranda; security-dev at lists.jboss.org; Vinod Raghavan
Subject: Re: SPFilter should check principal in POST calls

Hey Manohara,

   Is it possible to use the SP Authenticator Valve in your case ? As I've already mentioned in this thread, the SPFilter is not the best component to configure a SP.

   I think we already have use cases using ADFS and PL. But they are probably using the valve instead of the filter.

Regards.

----- Original Message -----
From: "Manohara Raju" <mraju at temenos.com>
To: "Pedro Igor Silva" <psilva at redhat.com>, "Claudio Miranda" <claudio at claudius.com.br>
Cc: security-dev at lists.jboss.org, "Vinod Raghavan" <vraghavan at temenos.com>
Sent: Friday, October 24, 2014 9:46:26 AM
Subject: RE: SPFilter should check principal in POST calls

Hi,

Thanks for the response.

We are using Picketlink as SP(service provider) and ADFS server as IDP. I tried adding the SP filter in web.xml of our java application, but not successful. Still issue persists.

Please can you let me know, is it possible to have a call, so that can discuss and clarify on the configuration settings and about SP.

Thanks a lot for the support.

Regards,
Manoharr.

-----Original Message-----
From: security-dev-bounces at lists.jboss.org [mailto:security-dev-bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Friday, October 24, 2014 12:49 AM
To: Claudio Miranda
Cc: security-dev at lists.jboss.org
Subject: Re: [security-dev] SPFilter should check principal in POST calls

Hey Claudio,

    Makes sense for me. Specially if we maintain backward compatibility.

    However, the SPFilter is pretty outdated if you compare with both JBossWeb/Tomcat valves and Undertow mech. Maybe you can reach a blocker in the future ...

    Please, send your contribution if you like to. Contribution is always welcome :)

Regards.

----- Original Message -----
From: "Claudio Miranda" <claudio at claudius.com.br>
To: security-dev at lists.jboss.org
Sent: Thursday, October 23, 2014 4:50:06 PM
Subject: [security-dev] SPFilter should check principal in POST calls

Hi, related to PLINK2-20, our application cannot use SP valve, as there are two authentication mechanism (DatabaseServerLoginModule and SAML2LoginModule). So we use SPFilter and it the alternative authentication mechanism is working, except for the jsf requests, SPFilter intercepts it as POST requests and redirects to IDP, but the user is already authenticated.

So, there is the following issue.

https://issues.jboss.org/browse/PLINK2-20

Would you allow a contribution to add a servlet filter init param to optionally add the allowed request methods ?

<init-param>
    <param-name>ALLOWED_METHODS</param-name>
    <param-value>GET,POST</param-value>
</init-param>

And change the below code to allow it ?

        boolean postMethod = "POST".equalsIgnoreCase(request.getMethod());

Defaults to POST to maintain compatibility.

Comments ?

Kind regards
--
  Claudio Miranda

claudio at claudius.com.br
http://www.claudius.com.br
_______________________________________________
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

The information in this e-mail and any attachments is confidential and may be legally privileged. It is intended solely for the addressee or addressees. Any use or disclosure of the contents of this e-mail/attachments by a not intended recipient is unauthorized and may be unlawful. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of TEMENOS. We recommend that you check this e-mail and any attachments against viruses. TEMENOS accepts no liability for any damage caused by any malicious code or virus transmitted by this e-mail.