[jira] [Reopened] (CXF-4347) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin reopened CXF-4347:
---
Assignee: Sergey Beryozkin
Hi Freeman, it might be that the issue I referred to was about producing the
multipart/form-data with the recursive parts on the output. I'm not sure at
this stage if this issue is exactly a duplicate of that issue, so I need to
investigate
> Content-Type is broken in multipart serialization
> -
>
> Key: CXF-4347
> URL: https://issues.apache.org/jira/browse/CXF-4347
> Project: CXF
> Issue Type: Bug
> Environment: Any
>Reporter: Ivan Bondarenko
>Assignee: Sergey Beryozkin
>Priority: Blocker
> Labels: bug, multipart, serialization
>
> Multiparts are serialized incorrectly.
> Imagine the response with two attachments:
> a) "filename1.doc" with attachment-id "Attachment_id1" and Content-Type
> "application/msword"
> b) "filename2.xls" with attachment-id "Attachment_id2" and Content-Type
> "application/vnd.ms-excel"
> Serialization of this Multipart is ({} are used for text reduction):
> HTTP/1.1 200 OK
> Server: ...
> Date: ...
> Content-Type: application/octet-stream; type="application/msword";
> boundary="uuid:{UUID}"; start="";
> start-info="application/msword"
> Transfer-Encoding: chunked
> --uuid:{UUID}
> Content-Type: text/xml; charset=UTF-8; type="application/msword";
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename1.doc
> {CONTENT1}
> --uuid:{UUID}
> Content-Type: application/vnd.ms-excel
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename2.xls
> {CONTENT2}
> --uuid:{UUID}--
> While we are expecting kind of this:
> HTTP/1.1 200 OK
> Server: ...
> Date: ...
> Content-Type: multipart/related
> Transfer-Encoding: chunked
> --uuid:{UUID}
> Content-Type: application/msword;
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename1.doc
> {CONTENT1}
> --uuid:{UUID}
> Content-Type: application/vnd.ms-excel
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename2.xls
> {CONTENT2}
> --uuid:{UUID}--
> So the Content-Type of the whole response and of the first part are incorrect.
> The starting point of the bug searching is
> org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
> method, which has at least these sub-bugs:
> 1) First attachment is handled other way than all subsequent ones -> All
> attachments must be handled in the same way.
> 2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
> which is "application/octet-stream" -> The type must be "multipart/related"
> (or other multipart).
> 3) Content-Type of outMessage is changed to the first attachment's
> Content-Type and then new type is used at least in
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method -> The
> same type must be used.
--
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] [Closed] (CXF-4347) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin closed CXF-4347.
-
Resolution: Duplicate
oops, Freeman, you are right :-), 4348 is the issue to deal with
> Content-Type is broken in multipart serialization
> -
>
> Key: CXF-4347
> URL: https://issues.apache.org/jira/browse/CXF-4347
> Project: CXF
> Issue Type: Bug
> Environment: Any
>Reporter: Ivan Bondarenko
>Assignee: Sergey Beryozkin
>Priority: Blocker
> Labels: bug, multipart, serialization
>
> Multiparts are serialized incorrectly.
> Imagine the response with two attachments:
> a) "filename1.doc" with attachment-id "Attachment_id1" and Content-Type
> "application/msword"
> b) "filename2.xls" with attachment-id "Attachment_id2" and Content-Type
> "application/vnd.ms-excel"
> Serialization of this Multipart is ({} are used for text reduction):
> HTTP/1.1 200 OK
> Server: ...
> Date: ...
> Content-Type: application/octet-stream; type="application/msword";
> boundary="uuid:{UUID}"; start="";
> start-info="application/msword"
> Transfer-Encoding: chunked
> --uuid:{UUID}
> Content-Type: text/xml; charset=UTF-8; type="application/msword";
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename1.doc
> {CONTENT1}
> --uuid:{UUID}
> Content-Type: application/vnd.ms-excel
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename2.xls
> {CONTENT2}
> --uuid:{UUID}--
> While we are expecting kind of this:
> HTTP/1.1 200 OK
> Server: ...
> Date: ...
> Content-Type: multipart/related
> Transfer-Encoding: chunked
> --uuid:{UUID}
> Content-Type: application/msword;
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename1.doc
> {CONTENT1}
> --uuid:{UUID}
> Content-Type: application/vnd.ms-excel
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename2.xls
> {CONTENT2}
> --uuid:{UUID}--
> So the Content-Type of the whole response and of the first part are incorrect.
> The starting point of the bug searching is
> org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
> method, which has at least these sub-bugs:
> 1) First attachment is handled other way than all subsequent ones -> All
> attachments must be handled in the same way.
> 2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
> which is "application/octet-stream" -> The type must be "multipart/related"
> (or other multipart).
> 3) Content-Type of outMessage is changed to the first attachment's
> Content-Type and then new type is used at least in
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method -> The
> same type must be used.
--
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-4209) Server side message redelivery support for WS-RM
[ https://issues.apache.org/jira/browse/CXF-4209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida updated CXF-4209: - Fix Version/s: (was: 2.6.1) > Server side message redelivery support for WS-RM > > > Key: CXF-4209 > URL: https://issues.apache.org/jira/browse/CXF-4209 > Project: CXF > Issue Type: New Feature > Components: WS-* Components >Reporter: Aki Yoshida >Assignee: Aki Yoshida > > Currently, when a WS-RM message reaches the RM-Destination at the server side > but not the service itself, there is no mechanism to redeliver this message > to the service. There is also no mechanism for redelivering those persisted > messages at the RM-Destination to the services when the corresponding > destination endpoints are restarted. > A retry mechanism similar to what is available at the RM-Source for message > retransmission can be provided at the RM-Destination to enable message > redelivery. -- 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] (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:comment-tabpanel&focusedCommentId=13285553#comment-13285553 ] Colm O hEigeartaigh commented on CXF-3520: -- "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. " Does the STS client call the issue or validate binding on the Relying Party STS? Colm. > 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 thread in mailing list: > http://cxf.547215.n5.nabble.com/SAML-support-across-security-domains-SSO-td4372429.html -- 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] (CXF-4346) Support to set the messageType from the jms URI
[ https://issues.apache.org/jira/browse/CXF-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285661#comment-13285661 ] Willem Jiang commented on CXF-4346: --- trunk: http://svn.apache.org/viewvc?rev=1343561&view=rev 2.5.x-fixes: http://svn.apache.org/viewvc?rev=1343581&view=rev 2.4.x-fixes: http://svn.apache.org/viewvc?rev=1344067&view=rev > Support to set the messageType from the jms URI > --- > > Key: CXF-4346 > URL: https://issues.apache.org/jira/browse/CXF-4346 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Willem Jiang >Assignee: Willem Jiang > Fix For: 2.4.8, 2.5.4, 2.6.1 > > > When the user use URI to setup the jms address it should be more convince if > the URI support to set the messageType. > BTW, current CXF only set the messageType to be 'byte' when it load the > address from URI. -- 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] [Assigned] (CXF-4344) Provide simplifications and shortcuts in CXF STS configuration
[ https://issues.apache.org/jira/browse/CXF-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-4344: Assignee: Colm O hEigeartaigh > Provide simplifications and shortcuts in CXF STS configuration > -- > > Key: CXF-4344 > URL: https://issues.apache.org/jira/browse/CXF-4344 > Project: CXF > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Glen Mazza >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.6.2 > > > Presently STS configuration in the cxf-servlet.xml file is a bit verbose[1], > especially if one is planning on configuring multiple STS endpoints within > the same file. I would like to see configuration simplified a bit for those > wishing to remain with default/common settings. In particular: > 1.) In any SecurityTokenServiceProvider instantiation, default the values of > issueOperation and validateOperation to > org.apache.cxf.sts.operation.TokenIssueOperation and > org.apache.cxf.sts.operation.TokenValidateOperation if not explicitly > specified (same for the other operations). If concerned about hardwiring > constant classes in such a manner, create a > DefaultSecurityTokenServiceProvider with these defaults that people can use > instead. > 2.) Provide properties "stsProperties" and "services" for the > SecurityTokenServiceProvider (perhaps other properties defined > in AbstractOperation) that will be the default for AbstractOperation > subclasses like TokenIssueOperation and TokenValidateOperation unless > explicitly defined as done presently. > 3.) For TokenIssueOperation and TokenValidateOperation, default the values of > tokenProviders and tokenValidators to SAMLTokenProvider and > SAMLTokenValidator unless explicitly defined as done presently. > Such shortcuts will allow configuration to simplified from this: > > class="org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider"> > > > > class="org.apache.cxf.sts.operation.TokenIssueOperation"> > > > > > class="org.apache.cxf.sts.operation.TokenValidateOperation"> > > > > class="org.apache.cxf.sts.token.provider.SAMLTokenProvider"/> > class="org.apache.cxf.sts.token.validator.SAMLTokenValidator"/> > to this: > > class="org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider"> > > > > These changes can probably all be done in a backwards-compatible manner so it > wouldn't be necessary to wait for CXF 2.7 before implementing. > [1] > http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/sts/src/demo/wssec/sts/wssec-sts.xml?revision=1190520&view=markup > -- 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-4344) Provide simplifications and shortcuts in CXF STS configuration
[ https://issues.apache.org/jira/browse/CXF-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-4344: - Fix Version/s: (was: 2.6.1) 2.6.2 > Provide simplifications and shortcuts in CXF STS configuration > -- > > Key: CXF-4344 > URL: https://issues.apache.org/jira/browse/CXF-4344 > Project: CXF > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Glen Mazza >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.6.2 > > > Presently STS configuration in the cxf-servlet.xml file is a bit verbose[1], > especially if one is planning on configuring multiple STS endpoints within > the same file. I would like to see configuration simplified a bit for those > wishing to remain with default/common settings. In particular: > 1.) In any SecurityTokenServiceProvider instantiation, default the values of > issueOperation and validateOperation to > org.apache.cxf.sts.operation.TokenIssueOperation and > org.apache.cxf.sts.operation.TokenValidateOperation if not explicitly > specified (same for the other operations). If concerned about hardwiring > constant classes in such a manner, create a > DefaultSecurityTokenServiceProvider with these defaults that people can use > instead. > 2.) Provide properties "stsProperties" and "services" for the > SecurityTokenServiceProvider (perhaps other properties defined > in AbstractOperation) that will be the default for AbstractOperation > subclasses like TokenIssueOperation and TokenValidateOperation unless > explicitly defined as done presently. > 3.) For TokenIssueOperation and TokenValidateOperation, default the values of > tokenProviders and tokenValidators to SAMLTokenProvider and > SAMLTokenValidator unless explicitly defined as done presently. > Such shortcuts will allow configuration to simplified from this: > > class="org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider"> > > > > class="org.apache.cxf.sts.operation.TokenIssueOperation"> > > > > > class="org.apache.cxf.sts.operation.TokenValidateOperation"> > > > > class="org.apache.cxf.sts.token.provider.SAMLTokenProvider"/> > class="org.apache.cxf.sts.token.validator.SAMLTokenValidator"/> > to this: > > class="org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider"> > > > > These changes can probably all be done in a backwards-compatible manner so it > wouldn't be necessary to wait for CXF 2.7 before implementing. > [1] > http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/sts/src/demo/wssec/sts/wssec-sts.xml?revision=1190520&view=markup > -- 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] (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:comment-tabpanel&focusedCommentId=13285668#comment-13285668 ] Oliver Wulff commented on CXF-3520: --- It's an issue request to the RP STS. > 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 thread in mailing list: > http://cxf.547215.n5.nabble.com/SAML-support-across-security-domains-SSO-td4372429.html -- 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] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285795#comment-13285795
]
Sergey Beryozkin commented on CXF-4348:
---
Ivan,
> 2) AttachmentOutputInterceptor is created with some default Content-Type,
> which is "application/octet-stream" -> The type must be "multipart/related"
> (or other multipart).
note that the method in your code @Produces("multipart/*"). I can reproduce
that the response message's Content-Type is set to "application/octet-stream",
but only if no "Accept: multipart-related" exists. If I update the client to
set "Accept: multipart-related", then the message Content-Type is set correctly
to multipart-related, with other parameters like start-info, etc, included.
Can you confirm that you have a specific multipart media type listed in Accept ?
I can confirm that when we have more than one part returned, the Content-Type
of the root part is broken. Will be fixing it
> Content-Type is broken in multipart serialization
> -
>
> Key: CXF-4348
> URL: https://issues.apache.org/jira/browse/CXF-4348
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Environment: Any
>Reporter: Ivan Bondarenko
>Priority: Blocker
> Labels: bug, multipart, serialization
>
> Multiparts are serialized incorrectly.
> Imagine the response with two attachments:
> a) "filename1.doc" with attachment-id "Attachment_id1" and Content-Type
> "application/msword"
> b) "filename2.xls" with attachment-id "Attachment_id2" and Content-Type
> "application/vnd.ms-excel"
> Serialization of this Multipart is ({} are used for text reduction):
> HTTP/1.1 200 OK
> Server: ...
> Date: ...
> Content-Type: application/octet-stream; type="application/msword";
> boundary="uuid:{UUID}"; start="";
> start-info="application/msword"
> Transfer-Encoding: chunked
> --uuid:{UUID}
> Content-Type: text/xml; charset=UTF-8; type="application/msword";
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename1.doc
> {CONTENT1}
> --uuid:{UUID}
> Content-Type: application/vnd.ms-excel
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename2.xls
> {CONTENT2}
> --uuid:{UUID}--
> While we are expecting kind of this:
> HTTP/1.1 200 OK
> Server: ...
> Date: ...
> Content-Type: multipart/related
> Transfer-Encoding: chunked
> --uuid:{UUID}
> Content-Type: application/msword;
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename1.doc
> {CONTENT1}
> --uuid:{UUID}
> Content-Type: application/vnd.ms-excel
> Content-Transfer-Encoding: binary
> Content-ID:
> Content-Disposition: attachment; filename=filename2.xls
> {CONTENT2}
> --uuid:{UUID}--
> So the Content-Type of the whole response and of the first part are incorrect.
> The starting point of the bug searching is
> org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
> method, which has at least these sub-bugs:
> 1) First attachment is handled other way than all subsequent ones -> All
> attachments must be handled in the same way.
> 2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
> which is "application/octet-stream" -> The type must be "multipart/related"
> (or other multipart).
> 3) Content-Type of outMessage is changed to the first attachment's
> Content-Type and then new type is used at least in
> org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method -> The
> same type must be used.
--
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] (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:comment-tabpanel&focusedCommentId=13285946#comment-13285946 ] Oliver Wulff commented on CXF-3520: --- This issue depends on CXF-3883 for the STS > 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 thread in mailing list: > http://cxf.547215.n5.nabble.com/SAML-support-across-security-domains-SSO-td4372429.html -- 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] (CXF-3883) Support for identity mapping as part of issue token process
[ https://issues.apache.org/jira/browse/CXF-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285962#comment-13285962 ] Oliver Wulff commented on CXF-3883: --- If the STS must be able to map the identity/claims he must know from which security domain (realm) to which security domain. The latter is defined by a RealmParser implementation. Options could be based the TCP Port as each realm runs in a different JVM or based on the URI like (.../STS//...). The source realm must be encoded in the retrieved token which is possible with a SAML token (or X509). The SAMLRealmCodec interface provides customization to tell the STS how to parse the realm in the SAML token. This could be done by using an individual cert/pk for each security domain where the realm is encoded in the DN. Currently, the TokenProvider has only access to the principal of the token passed in the WS-Sec header but he requires access to the realm as well. The TokenIssueOperation is called when the SAML assertion is valid and the issuer of this token is trusted by this STS realm instance. Then, the TokenIssueOperation must parse the realm of the SAML token (SAMLRealmCodec) and get the its own realm (RealmParser). If it's equal don't do anything as right now. If different, figure out what kind of relationship is defined between the two realms (principal oder claims mapping), do the mapping. TokenProviderParameters provides a new attribute "mappedPrincipal" attribute (new) where the mapped id is stored. I'd like to wrap the security token used for authentication in the WS-Sec header in a ReceivedToken thus any TokenProvider has access to it (optional). The subject provider will first check whether there is a mappedPrincipal set before falling back to the principal attribute. > Support for identity mapping as part of issue token process > --- > > Key: CXF-3883 > URL: https://issues.apache.org/jira/browse/CXF-3883 > Project: CXF > Issue Type: New Feature > Components: Services >Affects Versions: 2.5 >Reporter: Oliver Wulff > > The JIRA https://issues.apache.org/jira/browse/CXF-3520 describes the case > where a CXF consumer has configured a different STS than the issuer > configured in the IssuedToken assertion of the service provider: > In this case, the service consumer and provider don't understand the > identity/subject/principal of the counterpart. First, the consumer gets a > token from its STS (IDP-STS) which could be a SAML token. Then he requests > another token from the STS and sends the one issued before as part of the > WS-Security header. > The STS must figure out that the sent and requested tokens are from different > realms (security domains) and must therefore call the configured identity > mapper which takes as parameters source realm, target realm and source > principal. -- 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] (CXF-2937) character encoding in cxf-codegen is wrong
[ https://issues.apache.org/jira/browse/CXF-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286035#comment-13286035 ] Markus Umefjord commented on CXF-2937: -- This fix works for me (also had problems with Swedish characters in comments in the UTF-8 encoded WSDLs). I appreciate the fix, thanks!! Just tested latest snapshot (5/30/12) with apache-snapshots https://repository.apache.org/content/groups/snapshots true ... org.apache.cxf cxf-codegen-plugin 2.6.1-SNAPSHOT ... ... com.sun.xml.bind jaxb1-impl 2.2.5.1 com.sun.xml.bind jaxb-xjc 2.2.5-2 > character encoding in cxf-codegen is wrong > -- > > Key: CXF-2937 > URL: https://issues.apache.org/jira/browse/CXF-2937 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.2.9 > Environment: windows, sun java 6 >Reporter: Martin Goldhahn >Assignee: Daniel Kulp > Fix For: 2.5.4, 2.6.1 > > > We develop on linux and Windows concurrently. Therefor we choose to use UTF-8 > as source encoding. We also set the property project.build.sourceEncoding in > maven to utf-8. > Further we have a utf-8 encoded WSDL with some comments in Norwegian > (containing letters like åæø). On Windows the generated code contains these > characters as ISO-8859-1 even though I set -Dfile.encoding=utf-8 on the maven > command line. > A workaround is to set the property project.build.sourceEncoding in a maven > profile and activate it by OS. -- 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-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
Chris Dolan created CXF-4351:
Summary: No JSON output under OSGi because cxf-rt-frontend-jaxrs
is missing Import-Package for org.apache.cxf.jaxrs.provider.json
Key: CXF-4351
URL: https://issues.apache.org/jira/browse/CXF-4351
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6
Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
Reporter: Chris Dolan
I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
feature "cxf" to pull in most of the CXF bundles.
When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
following when my Accepts header is application/json:
{noformat}
2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
writer has been found for response class HealthItemCollection. -
o.a.c.j.i.JAXRSOutInterceptor
{noformat}
I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
this:
{noformat}
java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.json.JSONProvider
{noformat}
Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
and other providers that were moved to the new cxf-rt-rs-extension-providers
bundle for 2.6.0.
I think the solution is to simply add an import for
org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
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] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286131#comment-13286131
]
Chris Dolan commented on CXF-4351:
--
Workaround: simply add "new JSONProvider()" to my application via
JAXRSServerFactoryBean.setProviders()
> No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing
> Import-Package for org.apache.cxf.jaxrs.provider.json
>
>
> Key: CXF-4351
> URL: https://issues.apache.org/jira/browse/CXF-4351
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.6
> Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
>Reporter: Chris Dolan
>
> I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
> feature "cxf" to pull in most of the CXF bundles.
> When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
> following when my Accepts header is application/json:
> {noformat}
> 2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
> writer has been found for response class HealthItemCollection. -
> o.a.c.j.i.JAXRSOutInterceptor
> {noformat}
> I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
> this:
> {noformat}
> java.lang.ClassNotFoundException:
> org.apache.cxf.jaxrs.provider.json.JSONProvider
> {noformat}
> Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
> Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
> and other providers that were moved to the new cxf-rt-rs-extension-providers
> bundle for 2.6.0.
> I think the solution is to simply add an import for
> org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
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
