Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?

From: "Adam Dong" <adamdong(a)vidder.com&gt; To: security-dev(a)lists.jboss.org Sent: Wednesday, September 17, 2014 9:59:11 PM Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ? Just to follow up on this: I worked around this problem by using wild card as role name in <auth-constraint> for my app: <auth-constraint> <role-name>*</role-name> </auth-constraint>

Separately, there is a potential bug: in the quick start examples having a key store, the key pair in the store expired already: Valid from: Thu Jan 15 08:54:42 PST 2009 until: Wed Apr 15 09:54:42 PDT 2009 But xml signing and validation for assertion are still successful during SP and IDP exchanging SAML requests/responses. Should I file a bug ?

By the way, I filed another bug (with the possible solution code) about two weeks ago: PLINK-567: SAML2AttributeHandler couldn't handle multiple attribute elements with the same attribute name Which release would have the fix ?

Thanks, Adam Dong -----Original Message----- From: Adam Dong Sent: Monday, September 08, 2014 12:16 PM To: 'Michael Cirioli' Cc: security-dev(a)lists.jboss.org; Pedro Igor Silva Subject: RE: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ? Thanks a lot Mike. That is exactly what I'm missing. Now the valve is working. The next problem is how to configure/pull in my own Role Validator whose useInRole() method just returns true, as opposed to using DefaultRoleValidator. With SPFilter, I could just add an init-parameter to pull in my own role validator : <filter> <filter-name>SPFilter</filter-name> <filter-class>org.picketlink.identity.federation.web.filters.SPFilter</filter-class> <init-param> <param-name>ROLE_VALIDATOR</param-name> <param-value>MyRoleValidator</param-value> </init-param> But with ServiceProviderAuthenticator (as a valve), I didn't find a way to do this. Any idea ? Thanks, Adam -----Original Message----- From: Michael Cirioli [mailto:mcirioli@redhat.com] Sent: Saturday, September 06, 2014 8:05 AM To: Adam Dong Cc: security-dev(a)lists.jboss.org; Pedro Igor Silva Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ? Adam , One thing you might check is if your security domain is properly configured and you have the correct security constraints applied in web.xml for.your index.jsp.  if you have questions let me know and I can dig up some examples for you. -mike cirioli On Sep 5, 2014 2:18 AM, Adam Dong <adamdong(a)vidder.com&gt; wrote: > > Pedro, > > I finally had time to try that jar file on Tomcat 7 (no Jboss), now > therePedro, I finally had time to try that jar file on Tomcat 7 (no Jboss), now there is no more complaint during loading of my simple one-page (index.jsp) web app with the following META-INF/context.xml: <Context> <Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.Servi ceProviderAuthenticator"/> <Context> However, when I try to access my index page, there is no SAML traffic, the index page just showed up. I further tried to sub-class ServiceProviderAuthenticator with a default constructor to print out a line to show that it is instantiated. I used that class as the valve. The log did prove that the valve is instantiated during loading time. But an access to the web app (well, just the index page) didn't cause any SAML interaction at all. So what am I missing ? Did I misunderstand how ServiceProviderAuthenticator is supposed to be used ? Thanks, Adam PS: I examined the source code for ServiceProviderAuthenticator, its parent AbstractSPFormAuthenticator, and its grandparent BaseFormAuthenticator, I was expecting to see the implemention of invoke(request, response) method with similar logic as in SPFilter's doFilter(request, response) method. But neither of the 3 classes implement invoke(...) method, why is that ? How does SAML processing come into the picture then ? Another general question, is picket link SAML offering widely used in commercial products ? -----Original Message----- From: Adam Dong Sent: Friday, August 29, 2014 3:00 PM To: 'Pedro Igor Silva' Cc: security-dev(a)lists.jboss.org Subject: RE: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ? Pedro Igor, Thank you so much. I will try it out and report the result back to this email group. Adam Dong -----Original Message----- From: Pedro Igor Silva [mailto:psilva@redhat.com] Sent: Friday, August 29, 2014 5:37 AM To: Adam Dong Cc: security-dev(a)lists.jboss.org Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ? Hi Adam, This is the right GAV: <dependency> <groupId>org.picketlink.distribution</groupId> <artifactId>picketlink-tomcat7</artifactId> <version>${picketlink.version}</version> </dependency> The picketlink-tomact7-single can not be used alone. Try to download from here: https://repository.jboss.org/nexus/content/groups/public/org/picketlin k/distribution/picketlink-tomcat7/2.6.0.Final/picketlink-tomcat7-2.6.0 .Final.jar Regards. Pedro Igor ----- Original Message ----- From: "Adam Dong" <adamdong(a)vidder.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: security-dev(a)lists.jboss.org Sent: Wednesday, August 27, 2014 10:18:32 PM Subject: RE: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ? OK, I found picketlink-tomcat7-single-2.6.0.Final.jar on picketlink.org site, replaced picketlink-jbas7-2.6.0.Final.jar with it. Now I got java.lang.NoClassDefFoundError: org/picketlink/identity/federation/bindings/tomcat/sp/AbstractSPFormAu thenticator And I checked, indeed AbstractSPFormAuthenticator is not in picketlink-tomcat7-single-2.6.0.Final.jar, but in picketlink-jbas7-2.6.0.Final.jar. Is picketlink-tomcat7-single-2.6.0.Final.jar missing a few files ? Should I grab those missing file from jbas7 jar file and put them into tomcat7 jar file ? Would they be compatible ? To check the compatibility, I found the following. ServiceProviderAuthenticator.class in picketlink-tomcat7-single-2.6.0.Final.jar: 1667 Sun Jun 22 03:04:00 PDT 2014 org/picketlink/identity/federation/bindings/tomcat/sp/ServiceProviderA uthenticator.class The same class in picketlink-jbas7-2.6.0.Final.jar: 978 Sun Jun 22 03:03:56 PDT 2014 org/picketlink/identity/federation/bindings/tomcat/sp/ServiceProviderA uthenticator.class They are different. Is that correct ? Can I trust the AbstractSPFormAuthenticator.class in jbas7 jar file to work with ServiceProviderAuthenticator.class in tomcat7 jar file ? Thanks, Adam Dong -----Original Message----- From: Adam Dong Sent: Wednesday, August 27, 2014 2:29 PM To: 'Pedro Igor Silva' Cc: security-dev(a)lists.jboss.org Subject: RE: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ? Pedro, The following are the jar files I put under <Tomcat_home>/lib (I first put them under my web app's WEB-INF/lib directory but tomcat couldn't find them): bcprov-jdk15on-151.jar jboss-logging-3.1.0.GA.jar jboss-security-spi-4.0.18.final.jar log4j-1.2.16.jar picketlink-common-2.6.0.Final.jar picketlink-config-2.6.0.Final.jar picketlink-federation-2.6.0.Final.jar picketlink-jbas7-2.6.0.Final.jar Where do I get that jar file you mentioned ? All the picketlink related jar files I got are from picketlink-installer-2.6.0.Final.zip, and in there the jar file you mentioned is not present. Thanks, Adam Dong -----Original Message----- From: Pedro Igor Silva [mailto:psilva@redhat.com] Sent: Wednesday, August 27, 2014 1:11 PM To: Adam Dong Cc: security-dev(a)lists.jboss.org Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ? Which jar are u using ? picketlink-tomcat7-X.jar ? ----- Original Message ----- From: "Adam Dong" <adamdong(a)vidder.com&gt; To: security-dev(a)lists.jboss.org Sent: Wednesday, August 27, 2014 3:18:51 PM Subject: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ? Hi, Any previous successful usage of putting ServiceProviderAuthenticator as a Valve in Tomcat, by adding it in a web app’s META-INF/context.xml like below (as opposed to adding it in jboss-web.xml on Jboss) ? <Context> <Valve className="org.picketlink.identity.federation.bindings.tomcat.sp.Servi ceProviderAuthenticator"/> </Context> I tried with Tomcat 7 and get some complaints (see below) about ServiceProviderAuthenticator overriding final method start()but the valve seemed being pulled in. java.lang.VerifyError: class org.picketlink.identity.federation.bindings.tomcat.sp.ServiceProviderA uthenticator overrides final method start.()V at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142 ) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRul e.java:144) at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:12 88) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElem ent(AbstractSAXParser.java:509) at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.e mptyElement(AbstractXMLDocumentParser.java:182) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl .scanStartElement(XMLDocumentFragmentScannerImpl.java:1342) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl $FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2770) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XM LDocumentScannerImpl.java:606) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl .scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XM L11Configuration.java:848) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XM L11Configuration.java:777) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.j ava:141) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Abs tractSAXParser.java:1213) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.pa rse(SAXParserImpl.java:648) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) at org.apache.catalina.startup.ContextConfig.processContextConfig(Context Config.java:637) at org.apache.catalina.startup.ContextConfig.contextConfig(ContextConfig. java:599) at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:837) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig .java:385) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycle Support.java:117) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBas e.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase. java:402) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase. java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877 ) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java :1247) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig. java:1898) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471 ) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j ava:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. java:615) at java.lang.Thread.run(Thread.java:745) I tried with Tomcat 6 and the valve didn’t get pulled in the request path, just as if it were not there. Any experience or idea ? Thanks, Adam Dong _______________________________________________ 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 _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev