[security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?
Adam Dong
adamdong at vidder.com
Thu Sep 18 14:35:29 EDT 2014
See comments (preceded by [AD]) embedded below.
-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com]
Sent: Wednesday, September 17, 2014 8:52 PM
To: Adam Dong
Cc: security-dev at lists.jboss.org
Subject: Re: [security-dev] Use ServiceProviderAuthenticator in Tomcat directly instead of in Jboss ?
----- Original Message -----
> From: "Adam Dong" <adamdong at vidder.com>
> To: security-dev at 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>
Yeah, like Michael said. That was the missing part in your config.
>
> 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 ?
Even though it does not impact the quickstarts, better is update them. You can open a JIRA if you want.
[AD]: I am not only talking about updating the certificate, but also talking about the signature validation code checking the cert expiration time before using it.
>
> 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 ?
Beta2 was the best version to put this issue. We had a few SAML issues fixes in this release.
But we can do that in CR1. If you have a patch, please attach it to the JIRA.
[AD]: I just put the code in the Jira ticket, didn't have time to learn how to submit a patch.
>
> Thanks,
> Adam Dong
>
> -----Original Message-----
> From: Adam Dong
> Sent: Monday, September 08, 2014 12:16 PM
> To: 'Michael Cirioli'
> Cc: security-dev at 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 at redhat.com]
> Sent: Saturday, September 06, 2014 8:05 AM
> To: Adam Dong
> Cc: security-dev at 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 at vidder.com> 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 at 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 at redhat.com]
> Sent: Friday, August 29, 2014 5:37 AM
> To: Adam Dong
> Cc: security-dev at 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 at vidder.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: security-dev at 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 at 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 at redhat.com]
> Sent: Wednesday, August 27, 2014 1:11 PM
> To: Adam Dong
> Cc: security-dev at 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 at vidder.com>
> To: security-dev at 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 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
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
More information about the security-dev
mailing list