RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
Embargoed:

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
View All

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.