[jira] [Created] (CXF-3520) CXF support for cross domain SSO based on SAML token
CXF support for cross domain SSO based on SAML token Key: CXF-3520 URL: https://issues.apache.org/jira/browse/CXF-3520 Project: CXF Issue Type: Improvement Components: WS-* Components Affects Versions: 2.4 Reporter: Oliver Wulff Use case: There is a service consumer and a service provider using SOAP/HTTPS. Both understand SAML tokens. An identity known in the security domain of the service consumer is not known to the domain of the service provider. This use case can be addressed by the following proposal. The IssuedToken assertion in the WS-SecurityPolicy document of the service provider defines the Issuer he trusts which is the so called Relying Party (RP) STS. The service consumer configures the STSClient bean where you define the URL of the STS which is the so called Identity Provider (IP) STS. If service consumer and service provider are in the same security domain (principal/id understood by service consumer and provider) the URLs/EPR are equal. If they are not I'd say we have the use case I described above. CXF 2.4 ignores the Issuer element in the IssuedToken assertion. wsa:EndpointReferenceType ... If they are different, the CXF service consumer must first go to the STS configured in the STSClient and gets a SAML token. Then the service consumer sends the previously issued token (in WS-Security header) to the Relying Party STS and let's issue a new token based on the data in the RequestSecurityTokenTemplate element of the policy. There must be a trust established between the IP STS and the RP STS. (This is *not* a case for OnBehalfOf support as described in WS-Trust spec) As far as I understand the WS-Federation spec this is the idea of the active requestor profile. It's then up to the Relying Party STS do implements claims transformation (like principal mapping, role mapping and other claims) Link to topic in mailing list: http://cxf.547215.n5.nabble.com/SAML-support-across-security-domains-SSO-td4372429.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Issues with Attachments: week of 2011-05-16
CXF - Monday, May 16, 2011 10 Issues with Attachments (sorted oldest to newest) [CXF-3219] WS-RMs' DestinationSequence does not update the ack range in the RMStore - Created: 2010-12-25 - Updated: 2011-04-29 - Type: Bug - Fix Versions: [] - Reporter: Aki Yoshida - Assigned: Aki Yoshida - Attachments: [rt-ws-rm-2.3.x-fixes-diff.txt] - https://issues.apache.org/jira/browse/CXF-3219 [CXF-3450] Unable to build service from class with JAXB bindings - Created: 2011-04-11 - Updated: 2011-05-05 - Type: Bug - Fix Versions: [] - Reporter: Dan Powell - Assigned: Unassigned - Attachments: [jaxb-bindings-test.tar.gz] - https://issues.apache.org/jira/browse/CXF-3450 [CXF-3454] CXFRS doesn't work when there are multiple optional parameters in a @Path annotation - Created: 2011-04-12 - Updated: 2011-04-18 - Type: Bug - Fix Versions: [] - Reporter: Guillermo Castro - Assigned: Unassigned - Attachments: [URITemplateTest.java] - https://issues.apache.org/jira/browse/CXF-3454 [CXF-3483] JSONProvider: Don't force attributes to have @ if users doesn't want them too - Created: 2011-05-03 - Updated: 2011-05-12 - Type: Improvement - Fix Versions: [] - Reporter: Pat Turner - Assigned: Unassigned - Attachments: [cxf-attribs-0.0.1-SNAPSHOT-src.tar.gz] - https://issues.apache.org/jira/browse/CXF-3483 [CXF-3500] Make more packages optional in the CXF JAX-RS OSGI bundle to reduce runtime dependencies - Created: 2011-05-07 - Updated: 2011-05-07 - Type: Improvement - Fix Versions: [2.4.1, 2.3.5] - Reporter: Ka-Lok Fung - Assigned: Unassigned - Attachments: [cxf-jaxrs-bundle-pom-23.diff, cxf-jaxrs-bundle-pom-24.diff] - https://issues.apache.org/jira/browse/CXF-3500 [CXF-3504] for big attachment, a temporary file is left on disk and keep opend, if the application just close the DataSource's inputStream and doesn't consume it; - Created: 2011-05-10 - Updated: 2011-05-10 - Type: Bug - Fix Versions: [] - Reporter: ext2 - Assigned: Unassigned - Attachments: [attachment-clean.zip, mtom.wsdl] - https://issues.apache.org/jira/browse/CXF-3504 [CXF-3505] CXF attachment doesn't compatible with SUN's ACTIVATION library - Created: 2011-05-10 - Updated: 2011-05-13 - Type: Bug - Fix Versions: [] - Reporter: ext2 - Assigned: Freeman Fang - Attachments: [attachment-clean.zip] - https://issues.apache.org/jira/browse/CXF-3505 [CXF-3510] wrong destination determination by OSGi based CXF entry point (regarding its fallback logic) - Created: 2011-05-11 - Updated: 2011-05-13 - Type: Bug - Fix Versions: [2.4.1, 2.3.5] - Reporter: Aki Yoshida - Assigned: Aki Yoshida - Attachments: [2.3.x-fixes-20110512.diff.txt, trunk-20110512.diff.txt] - https://issues.apache.org/jira/browse/CXF-3510 [CXF-3514] Interaction of JAXWS Handler and WSS4JInInterceptor breaks SOAP Message - Created: 2011-05-13 - Updated: 2011-05-13 - Type: Bug - Fix Versions: [] - Reporter: Dirk Rudolph - Assigned: Unassigned - Attachments: [SOAPRequestHandler.java, UTPasswordCallback.java, beans.xml, pom.xml] - https://issues.apache.org/jira/browse/CXF-3514 [CXF-3518] WebClient doesn't handle responses containing a quoted-string in a header correctly - Created: 2011-05-15 - Updated: 2011-05-15 - Type: Bug - Fix Versions: [2.4.1, 2.3.5] - Reporter: Ka-Lok Fung - Assigned: Unassigned - Attachments: [trunk.wc_quote_minimal.diff] - https://issues.apache.org/jira/browse/CXF-3518
[jira] [Updated] (CXF-3520) CXF support for cross domain SSO based on SAML token
[ https://issues.apache.org/jira/browse/CXF-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff updated CXF-3520: -- Description: Use case: There is a service consumer and a service provider using SOAP/HTTPS. Both understand SAML tokens. An identity known in the security domain of the service consumer is not known to the domain of the service provider. This use case can be addressed by the following proposal. The IssuedToken assertion in the WS-SecurityPolicy document of the service provider defines the Issuer he trusts which is the so called Relying Party (RP) STS. The service consumer configures the STSClient bean where you define the URL of the STS which is the so called Identity Provider (IP) STS. If service consumer and service provider are in the same security domain (principal/id understood by service consumer and provider) the URLs/EPR are equal. If they are not I'd say we have the use case I described above. CXF 2.4 ignores the Issuer element in the IssuedToken assertion. wsa:EndpointReferenceType ... If they are different, the CXF service consumer must first go to the STS configured in the STSClient and gets a SAML token. Then the service consumer sends the previously issued token (in WS-Security header) to the Relying Party STS and let's issue a new token based on the data in the RequestSecurityTokenTemplate element of the policy. There must be a trust established between the IP STS and the RP STS. (This is *not* a case for OnBehalfOf support as described in WS-Trust spec) As far as I understand the WS-Federation spec this is the idea of the active requestor profile. It's then up to the Relying Party STS do implements claims transformation (like principal mapping, role mapping and other claims) Link to thread in mailing list: http://cxf.547215.n5.nabble.com/SAML-support-across-security-domains-SSO-td4372429.html was: Use case: There is a service consumer and a service provider using SOAP/HTTPS. Both understand SAML tokens. An identity known in the security domain of the service consumer is not known to the domain of the service provider. This use case can be addressed by the following proposal. The IssuedToken assertion in the WS-SecurityPolicy document of the service provider defines the Issuer he trusts which is the so called Relying Party (RP) STS. The service consumer configures the STSClient bean where you define the URL of the STS which is the so called Identity Provider (IP) STS. If service consumer and service provider are in the same security domain (principal/id understood by service consumer and provider) the URLs/EPR are equal. If they are not I'd say we have the use case I described above. CXF 2.4 ignores the Issuer element in the IssuedToken assertion. wsa:EndpointReferenceType ... If they are different, the CXF service consumer must first go to the STS configured in the STSClient and gets a SAML token. Then the service consumer sends the previously issued token (in WS-Security header) to the Relying Party STS and let's issue a new token based on the data in the RequestSecurityTokenTemplate element of the policy. There must be a trust established between the IP STS and the RP STS. (This is *not* a case for OnBehalfOf support as described in WS-Trust spec) As far as I understand the WS-Federation spec this is the idea of the active requestor profile. It's then up to the Relying Party STS do implements claims transformation (like principal mapping, role mapping and other claims) Link to topic in mailing list: http://cxf.547215.n5.nabble.com/SAML-support-across-security-domains-SSO-td4372429.html > CXF support for cross domain SSO based on SAML token > > > Key: CXF-3520 > URL: https://issues.apache.org/jira/browse/CXF-3520 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.4 >Reporter: Oliver Wulff > > Use case: > There is a service consumer and a service provider using SOAP/HTTPS. Both > understand SAML tokens. An identity known in the security domain of the > service consumer is not known to the domain of the service provider. > This use case can be addressed by the following proposal. The IssuedToken > assertion in the WS-SecurityPolicy document of the service provider defines > the Issuer he trusts which is the so called Relying Party (RP) STS. The > service consumer configures the STSClient bean where you define the URL of > the STS which is the so called Identity Provider (IP) STS. > If service consumer and service provider are in the same security domain > (principal/id understood by service consumer and provider) the URLs/EPR are > equal. If they are not I'd say we have the use case I described above. CXF > 2.4 ignores the Issuer el
[jira] [Created] (CXF-3521) WebServiceContext.getUserPrincipal() is null for incoming SAML Token or transformed token
WebServiceContext.getUserPrincipal() is null for incoming SAML Token or
transformed token
-
Key: CXF-3521
URL: https://issues.apache.org/jira/browse/CXF-3521
Project: CXF
Issue Type: Improvement
Components: WS-* Components
Affects Versions: 2.4
Reporter: Oliver Wulff
If my service provider receives a SAML token or a BinarySecurityToken (will be
transformed) I can't read the principle using the JAX-WS WebServiceContext.
example:
...
@Resource
WebServiceContext wsContext;
public java.math.BigInteger doubleIt(java.math.BigInteger numberToDouble) {
Principal pr = wsContext.getUserPrincipal();
...
The method getUserPrincipal() returns null.
I see two ways to fix this.
1) Pass the principal to the constructor of WSSecurityEngineResult in the
processor of WSS4J
ex.
if (assertion.isSigned()) {
result = new WSSecurityEngineResult(WSConstants.ST_SIGNED,
assertion);
} else {
result = new WSSecurityEngineResult(WSConstants.ST_UNSIGNED,
assertion);
}
similar for BinarySecurityTokenProcessor.
This allows the CXF WSS4JInInterceptor to read the principal like this:
final Principal p = (Principal)o.get(WSSecurityEngineResult.TAG_PRINCIPAL);
2) Extend the WSS4JInInterceptor to parse the SAMLToken (or the transformed if
available), read the subject and create the CXF SecurityContext.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3521) WebServiceContext.getUserPrincipal() is null for incoming SAML Token or transformed token
[
https://issues.apache.org/jira/browse/CXF-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Wulff updated CXF-3521:
--
Attachment: DoubleItImpl.java
I've attached a new version for the SamlTokenTest which verifies the
UsernamePrinciple.
> WebServiceContext.getUserPrincipal() is null for incoming SAML Token or
> transformed token
> -
>
> Key: CXF-3521
> URL: https://issues.apache.org/jira/browse/CXF-3521
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
>Affects Versions: 2.4
>Reporter: Oliver Wulff
> Attachments: DoubleItImpl.java
>
>
> If my service provider receives a SAML token or a BinarySecurityToken (will
> be transformed) I can't read the principle using the JAX-WS WebServiceContext.
> example:
> ...
> @Resource
> WebServiceContext wsContext;
> public java.math.BigInteger doubleIt(java.math.BigInteger numberToDouble)
> {
> Principal pr = wsContext.getUserPrincipal();
> ...
> The method getUserPrincipal() returns null.
> I see two ways to fix this.
> 1) Pass the principal to the constructor of WSSecurityEngineResult in the
> processor of WSS4J
> ex.
> if (assertion.isSigned()) {
> result = new WSSecurityEngineResult(WSConstants.ST_SIGNED,
> assertion);
> } else {
> result = new WSSecurityEngineResult(WSConstants.ST_UNSIGNED,
> assertion);
> }
> similar for BinarySecurityTokenProcessor.
> This allows the CXF WSS4JInInterceptor to read the principal like this:
> final Principal p = (Principal)o.get(WSSecurityEngineResult.TAG_PRINCIPAL);
> 2) Extend the WSS4JInInterceptor to parse the SAMLToken (or the transformed
> if available), read the subject and create the CXF SecurityContext.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3522) Enhance CXF security context with claims information
Enhance CXF security context with claims information Key: CXF-3522 URL: https://issues.apache.org/jira/browse/CXF-3522 Project: CXF Issue Type: New Feature Reporter: Oliver Wulff Discussion around this feature started in the following thread: http://cxf.547215.n5.nabble.com/CXF-and-spring-security-td4368266.html The CXF SecurityContext provides the following two methods only: getUserPrincipal() isUserInRole() If the received security token is a SAML token further data (claims) can be in the token which might be relevant for authorization to implement the PEP/PDP in the application. WS-Trust has the following definition of a claim: A claim is a statement made about a client, service or other resource The following OASIS specification defines the URI for some claims like lastname, email, country, etc. (chapter 7.5): http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-spec-os.pdf We could introduce a ClaimSecurityContext interface which extends the current SecurityContext and introduces a new method like: List getClaims() A Claim consists of the following properties: ClaimType: URI (see spec mentioned above) Value: String / Object Additionally we can implement a ClaimsTranformer interface which depends on the security token type and creates an object which implements ClaimSecurityContext (similar design approach as for the validator implementation in WSS4J). We could provide out-of-the-box implementation for SAML 1.1 and 2.0 which parse the AttributeStatement and create the list of Claims object: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname";>Johnhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname";>Doehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth";>5/5/1955http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone";>555-555-http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress";>john@... In addition to that, the SamlClaimsTransformer can provide a property to define the URI how the role information is identified in the AttributeStatement. There is no standard claims URI for roles. Each STS uses a different URI. For instance, Microsoft ADFS uses the following URI: http://schemas.microsoft.com/ws/2008/06/identity/claims/role This would allow an application to use RBAC when they use ADFS and CXF out-of-the-box by using the isUserInRole of the WebServiceContext. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3523) Ability to force java2wsdl approach for javaws:client even if wsdlLocation is set (via populateFromClass property or, at least, custom jaxws:serviceFactory) when using spri
Ability to force java2wsdl approach for javaws:client even if wsdlLocation is set (via populateFromClass property or, at least, custom jaxws:serviceFactory) when using spring integration -- Key: CXF-3523 URL: https://issues.apache.org/jira/browse/CXF-3523 Project: CXF Issue Type: Improvement Components: Configuration Affects Versions: 2.3.4, 2.4, 2.2.12 Reporter: Albert Ruiz Priority: Minor To put into context: There's "no way" (i think there's one using some spring 'tricks') of using java2wsdl with client endpoints along with ServiceContractResolver functionality (to access an UDDI registry, for example). When using ServiceContractResolver, the wsdlLocation property gets updated, and this property is later used to determine the approach to use when initializing the service model. The same occurs with server endpoints but, at least, a custom jaxws:serviceFactory can be configured with populateFromClass set to true (this flag is checked when deciding how to initialize the model). ¿Is there a reason for jaxws:client not having the ability to pass a custom serviceFactory like server does? If there's a good reason for that (it seems to me that maybe this is done voluntarily) ¿couldn't a populateFromClass property be added to jaxws:client and jaxws:server to handle this when instantiating the default serviceFactory? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-3524) Support Derived Keys with the Symmetric Binding + SAML Assertions
[ https://issues.apache.org/jira/browse/CXF-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-3524: Assignee: Colm O hEigeartaigh > Support Derived Keys with the Symmetric Binding + SAML Assertions > - > > Key: CXF-3524 > URL: https://issues.apache.org/jira/browse/CXF-3524 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.4 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.4.1 > > > There are a couple of problems with using Derived Keys pointing towards SAML > Assertions when using the symmetric binding: > 1) The SymmetricBindingHandler can't handle creating a reference to SAML > Assertion if the security token does not have a (un)attached Reference to the > Assertion. > 2) In the holder-of-key case, using a derived key will cause the > holder-of-key requirements processing to fail. > Creating a JIRA + patch for this, as it depends on a fix in WSS4J 1.6.1 which > is not released yet. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3524) Support Derived Keys with the Symmetric Binding + SAML Assertions
[ https://issues.apache.org/jira/browse/CXF-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-3524: - Component/s: WS-* Components Description: There are a couple of problems with using Derived Keys pointing towards SAML Assertions when using the symmetric binding: 1) The SymmetricBindingHandler can't handle creating a reference to SAML Assertion if the security token does not have a (un)attached Reference to the Assertion. 2) In the holder-of-key case, using a derived key will cause the holder-of-key requirements processing to fail. Creating a JIRA + patch for this, as it depends on a fix in WSS4J 1.6.1 which is not released yet. was: There are a couple of problems with using Derived Keys pointing towards SAML Assertions when using the symmetric binding: 1) The SymmetricBindingHandler can't handle creating a reference to SAML Assertion if the security token does not have a (un)attached Reference to the Assertion. 2) In the holder-of-key case, using a derived key will cause the holder-of-key requirements processing to fail. Creating a JIRA + patch for this, as it depends on a fix in WSS4J 1.6.1 which is not released yet. Affects Version/s: 2.4 Fix Version/s: 2.4.1 > Support Derived Keys with the Symmetric Binding + SAML Assertions > - > > Key: CXF-3524 > URL: https://issues.apache.org/jira/browse/CXF-3524 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.4 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.4.1 > > > There are a couple of problems with using Derived Keys pointing towards SAML > Assertions when using the symmetric binding: > 1) The SymmetricBindingHandler can't handle creating a reference to SAML > Assertion if the security token does not have a (un)attached Reference to the > Assertion. > 2) In the holder-of-key case, using a derived key will cause the > holder-of-key requirements processing to fail. > Creating a JIRA + patch for this, as it depends on a fix in WSS4J 1.6.1 which > is not released yet. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3524) Support Derived Keys with the Symmetric Binding + SAML Assertions
Support Derived Keys with the Symmetric Binding + SAML Assertions - Key: CXF-3524 URL: https://issues.apache.org/jira/browse/CXF-3524 Project: CXF Issue Type: Bug Reporter: Colm O hEigeartaigh There are a couple of problems with using Derived Keys pointing towards SAML Assertions when using the symmetric binding: 1) The SymmetricBindingHandler can't handle creating a reference to SAML Assertion if the security token does not have a (un)attached Reference to the Assertion. 2) In the holder-of-key case, using a derived key will cause the holder-of-key requirements processing to fail. Creating a JIRA + patch for this, as it depends on a fix in WSS4J 1.6.1 which is not released yet. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3524) Support Derived Keys with the Symmetric Binding + SAML Assertions
[ https://issues.apache.org/jira/browse/CXF-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-3524: - Attachment: cxf-3524.patch > Support Derived Keys with the Symmetric Binding + SAML Assertions > - > > Key: CXF-3524 > URL: https://issues.apache.org/jira/browse/CXF-3524 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.4 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.4.1 > > Attachments: cxf-3524.patch > > > There are a couple of problems with using Derived Keys pointing towards SAML > Assertions when using the symmetric binding: > 1) The SymmetricBindingHandler can't handle creating a reference to SAML > Assertion if the security token does not have a (un)attached Reference to the > Assertion. > 2) In the holder-of-key case, using a derived key will cause the > holder-of-key requirements processing to fail. > Creating a JIRA + patch for this, as it depends on a fix in WSS4J 1.6.1 which > is not released yet. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3472) Cannot override HTTPConduit's handleResponse() method
[ https://issues.apache.org/jira/browse/CXF-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034127#comment-13034127 ] Daniel Kulp commented on CXF-3472: -- I just added a new protected "createOutputStream" method to the conduit so you may be able to make this even easier/cleaner by not even having the original WrappedOutputStream created. > Cannot override HTTPConduit's handleResponse() method > - > > Key: CXF-3472 > URL: https://issues.apache.org/jira/browse/CXF-3472 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.2, 2.4 >Reporter: David Liu >Assignee: Willem Jiang > Fix For: 2.4.1, 2.3.5 > > > Current, all response message processing of HTTPConduit is in the class > WrappedOutputStream, e.g. handleResponse(), and handleResponseInternal() > method, so we cannot extend HTTPConduit to override both method if we want to > add more functions during processing response. because the class > WrappedOutputStream need some input parameter and the its sub-class cannot > get these private properties. > My use case is: I have my customized HTTPConduit which needs to override > handleResponse() method to catch its instead of cxf's default logic. > Can cxf move both meothd from WrappedOutputStream class to HTTPConduit so > that we can override them? thanks. > David -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3524) Support Derived Keys with the Symmetric Binding + SAML Assertions
[ https://issues.apache.org/jira/browse/CXF-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-3524: - CXF Fields: [Blocked on External] > Support Derived Keys with the Symmetric Binding + SAML Assertions > - > > Key: CXF-3524 > URL: https://issues.apache.org/jira/browse/CXF-3524 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.4 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.4.1 > > Attachments: cxf-3524.patch > > > There are a couple of problems with using Derived Keys pointing towards SAML > Assertions when using the symmetric binding: > 1) The SymmetricBindingHandler can't handle creating a reference to SAML > Assertion if the security token does not have a (un)attached Reference to the > Assertion. > 2) In the holder-of-key case, using a derived key will cause the > holder-of-key requirements processing to fail. > Creating a JIRA + patch for this, as it depends on a fix in WSS4J 1.6.1 which > is not released yet. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3523) Ability to force java2wsdl approach for javaws:client even if wsdlLocation is set (via populateFromClass property or, at least, custom jaxws:serviceFactory) when using sp
[ https://issues.apache.org/jira/browse/CXF-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034188#comment-13034188 ] Daniel Kulp commented on CXF-3523: -- Does something like wsdlLocation="" not work? In theory, setting the wsdlLocation to an empty string might override the annotation. Not 100% sure though. That would likely be the proper solution though. If the wsdlLocation is set like that, it should force the the populateFromClass setting. > Ability to force java2wsdl approach for javaws:client even if wsdlLocation is > set (via populateFromClass property or, at least, custom > jaxws:serviceFactory) when using spring integration > -- > > Key: CXF-3523 > URL: https://issues.apache.org/jira/browse/CXF-3523 > Project: CXF > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.2.12, 2.4, 2.3.4 >Reporter: Albert Ruiz >Priority: Minor > > To put into context: There's "no way" (i think there's one using some spring > 'tricks') of using java2wsdl with client endpoints along with > ServiceContractResolver functionality (to access an UDDI registry, for > example). When using ServiceContractResolver, the wsdlLocation property gets > updated, and this property is later used to determine the approach to use > when initializing the service model. The same occurs with server endpoints > but, at least, a custom jaxws:serviceFactory can be configured with > populateFromClass set to true (this flag is checked when deciding how to > initialize the model). > ¿Is there a reason for jaxws:client not having the ability to pass a custom > serviceFactory like server does? If there's a good reason for that (it seems > to me that maybe this is done voluntarily) ¿couldn't a populateFromClass > property be added to jaxws:client and jaxws:server to handle this when > instantiating the default serviceFactory? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3518) WebClient doesn't handle responses containing a quoted-string in a header correctly
[
https://issues.apache.org/jira/browse/CXF-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034268#comment-13034268
]
Sergey Beryozkin commented on CXF-3518:
---
Hi, thanks for this patch.
I'm a bit concerned about introducing HttpHeaderImpl in there, given that some
headers, notably Set-Cookie, can contain a combination of all sort of values,
ex,
Set-Cookie: bar.com.anoncart=107894933471602436; Domain=.bar.com;Expires=Thu,
01-Oct-2020 23:44:22 GMT; Path=/
and I'm worried we could break some existing code there if we try to
generalize, because HttpHeadersImpl will split by default.
What do you think of the following approach:
I reckon that realistically, as far as \" character is concerned, we can expect
SomeHeader: "some text, some more text"
or
SomeHeader: "some text, some more text","even more text"
but not
SomeHeader: "some text, some more text with inlined \""
which may not be even legal.
So would checking if the header value starts with \" and if yes then parse it
using fast indexOf will work well in most/all such cases ?
Cheers, Sergey
> WebClient doesn't handle responses containing a quoted-string in a header
> correctly
> ---
>
> Key: CXF-3518
> URL: https://issues.apache.org/jira/browse/CXF-3518
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.4, 2.3.4
> Environment: JDK 1.6
>Reporter: Ka-Lok Fung
>Priority: Minor
> Fix For: 2.4.1, 2.3.5
>
> Attachments: trunk.wc_quote_minimal.diff
>
>
> Similar to CXF-2462, if a request returns a response header that looks like
> the following:
> bq. {{q: "stuff with commas, and spaces"}}
> WebClient's response.getMetadata() returns 2 values:
> {quote}
> # "stuff with commas
> # and spaces"
> {quote}
> while the correct response should be:
> {quote}
> # stuff with commas, and spaces
> {quote}
> Here's the WebClient code which reproduces the issue (as long as the server
> response contains a header that returns the header value above):
> {code:Java}
> Response r = WebClient.create(new
> URI("http://localhost:8080";)).path("key/quoted").get();
> List l = r.getMetadata().get("q");
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3518) WebClient doesn't handle responses containing a quoted-string in a header correctly
[
https://issues.apache.org/jira/browse/CXF-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034302#comment-13034302
]
Ka-Lok Fung commented on CXF-3518:
--
For my use cases, your suggestion will work:
bq. So would checking if the header value starts with \" and if yes then parse
it using fast indexOf will work well in most/all such cases ?
However, this is technically allowed (per RFC2616, section 2.2, see quoted-pair)
bq. SomeHeader: "some text, some more text with inlined \""
What do you think of me submitting another patch that works for the following
use cases:
* {{SomeHeader: "some text, some more text"}}
* {{SomeHeader: "some text","quoted,text","even more text"}}
* {{SomeHeader: "some text, some more text with inlined \""}}
but would fail for the following use case:
* {{SomeHeader: some text,"other quoted, text","blah"}}
Because we're doing text scanning, I'm thinking that the most efficient way to
do this is actually going character by character in the string (converting to
{{char[]}} first) than using indexOf. However, I could do a benchmark to see
which is faster and choose that for the patch :)
What do you think?
> WebClient doesn't handle responses containing a quoted-string in a header
> correctly
> ---
>
> Key: CXF-3518
> URL: https://issues.apache.org/jira/browse/CXF-3518
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.4, 2.3.4
> Environment: JDK 1.6
>Reporter: Ka-Lok Fung
>Priority: Minor
> Fix For: 2.4.1, 2.3.5
>
> Attachments: trunk.wc_quote_minimal.diff
>
>
> Similar to CXF-2462, if a request returns a response header that looks like
> the following:
> bq. {{q: "stuff with commas, and spaces"}}
> WebClient's response.getMetadata() returns 2 values:
> {quote}
> # "stuff with commas
> # and spaces"
> {quote}
> while the correct response should be:
> {quote}
> # stuff with commas, and spaces
> {quote}
> Here's the WebClient code which reproduces the issue (as long as the server
> response contains a header that returns the header value above):
> {code:Java}
> Response r = WebClient.create(new
> URI("http://localhost:8080";)).path("key/quoted").get();
> List l = r.getMetadata().get("q");
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3518) WebClient doesn't handle responses containing a quoted-string in a header correctly
[
https://issues.apache.org/jira/browse/CXF-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034306#comment-13034306
]
Sergey Beryozkin commented on CXF-3518:
---
Hi
Failing
* {{SomeHeader: some text,"other quoted, text","blah"}}
is not a problem because it's reasonable to expect multiple SomeHeader headers
in such cases.
SomeHeader: some text
SomeHeader: "other quoted, text","blah"
If we ever get a single line like that then we can see what can be improved. We
can always have contextual properties which can tell the client which headers
may need some special processing/etc
thanks, Sergey
> WebClient doesn't handle responses containing a quoted-string in a header
> correctly
> ---
>
> Key: CXF-3518
> URL: https://issues.apache.org/jira/browse/CXF-3518
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.4, 2.3.4
> Environment: JDK 1.6
>Reporter: Ka-Lok Fung
>Priority: Minor
> Fix For: 2.4.1, 2.3.5
>
> Attachments: trunk.wc_quote_minimal.diff
>
>
> Similar to CXF-2462, if a request returns a response header that looks like
> the following:
> bq. {{q: "stuff with commas, and spaces"}}
> WebClient's response.getMetadata() returns 2 values:
> {quote}
> # "stuff with commas
> # and spaces"
> {quote}
> while the correct response should be:
> {quote}
> # stuff with commas, and spaces
> {quote}
> Here's the WebClient code which reproduces the issue (as long as the server
> response contains a header that returns the header value above):
> {code:Java}
> Response r = WebClient.create(new
> URI("http://localhost:8080";)).path("key/quoted").get();
> List l = r.getMetadata().get("q");
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3518) WebClient doesn't handle responses containing a quoted-string in a header correctly
[
https://issues.apache.org/jira/browse/CXF-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034309#comment-13034309
]
Ka-Lok Fung commented on CXF-3518:
--
Okay, that works for me. I'll work on this tonight then.
By the way, did you have any suggestions for the unit test question I had? Is
there a way I can easily/moderately add a unit test for this?
-kl
> WebClient doesn't handle responses containing a quoted-string in a header
> correctly
> ---
>
> Key: CXF-3518
> URL: https://issues.apache.org/jira/browse/CXF-3518
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.4, 2.3.4
> Environment: JDK 1.6
>Reporter: Ka-Lok Fung
>Priority: Minor
> Fix For: 2.4.1, 2.3.5
>
> Attachments: trunk.wc_quote_minimal.diff
>
>
> Similar to CXF-2462, if a request returns a response header that looks like
> the following:
> bq. {{q: "stuff with commas, and spaces"}}
> WebClient's response.getMetadata() returns 2 values:
> {quote}
> # "stuff with commas
> # and spaces"
> {quote}
> while the correct response should be:
> {quote}
> # stuff with commas, and spaces
> {quote}
> Here's the WebClient code which reproduces the issue (as long as the server
> response contains a header that returns the header value above):
> {code:Java}
> Response r = WebClient.create(new
> URI("http://localhost:8080";)).path("key/quoted").get();
> List l = r.getMetadata().get("q");
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3518) WebClient doesn't handle responses containing a quoted-string in a header correctly
[
https://issues.apache.org/jira/browse/CXF-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034319#comment-13034319
]
Sergey Beryozkin commented on CXF-3518:
---
At the moment the fact that HttpURLConnection is directly dealt with is
problematic. We will definitely refactor the client runtime, for the async
conduit be supported better, for a local transport be supported, etc. That will
have to become a priority soon enough, however we are more focused at the
moment on wadl and security.
In meantime, I tend to update real system tests to test such cases, ex, please
copy & paste one of BookStore methods in systest/jaxrs and then add a test
invocation in JAXRSClientServerBookTest. That will work with Jetty. I believe
one can do a similar test even in rt/frontend/jaxrs, but I'll need to review
how it can be done
Cheers, Sergey
> WebClient doesn't handle responses containing a quoted-string in a header
> correctly
> ---
>
> Key: CXF-3518
> URL: https://issues.apache.org/jira/browse/CXF-3518
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.4, 2.3.4
> Environment: JDK 1.6
>Reporter: Ka-Lok Fung
>Priority: Minor
> Fix For: 2.4.1, 2.3.5
>
> Attachments: trunk.wc_quote_minimal.diff
>
>
> Similar to CXF-2462, if a request returns a response header that looks like
> the following:
> bq. {{q: "stuff with commas, and spaces"}}
> WebClient's response.getMetadata() returns 2 values:
> {quote}
> # "stuff with commas
> # and spaces"
> {quote}
> while the correct response should be:
> {quote}
> # stuff with commas, and spaces
> {quote}
> Here's the WebClient code which reproduces the issue (as long as the server
> response contains a header that returns the header value above):
> {code:Java}
> Response r = WebClient.create(new
> URI("http://localhost:8080";)).path("key/quoted").get();
> List l = r.getMetadata().get("q");
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3525) JAXB provider can not read explicit collections of beans which have no @XmlRootElement
JAXB provider can not read explicit collections of beans which have no @XmlRootElement -- Key: CXF-3525 URL: https://issues.apache.org/jira/browse/CXF-3525 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 2.3.4, 2.4 Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 2.4.1, 2.3.5 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3525) JAXB provider can not read explicit collections of beans which have no @XmlRootElement
[ https://issues.apache.org/jira/browse/CXF-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3525. --- Resolution: Fixed > JAXB provider can not read explicit collections of beans which have no > @XmlRootElement > -- > > Key: CXF-3525 > URL: https://issues.apache.org/jira/browse/CXF-3525 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.4, 2.3.4 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.4.1, 2.3.5 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-3504) for big attachment, a temporary file is left on disk and keep opend, if the application just close the DataSource's inputStream and doesn't consume it;
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-3504: - Assignee: Freeman Fang > for big attachment, a temporary file is left on disk and keep opend, if the > application just close the DataSource's inputStream and doesn't consume it; > > > Key: CXF-3504 > URL: https://issues.apache.org/jira/browse/CXF-3504 > Project: CXF > Issue Type: Bug >Affects Versions: 2.4 >Reporter: ext2 >Assignee: Freeman Fang > Attachments: attachment-clean.zip, mtom.wsdl > > > when the client receiving multiple larget attachments from server. here > "large" means : attachment size is large enough to be saved as temporary file > on disk; > for the last attachment, if the user application only close the input stream > got from DataSource and doesn't consume the input stream at all, a temporary > file will be left on the disk. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3518) WebClient doesn't handle responses containing a quoted-string in a header correctly
[
https://issues.apache.org/jira/browse/CXF-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ka-Lok Fung updated CXF-3518:
-
Attachment: trunk.webclient.quote.try2.diff
I've implemented the "good enough" proposal per the feedback from Sergey.
As long as long all the values inside the header are appropriately quoted, they
will be available to {{WebClient}}. If the values aren't quoted correctly,
{{WebClient}} will apply a "best effort" approach to return the header data
from the server to the client.
I've also added/modified three system tests to component test these changes:
* I've extended the ETag test to make sure the current {{WebClient}} behaviour
remains - that is, if the server returned quoted values, {{WebClient}} also
return quoted values.
* Added a test for quoted-strings in headers
* Added a test for malformed quoted-strings in headers & broken per spec case
discussed above
> WebClient doesn't handle responses containing a quoted-string in a header
> correctly
> ---
>
> Key: CXF-3518
> URL: https://issues.apache.org/jira/browse/CXF-3518
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.4, 2.3.4
> Environment: JDK 1.6
>Reporter: Ka-Lok Fung
>Priority: Minor
> Fix For: 2.4.1, 2.3.5
>
> Attachments: trunk.wc_quote_minimal.diff,
> trunk.webclient.quote.try2.diff
>
>
> Similar to CXF-2462, if a request returns a response header that looks like
> the following:
> bq. {{q: "stuff with commas, and spaces"}}
> WebClient's response.getMetadata() returns 2 values:
> {quote}
> # "stuff with commas
> # and spaces"
> {quote}
> while the correct response should be:
> {quote}
> # stuff with commas, and spaces
> {quote}
> Here's the WebClient code which reproduces the issue (as long as the server
> response contains a header that returns the header value above):
> {code:Java}
> Response r = WebClient.create(new
> URI("http://localhost:8080";)).path("key/quoted").get();
> List l = r.getMetadata().get("q");
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
