[
https://issues.apache.org/jira/browse/CXF-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15703316#comment-15703316
]
PHILIP commented on CXF-7039:
-----------------------------
We encountered this issue during deployment of our application and found this
fix. In our case the addresses differ in that the protocol changes depeding on
if the reverse proxy is between insecure and secure zones (http vs https
respectively).
An outstanding question regarding this fix is how it fundamentally changes the
validation which occurs when the pre-configured value is used versus the
message's actual destination.
Can you provide an explanation addressing how both approaches are compliant
with the SAML protocol?
Thank you.
> JAX-RS Security SAML web SSO consumer service can not validate SAML response
> behind reverse proxy
> -------------------------------------------------------------------------------------------------
>
> Key: CXF-7039
> URL: https://issues.apache.org/jira/browse/CXF-7039
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
> Affects Versions: 3.0.9
> Environment: JRE 1.8.0_101-b13
> Reporter: Michal Sabo
> Assignee: Colm O hEigeartaigh
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
>
> During the SAML web SSO processing, the RequestAssertionConsumerService
> validates the request with the
> org.apache.cxf.rs.security.saml.sso.SAMLSSOResponseValidator using a wrong
> assertionConsumerURL.
> The SAML request (org.opensaml.saml2.core.AuthnRequest) is configured with
> the serviceURL taken as the
> org.apache.cxf.rs.security.saml.sso.AbstractServiceProviderFilter.assertionConsumerServiceAddress
> property, however the
> org.apache.cxf.rs.security.saml.sso.SAMLSSOResponseValidator is bootstrapped
> with the following consumer URL:
> ssoResponseValidator.setAssertionConsumerURL(messageContext.getUriInfo().getAbsolutePath().toString());
> This particularly makes a problem when serving the application behind a
> reverse proxy since the absolutePath taken from messageVontext's uriInfo is
> different than the configured one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
