Are you setting both valve and filter ? You only need one or another ...
Btw, I've reviewed the SPFilter. I think I've a new version for this component
that should behave just like the valve. I can send you some jars so you can try it out.
Also, let's move this discussion to [1], ok ?
https://issues.jboss.org/browse/PLINK2-120
Regards.
----- Original Message -----
From: "Manohara Raju" <mraju(a)temenos.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: "Claudio Miranda" <claudio(a)claudius.com.br>,
security-dev(a)lists.jboss.org, "Vinod Raghavan" <vraghavan(a)temenos.com>
Sent: Sunday, October 26, 2014 2:44:39 AM
Subject: RE: SPFilter should check principal in POST calls
Hi Pedro,
Its also set in jboss-web.xml also as below:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<!--
<security-domain>java:/jaas/T24</security-domain>
-->
<security-domain>tsp</security-domain>
<valve>
<class-name>org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderAuthenticator</class-name>
</valve>
Thanks,
Manoharr
-----Original Message-----
From: Manohara Raju
Sent: Sunday, October 26, 2014 9:43 AM
To: 'Pedro Igor Silva'
Cc: Claudio Miranda; security-dev(a)lists.jboss.org; Vinod Raghavan
Subject: RE: SPFilter should check principal in POST calls
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@redhat.com]
Sent: Friday, October 24, 2014 6:10 PM
To: Manohara Raju
Cc: Claudio Miranda; security-dev(a)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(a)temenos.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>, "Claudio Miranda"
<claudio(a)claudius.com.br>
Cc: security-dev(a)lists.jboss.org, "Vinod Raghavan"
<vraghavan(a)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(a)lists.jboss.org [mailto:security-dev-bounces@lists.jboss.org]
On Behalf Of Pedro Igor Silva
Sent: Friday, October 24, 2014 12:49 AM
To: Claudio Miranda
Cc: security-dev(a)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(a)claudius.com.br>
To: security-dev(a)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(a)claudius.com.br
http://www.claudius.com.br
_______________________________________________
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
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.
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.