[jira] [Commented] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750878#comment-16750878 ] Tomas Vanhala commented on CXF-7941: Thank you for fixing the constraint separator issue, very much appreciated. We made some changes to our testclient, now it creates a request that is almost identical to request-real-sanitised.xml. Chain trust works just fine for this request. The initally reported CXF/WSS4J behaviour was triggered by a request, which erroneously used PublicKey as the signing credentials of the KeyInfo. The prerequisites for chain trust are not present in this case, CXF/WSS4J works as designed.This bug report can be rejected. > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip, obsolete-code.txt, > request-real-sanitised.xml, request-test-broken-sanitised.xml, > request-test-working-sanitised.xml, stacktrace-request-test-broken.txt > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7943) MAPCodec: Memory leak due to growing uncorrelatedExchanges
[ https://issues.apache.org/jira/browse/CXF-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751009#comment-16751009 ] Adolfo Volpe commented on CXF-7943: --- I think that the growth is caused by fault response received. Take a look at attachments. > MAPCodec: Memory leak due to growing uncorrelatedExchanges > -- > > Key: CXF-7943 > URL: https://issues.apache.org/jira/browse/CXF-7943 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.0 > Environment: CXF 3.2.0, JDK 1.8 >Reporter: Sean >Priority: Major > Attachments: fault_req_resp.xml, histogram.PNG, leak_suspect_1.PNG, > mapcodec_leak.png > > > When running load tests, my system begin to get memory leak after 4 hours or > so. When analyzing the heap dump using VisualVM (please see attachments), I > can see that a ConcurrentHashMap is taking up 1.7 GB of space in the heap, as > well as being the main "suspect" for this leak. This leads me to believe that > it is the uncorrelatedExchanges attribute since this map is being reference > from the MAPCodec class. > I believe that the map, in my case, for whatever reason, does not always > remove the Exchange after the synchronous request/responses are done, however > I could be wrong. > > IF this is indeed a bug, what could the cause of this be, as well as any work > around? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7943) MAPCodec: Memory leak due to growing uncorrelatedExchanges
[ https://issues.apache.org/jira/browse/CXF-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adolfo Volpe updated CXF-7943: -- Attachment: fault_req_resp.xml > MAPCodec: Memory leak due to growing uncorrelatedExchanges > -- > > Key: CXF-7943 > URL: https://issues.apache.org/jira/browse/CXF-7943 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.0 > Environment: CXF 3.2.0, JDK 1.8 >Reporter: Sean >Priority: Major > Attachments: fault_req_resp.xml, histogram.PNG, leak_suspect_1.PNG, > mapcodec_leak.png > > > When running load tests, my system begin to get memory leak after 4 hours or > so. When analyzing the heap dump using VisualVM (please see attachments), I > can see that a ConcurrentHashMap is taking up 1.7 GB of space in the heap, as > well as being the main "suspect" for this leak. This leads me to believe that > it is the uncorrelatedExchanges attribute since this map is being reference > from the MAPCodec class. > I believe that the map, in my case, for whatever reason, does not always > remove the Exchange after the synchronous request/responses are done, however > I could be wrong. > > IF this is indeed a bug, what could the cause of this be, as well as any work > around? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7943) MAPCodec: Memory leak due to growing uncorrelatedExchanges
[ https://issues.apache.org/jira/browse/CXF-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adolfo Volpe updated CXF-7943: -- Attachment: ok_req_resp.xml > MAPCodec: Memory leak due to growing uncorrelatedExchanges > -- > > Key: CXF-7943 > URL: https://issues.apache.org/jira/browse/CXF-7943 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.0 > Environment: CXF 3.2.0, JDK 1.8 >Reporter: Sean >Priority: Major > Attachments: fault_req_resp.xml, histogram.PNG, leak_suspect_1.PNG, > mapcodec_leak.png, ok_req_resp.xml > > > When running load tests, my system begin to get memory leak after 4 hours or > so. When analyzing the heap dump using VisualVM (please see attachments), I > can see that a ConcurrentHashMap is taking up 1.7 GB of space in the heap, as > well as being the main "suspect" for this leak. This leads me to believe that > it is the uncorrelatedExchanges attribute since this map is being reference > from the MAPCodec class. > I believe that the map, in my case, for whatever reason, does not always > remove the Exchange after the synchronous request/responses are done, however > I could be wrong. > > IF this is indeed a bug, what could the cause of this be, as well as any work > around? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7943) MAPCodec: Memory leak due to growing uncorrelatedExchanges
[ https://issues.apache.org/jira/browse/CXF-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adolfo Volpe updated CXF-7943: -- Attachment: mem_dump.png > MAPCodec: Memory leak due to growing uncorrelatedExchanges > -- > > Key: CXF-7943 > URL: https://issues.apache.org/jira/browse/CXF-7943 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.0 > Environment: CXF 3.2.0, JDK 1.8 >Reporter: Sean >Priority: Major > Attachments: fault_req_resp.xml, histogram.PNG, leak_suspect_1.PNG, > mapcodec_leak.png, mem_dump.png, ok_req_resp.xml > > > When running load tests, my system begin to get memory leak after 4 hours or > so. When analyzing the heap dump using VisualVM (please see attachments), I > can see that a ConcurrentHashMap is taking up 1.7 GB of space in the heap, as > well as being the main "suspect" for this leak. This leads me to believe that > it is the uncorrelatedExchanges attribute since this map is being reference > from the MAPCodec class. > I believe that the map, in my case, for whatever reason, does not always > remove the Exchange after the synchronous request/responses are done, however > I could be wrong. > > IF this is indeed a bug, what could the cause of this be, as well as any work > around? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CXF-7943) MAPCodec: Memory leak due to growing uncorrelatedExchanges
[ https://issues.apache.org/jira/browse/CXF-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751009#comment-16751009 ] Adolfo Volpe edited comment on CXF-7943 at 1/24/19 11:06 AM: - I think that the growth is caused by fault response received. Take a look at attachments. Today dump is growth to 1.5 Gb. was (Author: volpe): I think that the growth is caused by fault response received. Take a look at attachments. > MAPCodec: Memory leak due to growing uncorrelatedExchanges > -- > > Key: CXF-7943 > URL: https://issues.apache.org/jira/browse/CXF-7943 > Project: CXF > Issue Type: Bug >Affects Versions: 3.2.0 > Environment: CXF 3.2.0, JDK 1.8 >Reporter: Sean >Priority: Major > Attachments: fault_req_resp.xml, histogram.PNG, leak_suspect_1.PNG, > mapcodec_leak.png, mem_dump.png, ok_req_resp.xml > > > When running load tests, my system begin to get memory leak after 4 hours or > so. When analyzing the heap dump using VisualVM (please see attachments), I > can see that a ConcurrentHashMap is taking up 1.7 GB of space in the heap, as > well as being the main "suspect" for this leak. This leads me to believe that > it is the uncorrelatedExchanges attribute since this map is being reference > from the MAPCodec class. > I believe that the map, in my case, for whatever reason, does not always > remove the Exchange after the synchronous request/responses are done, however > I could be wrong. > > IF this is indeed a bug, what could the cause of this be, as well as any work > around? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-7941. > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Assignee: Colm O hEigeartaigh >Priority: Major > Attachments: cxf7941.zip, obsolete-code.txt, > request-real-sanitised.xml, request-test-broken-sanitised.xml, > request-test-working-sanitised.xml, stacktrace-request-test-broken.txt > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-7941. -- Resolution: Not A Problem > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Assignee: Colm O hEigeartaigh >Priority: Major > Attachments: cxf7941.zip, obsolete-code.txt, > request-real-sanitised.xml, request-test-broken-sanitised.xml, > request-test-working-sanitised.xml, stacktrace-request-test-broken.txt > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-7941: Assignee: Colm O hEigeartaigh > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Assignee: Colm O hEigeartaigh >Priority: Major > Attachments: cxf7941.zip, obsolete-code.txt, > request-real-sanitised.xml, request-test-broken-sanitised.xml, > request-test-working-sanitised.xml, stacktrace-request-test-broken.txt > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
