[jira] [Created] (FEDIZ-19) Single Sign Out
Romain Manni-Bucau created FEDIZ-19: --- Summary: Single Sign Out Key: FEDIZ-19 URL: https://issues.apache.org/jira/browse/FEDIZ-19 Project: CXF-Fediz Issue Type: New Feature Reporter: Romain Manni-Bucau The goal is to invalidate all sessions of "related" webapps with a single action (button). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FEDIZ-19) Single Sign Out
[ https://issues.apache.org/jira/browse/FEDIZ-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13427932#comment-13427932 ] Romain Manni-Bucau commented on FEDIZ-19: - side note about it: it is important to be able to sign out behind a load balancer > Single Sign Out > --- > > Key: FEDIZ-19 > URL: https://issues.apache.org/jira/browse/FEDIZ-19 > Project: CXF-Fediz > Issue Type: New Feature >Reporter: Romain Manni-Bucau > > The goal is to invalidate all sessions of "related" webapps with a single > action (button). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4453) Make the CryptoCoverageChecker easier to use for common signature verification and decryption use-cases
[ https://issues.apache.org/jira/browse/CXF-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-4453: - Description: The CryptoCoverageChecker is designed to be used in conjunction with the WSS4JInInterceptor for the non-WS-SecurityPolicy case, to check that elements you expected to be signed or encrypted actually were. However, for some common use-cases based around signature verification or decryption it is slightly complex to set up, as it involves adding XPath expressions, as well as the corresponding prefix/namespace pairs. This task is to extend the CryptoCoverageChecker to make it easier to use for some common use-cases. A new subclass called "DefaultCryptoCoverageChecker" will be introduced, which will provide an easy way to make sure that the SOAP Body is signed or encrypted, and that the Timestamp is signed. was: The CryptoCoverageChecker is designed to be used in conjunction with the WSS4JInInterceptor for the non-WS-SecurityPolicy case, to check that elements you expected to be signed or encrypted actually were. However, for some common use-cases based around signature verification it is slightly complex to set up, as it involves adding XPath expressions, as well as the corresponding prefix/namespace pairs. This task is to extend the CryptoCoverageChecker to make it easier to use for some common use-cases. Summary: Make the CryptoCoverageChecker easier to use for common signature verification and decryption use-cases (was: Make the CryptoCoverageChecker easier to use for common signature verification use-cases) > Make the CryptoCoverageChecker easier to use for common signature > verification and decryption use-cases > --- > > Key: CXF-4453 > URL: https://issues.apache.org/jira/browse/CXF-4453 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.4.8, 2.5.4, 2.6.1 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.4.9, 2.5.5, 2.6.2 > > > The CryptoCoverageChecker is designed to be used in conjunction with the > WSS4JInInterceptor for the non-WS-SecurityPolicy case, to check that elements > you expected to be signed or encrypted actually were. However, for some > common use-cases based around signature verification or decryption it is > slightly complex to set up, as it involves adding XPath expressions, as well > as the corresponding prefix/namespace pairs. This task is to extend the > CryptoCoverageChecker to make it easier to use for some common use-cases. > A new subclass called "DefaultCryptoCoverageChecker" will be introduced, > which will provide an easy way to make sure that the SOAP Body is signed or > encrypted, and that the Timestamp is signed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4454) JSSE KeyManagers and TrustManager XML configurations are ignored if they contain no keystore element.
Sven Staible created CXF-4454: - Summary: JSSE KeyManagers and TrustManager XML configurations are ignored if they contain no keystore element. Key: CXF-4454 URL: https://issues.apache.org/jira/browse/CXF-4454 Project: CXF Issue Type: Bug Components: Configuration Affects Versions: 2.6.1 Environment: all Reporter: Sven Staible Priority: Minor The XSD for JSSE KeyManagers and TrustManagers allows them to not include a keystore (or certstore) element (which is correct). However the configured key and trust manager configurations are ignored and not applied if they contain no keystore configuration element (see TLSParameterJaxBUtils.java:239 and TLSParameterJaxBUtils.java:275). For a Trust- or KeyManager to not require a keystore configuration is a valid scenario. I'm currently using a JCE provider that does not require a keystore. With the current implementation I can not use this provider with the XML configuration feature. If I set the key and trust managers of this provider manually in the TLSClientParametersConfig using java code it works as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4453) Make the CryptoCoverageChecker easier to use for common signature verification and decryption use-cases
[ https://issues.apache.org/jira/browse/CXF-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-4453: - Description: The CryptoCoverageChecker is designed to be used in conjunction with the WSS4JInInterceptor for the non-WS-SecurityPolicy case, to check that elements you expected to be signed or encrypted actually were. However, for some common use-cases based around signature verification or decryption it is slightly complex to set up, as it involves adding XPath expressions, as well as the corresponding prefix/namespace pairs. This task is to extend the CryptoCoverageChecker to make it easier to use for some common use-cases. A new subclass called "DefaultCryptoCoverageChecker" will be introduced, which will provide an easy way to make sure that the SOAP Body is signed or encrypted, that the Timestamp is signed, and that the WS-Addressing ReplyTo and FaultTo headers are signed (if they are present in the message payload). was: The CryptoCoverageChecker is designed to be used in conjunction with the WSS4JInInterceptor for the non-WS-SecurityPolicy case, to check that elements you expected to be signed or encrypted actually were. However, for some common use-cases based around signature verification or decryption it is slightly complex to set up, as it involves adding XPath expressions, as well as the corresponding prefix/namespace pairs. This task is to extend the CryptoCoverageChecker to make it easier to use for some common use-cases. A new subclass called "DefaultCryptoCoverageChecker" will be introduced, which will provide an easy way to make sure that the SOAP Body is signed or encrypted, and that the Timestamp is signed. > Make the CryptoCoverageChecker easier to use for common signature > verification and decryption use-cases > --- > > Key: CXF-4453 > URL: https://issues.apache.org/jira/browse/CXF-4453 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.4.8, 2.5.4, 2.6.1 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.4.9, 2.5.5, 2.6.2 > > > The CryptoCoverageChecker is designed to be used in conjunction with the > WSS4JInInterceptor for the non-WS-SecurityPolicy case, to check that elements > you expected to be signed or encrypted actually were. However, for some > common use-cases based around signature verification or decryption it is > slightly complex to set up, as it involves adding XPath expressions, as well > as the corresponding prefix/namespace pairs. This task is to extend the > CryptoCoverageChecker to make it easier to use for some common use-cases. > A new subclass called "DefaultCryptoCoverageChecker" will be introduced, > which will provide an easy way to make sure that the SOAP Body is signed or > encrypted, that the Timestamp is signed, and that the WS-Addressing ReplyTo > and FaultTo headers are signed (if they are present in the message payload). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4453) Make the CryptoCoverageChecker easier to use for common signature verification and decryption use-cases
[ https://issues.apache.org/jira/browse/CXF-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-4453. -- Resolution: Fixed > Make the CryptoCoverageChecker easier to use for common signature > verification and decryption use-cases > --- > > Key: CXF-4453 > URL: https://issues.apache.org/jira/browse/CXF-4453 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.4.8, 2.5.4, 2.6.1 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.4.9, 2.5.5, 2.6.2 > > > The CryptoCoverageChecker is designed to be used in conjunction with the > WSS4JInInterceptor for the non-WS-SecurityPolicy case, to check that elements > you expected to be signed or encrypted actually were. However, for some > common use-cases based around signature verification or decryption it is > slightly complex to set up, as it involves adding XPath expressions, as well > as the corresponding prefix/namespace pairs. This task is to extend the > CryptoCoverageChecker to make it easier to use for some common use-cases. > A new subclass called "DefaultCryptoCoverageChecker" will be introduced, > which will provide an easy way to make sure that the SOAP Body is signed or > encrypted, that the Timestamp is signed, and that the WS-Addressing ReplyTo > and FaultTo headers are signed (if they are present in the message payload). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4372) Using geronimo jaxws API directly
[ https://issues.apache.org/jira/browse/CXF-4372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-4372. -- Resolution: Won't Fix Fix Version/s: (was: 2.6.2) (was: 2.5.5) Invalid As Willem stated, the current usage has been well discussed and works best for our needs. > Using geronimo jaxws API directly > - > > Key: CXF-4372 > URL: https://issues.apache.org/jira/browse/CXF-4372 > Project: CXF > Issue Type: Task > Components: OSGi >Reporter: Willem Jiang >Assignee: Willem Jiang >Priority: Minor > Fix For: Invalid > > > geronimo JAXWS spec API bundle already has the locator which works as > servicemix specs locator, we should use it instead of servicemix wrap one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4397) Cached Reader/Writer in org.apache.cxf.io
[ https://issues.apache.org/jira/browse/CXF-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-4397: - Fix Version/s: (was: 2.6.2) > Cached Reader/Writer in org.apache.cxf.io > - > > Key: CXF-4397 > URL: https://issues.apache.org/jira/browse/CXF-4397 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 2.6.1 >Reporter: Dr. Dietmar Wolz > > In version 2.6 support of Readers/Writers attached to the message > representing the content were added. Implementation of SAM for Talend ESB > needed to be adapted in case JMS is used as transport. The current fix > converts attached Readers/Writers to streams in SAM using UTF-8 encoding. It > works but I am not sure this is consistent with what was indended by > supporting Readers/Writers in CXF. To defer encoding also in case monitoring > is enabled I would prefer to use cached Readers/Writers instead converting > into streams thereby fixing the encoding. Proper place for cached > Reader/Writer would be org.apache.cxf.io, where the already existing cached > streams are located. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4436) EncryptionProperties.keyWrapAlgorithm is not used when issuing a Symmetric HOK SAML Assertion
[ https://issues.apache.org/jira/browse/CXF-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-4436. -- Resolution: Fixed > EncryptionProperties.keyWrapAlgorithm is not used when issuing a Symmetric > HOK SAML Assertion > - > > Key: CXF-4436 > URL: https://issues.apache.org/jira/browse/CXF-4436 > Project: CXF > Issue Type: Bug > Components: Services >Affects Versions: 2.5.4, 2.6.1 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.5.5, 2.6.2 > > > EncryptionProperties.keyWrapAlgorithm is not used when issuing a Symmetric > HOK SAML Assertion. RSA 1.5 is always used as it is the default algorithm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4411) Maven plugin fails wsdl2java execution with concurrent modification exception
[ https://issues.apache.org/jira/browse/CXF-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-4411: - Fix Version/s: (was: 2.7.0) (was: 2.6.2) (was: 2.5.5) (was: 2.4.9) > Maven plugin fails wsdl2java execution with concurrent modification exception > - > > Key: CXF-4411 > URL: https://issues.apache.org/jira/browse/CXF-4411 > Project: CXF > Issue Type: Bug >Affects Versions: 2.6.1 > Environment: Linux, IBM JVM 1.6, Builder is Atlassian Bamboo 2.7.6, > Maven 3.0.4 >Reporter: Jeroen Benckhuijsen >Assignee: Freeman Fang > > We're getting a concurrent modification exception while running a parallel > build (-T C5) using Maven 3. Reproducability is low, so it seems to be some > race condition. Stack trace: > build 06-Jul-2012 16:42:33 > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.cxf:cxf-codegen-plugin:2.6.1:wsdl2java > (generate-sources-task-callback) on project gps-wps-process-client-takp: > java.util.ConcurrentModificationException > build 06-Jul-2012 16:42:33at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > build 06-Jul-2012 16:42:33at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > build 06-Jul-2012 16:42:33at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > build 06-Jul-2012 16:42:33at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > build 06-Jul-2012 16:42:33at > org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) > build 06-Jul-2012 16:42:33at > org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163) > build 06-Jul-2012 16:42:33at > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:315) > build 06-Jul-2012 16:42:33at > java.util.concurrent.FutureTask.run(FutureTask.java:150) > build 06-Jul-2012 16:42:33at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:453) > build 06-Jul-2012 16:42:33at > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:315) > build 06-Jul-2012 16:42:33at > java.util.concurrent.FutureTask.run(FutureTask.java:150) > build 06-Jul-2012 16:42:33at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:898) > build 06-Jul-2012 16:42:33at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:920) > build 06-Jul-2012 16:42:33at java.lang.Thread.run(Thread.java:736) > build 06-Jul-2012 16:42:33Caused by: > org.apache.maven.plugin.MojoExecutionException: > java.util.ConcurrentModificationException > build 06-Jul-2012 16:42:33at > org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.generate(WSDL2JavaMojo.java:234) > build 06-Jul-2012 16:42:33at > org.apache.cxf.maven_plugin.AbstractCodegenMoho.execute(AbstractCodegenMoho.java:250) > build 06-Jul-2012 16:42:33at > org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:308) > build 06-Jul-2012 16:42:33at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > build 06-Jul-2012 16:42:33at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > build 06-Jul-2012 16:42:33... 13 more > build 06-Jul-2012 16:42:33Caused by: > org.apache.cxf.tools.common.ToolException: > java.util.ConcurrentModificationException > build 06-Jul-2012 16:42:33at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:294) > build 06-Jul-2012 16:42:33at > org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103) > build 06-Jul-2012 16:42:33at > org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113) > build 06-Jul-2012 16:42:33at > org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86) > build 06-Jul-2012 16:42:33at > org.apache.cxf.maven_plugin.wsdl2java.WSDL2JavaMojo.generate(WSDL2JavaMojo.java:231) > build 06-Jul-2012 16:42:33... 17 more > build 06-Jul-2012 16:42:33Caused by: > java.util.ConcurrentModificationException > build 06-Jul-2012 16:42:33at > java.util.LinkedHashMap$AbstractMapIterator.checkConcurrentMod(LinkedHashMap.java:136) > build 06-Jul-2012 16:42:33at > java.util.LinkedHashMap$AbstractMapIterat
