Bug 1576719 - ECP flow not triggering, instead client access secured resources without ECP authentication
Summary: ECP flow not triggering, instead client access secured resources without ECP ...
Keywords:
Status: CLOSED DUPLICATE of bug 1691126
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mod_auth_mellon
Version: 7.7
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: John Dennis
QA Contact: Scott Poore
URL:
Whiteboard:
Depends On:
Blocks: 1687978
TreeView+ depends on / blocked
 
Reported: 2018-05-10 08:59 UTC by bmesegue
Modified: 2019-05-02 13:40 UTC (History)
6 users (show)

Fixed In Version: mod_auth_mellon-0.14.0-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1687978 (view as bug list)
Environment:
Last Closed: 2019-05-02 13:40:21 UTC
Target Upstream Version:


Attachments (Terms of Use)
TAR file including resources to reproduce issue (69.50 KB, application/x-tar)
2018-05-10 08:59 UTC, bmesegue
no flags Details

Description bmesegue 2018-05-10 08:59:25 UTC
Created attachment 1434274 [details]
TAR file including resources to reproduce issue

Description of problem:
The problem observed is that the ECP flow does not trigger and the call goes through giving the client access to the service without undergoing authentication.

Version-Release number of selected component (if applicable):
0.11.0 and 0.13.1

How reproducible:
Instructions attached in TAR file (how-to-reproduce.txt)

Steps to Reproduce:
Read instructions on how to reproduce:
 > how-to-reproduce.txt (attached in TAR file)

Actual results:
The problem observed is that the ECP flow does not trigger and the call goes through giving the client access to the service without undergoing authentication.

Expected results:
The expected result would be to obtain a PAOS request from the HTTPD server redirecting the client to the SSO instance to get authenticated.

Additional info:
The same test has been run using versions of 'mod_auth_mellow' 0.11.0 and 0.13.1 using respectively CentOS-7 and Fedora-26 base images.

With close inspections to the HTTPD log files it appears the mod_auth_module identifies the request as an ECP one, then passes the request to the main handler but then it is not getting the expected callback from the main handler.

A diagnostics file has been collected and attached to the case, please find it enclosed as:
 - mellon_diagnostics

Comment 2 John Dennis 2018-11-16 18:43:42 UTC
In reviewing this I think there may be some confusion over how the ECP flow works. In the how-to-reproduce.txt document in the attachment is this statement:

The ECP flow to be tested looks as follows:

	client --> HTTPD(mellon) --> service

But that is not how the SAML ECP flow works. There needs to an intermediary called the ECP client which participates in the flow. Refer to page 14 in this document:

https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

If mellon is operating correctly it should respond with a 200 status, content-type of text/xml and the AuthnRequest in the body. The diagnostics shows it's responding with content-type of text/xml as would be expected. This seems to suggest mellon is operating as expected.

The receiver of the response is supposed to participate in the ECP flow by forwarding the AuthRequest it received in the response to the IdP. ECP cannot be done with a single curl request as it appears from the expectation in your document.

It would be very helpful to know what the body of the response was you got from melllon, it should have been an AuthnRequest but you don't indicate what you actually got back. What did you get back?

Comment 3 bmesegue 2018-11-16 19:24:37 UTC
Hi John,

I hope I understood your comments.

The curl command mimics/simulates the ECP client. Mellon should respond with the AuthRequest, but it doesn't, that is the problem, the request goes through as if there was no validation to do, it reaches the backend service.

You would need to follow the instructions to reproduce the problem to see by yourself the issue.


Note You need to log in before you can comment on or make changes to this bug.