Bug 1447770

[root@sp1 conf.d]# cat testapp_mellon_keycloak_test_realm.conf 
<Location /mellon_root>
    MellonEnable info
    MellonEndpointPath /mellon_root/mellon/
    MellonSPMetadataFile /etc/httpd/saml2/testapp_sp_metadata.xml
    MellonSPPrivateKeyFile /etc/httpd/saml2/testapp.key
    MellonSPCertFile /etc/httpd/saml2/testapp.cert
    MellonIdPMetadataFile /etc/httpd/saml2/testapp_keycloak_test_realm_idp_metadata.xml
    MellonIdP IDP
    MellonMergeEnvVars On ";"
</Location>

<Location /private>
    AuthType Mellon
    MellonEnable auth
    Require valid-user
</Location>

===================================================================

[root@sp1 conf.d]# cat /etc/httpd/saml2/testapp_keycloak_test_realm_idp_metadata.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
  ~ Copyright 2016 Red Hat, Inc. and/or its affiliates
  ~ and other contributors as indicated by the @author tags.
  ~
  ~ Licensed under the Apache License, Version 2.0 (the "License");
  ~ you may not use this file except in compliance with the License.
  ~ You may obtain a copy of the License at
  ~
  ~ http://www.apache.org/licenses/LICENSE-2.0
  ~
  ~ Unless required by applicable law or agreed to in writing, software
  ~ distributed under the License is distributed on an "AS IS" BASIS,
  ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  ~ See the License for the specific language governing permissions and
  ~ limitations under the License.
  -->

<EntitiesDescriptor Name="urn:keycloak" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
					xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
	<EntityDescriptor entityID="https://idp.keycloak.test:8443/auth/realms/test_realm">
		<IDPSSODescriptor WantAuthnRequestsSigned="true"
			protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
                        <KeyDescriptor use="signing">
                          <dsig:KeyInfo>
                            <dsig:KeyName>rnXIknR-5n2yyCRyp6DlUjAGaSSSvjXppnHM9CF7TI8</dsig:KeyName>
                            <dsig:X509Data>
                              <dsig:X509Certificate>MIICozCCAYsCBgFbz35pVjANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDDAp0ZXN0X3JlYWxtMB4XDTE3MDUwMzE4MDUxOVoXDTI3MDUwMzE4MDY1OVowFTETMBEGA1UEAwwKdGVzdF9yZWFsbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMMQvoJNVAyYJaVoUiAHVPFUiPJsjirPDlskLdDceDEG73iRWgy4fKfivpR/W4215rK4c6kpN2LUZkIUYG7620EMOybIp88jway75kCSm4PiEOtx+tb1WWMshPQHq1Xf9z00xBMO08Kem5O5Z7xc9dzConmj6p6Hst6Cvzns+n61IfXrNFf5QrA242fuiL3iP9pjYfSNfeVlbj4hskaYpDwduvoIKaqXRSbv+LJza0N4xSmVzi6r31l/Piqep6oQ0Gjh+uFFwAGFo5d+nfa/Wh9Qa43MuYu/WcGYjVTn3F/hiikdWqCJZfeFlVAMBX0kqGOKOPsdI9KtfDK/yFbP9g0CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEArEwB6sGNeKzl+2Gvccic0LIhsjptD9QIMliZCG9JSGCvFSYkcVcXTXhOb7AwM+CbJKonDZ8xyuVtATEZcId+jMfoPQtBBXzYxLD6ltg08j7Gn4NPBNpul5dl/wEdcl/2mDrJ3SHLLqXLIbE6nYqiM2c4bnt9Oh1g9TQw1lhGmFrODUJna1EJj04rXYcDCTGVGLQWRmdYzRyIZ3dHvWlX+YMpkrbT7qif1TACwZboWEDg6YeYjbqYKFfPJY/ESj3IIQuc7MtX3Fwju6Cr9GepkoswVp4Gwwdk+wF085Zwcow1k4pmnILLbdal3re3T45NTudEUyz42O7oXsqzfmymnQ==</dsig:X509Certificate>
                            </dsig:X509Data>
                          </dsig:KeyInfo>
                        </KeyDescriptor>

			<SingleLogoutService
					Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
					Location="https://idp.keycloak.test:8443/auth/realms/test_realm/protocol/saml" />
			<SingleLogoutService
					Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
					Location="https://idp.keycloak.test:8443/auth/realms/test_realm/protocol/saml" />
			<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
			<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
			<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
			<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
			<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
				Location="https://idp.keycloak.test:8443/auth/realms/test_realm/protocol/saml" />
			<SingleSignOnService
				Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
				Location="https://idp.keycloak.test:8443/auth/realms/test_realm/protocol/saml" />
			<SingleSignOnService
				Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
				Location="https://idp.keycloak.test:8443/auth/realms/test_realm/protocol/saml" />
		</IDPSSODescriptor>
	</EntityDescriptor>
</EntitiesDescriptor>

[root@sp1 ~]# keycloak-httpd-client-install   \
>     --client-originate-method registration \
>     --keycloak-server-url https://idp.keycloak.test:8443 \
>     --keycloak-admin-username admin \
>     --keycloak-admin-password Secret1230 \
>     --app-name testapp \
>     --keycloak-realm test_realm \
>     --mellon-protected-locations "/private" \
>     --mellon-root mellon_root \
>     --force
[Step  1] Connect to Keycloak Server
/usr/lib/python2.7/site-packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName`, falling back to check for a `commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.)
  SecurityWarning
[Step  2] Create Directories
[Step  3] Set up template environment
[Step  4] Set up Service Provider X509 Certificiates
[Step  5] Build Mellon httpd config file
[Step  6] Build Mellon SP metadata file
[Step  7] Query realms from Keycloak server
[Step  8] Use existing realm on Keycloak server
[Step  9] Query realm clients from Keycloak server
[Step 10] Get new initial access token
[Step 11] Creating new client using registration service
[Step 12] Enable saml.force.post.binding
[Step 13] Add group attribute mapper to client
[Step 14] Add Redirect URIs to client
[Step 15] Retrieve IdP metadata from Keycloak server
[Step 16] Completed Successfully

please attach the IdP metadata file as an attachment. I can't test reliably if I'm not loading the exact same file.

In the past one cause has been the inability of Apache to read the file. Is SELinux enabled? Did you get an AVC denial? How about permissions on the directory and file?

Created attachment 1275970 [details]
idp metadata file from rhsso 7.1

Created attachment 1275971 [details]
mellon config file generated by keycloak-httpd-client-install

Also hit the same issue:
lasso-2.5.1-2.el7.x86_64
httpd-2.4.6-45.el7_3.4.x86_64
mod_auth_mellon-0.11.0-2.el7.x86_64

Unable to get mellon to accept any IDP metadata, although it is clearly reading and parsing the XML file.  (edits to the file to produce invalid xml or to add unsupported tags do generate different error messages in the apache logs.)

Even tried the example IDP metadata from https://jdennis.fedorapeople.org/doc/mellon-install/mellon-install-guide.html, which presumably worked at one point

Re comment #8, using the exact same RPM versions I'm unable to reproduce the problem.

The original bug report should have been closed because it was an SELinux denial that was causing the problem.

Is SELinux enabled? (what does getenforce return?)

In what directory are you storing the metadata?

What is the SELinux label on the directory containing the metadata and the metadata file? (e.g. ls -lZ xxx)

Does the problem go away if you disable SELinux (e.g. setenforce 0) and restart httpd?

Still having problems?

Then please enable debug logging in /etc/http/conf/httpd.conf by changing the LogLevel to debug. Then restart the server and trying again. Look for any lines with "mellon" in the name. Anything interesting?

Still stuck?

Attach the log file and the IdP metadata.

Scott, what did you do to resolve the SELinux issue?

John,

I'm sorry, I think there was a misunderstanding.  The SELinux issue I resolved was something with bug #1414021.  If I recall that was an issue with file context on the IDP Metadata file I had copied in manually from this bug to be able to verify that one.  I don't think I ever got a completely configured mellon client using the installer.

I ran a test again and I am seeing the same thing:

/var/log/httpd/ssl_error_log:[Tue May 16 21:19:29.064061 2017] [:error] [pid 16763] [client 192.168.122.192:38670] Error adding IdP to lasso server object. Please verify the following configuration directives: MellonIdPMetadataFile and MellonIdPPublicKeyFile.

[root@sp1 ~]# egrep "MellonIdPMetadataFile|MellonIdPPublicKeyFile" /etc/httpd/conf.d/*
/etc/httpd/conf.d/testapp_mellon_keycloak_test_realm.conf:    MellonIdPMetadataFile /etc/httpd/saml2/testapp_keycloak_test_realm_idp_metadata.xml
/etc/httpd/conf.d/testapp_mellon_keycloak_test_realm.conf.orig:    MellonIdPMetadataFile /etc/httpd/saml2/testapp_keycloak_test_realm_idp_metadata.xml

[root@sp1 ~]# ls -lZ /etc/httpd/saml2/testapp_keycloak_test_realm_idp_metadata.xml
-rw-r--r--. root root unconfined_u:object_r:httpd_config_t:s0 /etc/httpd/saml2/testapp_keycloak_test_realm_idp_metadata.xml

[root@sp1 ~]# ls -ldZ /etc/httpd/saml2/
drwxr-xr-x. root root unconfined_u:object_r:httpd_config_t:s0 /etc/httpd/saml2/

Well, I'm baffled at the moment, I just tried loading the testapp_keycloak_test_realm_idp_metadata.xml file you attached to this bug report and it loads just fine. Here is the entry in my ssl_error_log file:

loaded IdP "https://idp.keycloak.test:8443/auth/realms/test_realm" from "/etc/httpd/saml2/testapp_keycloak_test_realm_idp_meta\
data.xml".

I can think of 2 other things to try:

Run apache under strace, I usually do like this:

strace -f -o /tmp/strace.log /usr/sbin/httpd

Then look at the /tmp/strace.log file and search for the open of the testapp_keycloak_test_realm_idp_metadata.xml file and see if there are any errors opening it. The log should show the first 32 bytes of the file as it's being read. Were there any errors opening and reading the file?

Also please verify you do not have an other config files that might have a MellonIdPMetadataFile directive in it. Unfortunately the error message does not indicate the filename of the failed IdP metadata file.

The other option is give me access to the machine and let me poke around.

I found your problem, it's a configuration problem, I should have seen this earlier but missed it myself.

You've got all your mellon config under the location /mellon_root but your
protected location is the location /private.

These two locations are siblings, thus /private cannot inherit the mellon config
from /mellon_root hence you're not loading any metadata or any other mellon
config for that matter when the /private location is hit. Unfortunately the error message is cryptic, something I'll fix in mellon soon.

Locating all your mellon config up at the root is a good strategy, that way any protected area *below* it can inherit from the ancestors above it. This provides a way to avoid duplicating the mellon config information more than once which is error prone. But for this strategy to work the locations protected by mellon *must* be descendants of the location where the "root" or "global" mellon config is located.

That was it.  Fixed my issue.

[root@sp1 ~]# sh -x run 
+ keycloak-httpd-client-install --client-originate-method registration --keycloak-server-url https://idp.keycloak.test:8443 --keycloak-admin-username admin --keycloak-admin-password Secret1230 --app-name testapp --keycloak-realm test_realm --mellon-protected-locations /private --mellon-root / --force

[Step  1] Connect to Keycloak Server
/usr/lib/python2.7/site-packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName`, falling back to check for a `commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.)
  SecurityWarning
[Step  2] Create Directories
[Step  3] Set up template environment
[Step  4] Set up Service Provider X509 Certificiates
[Step  5] Build Mellon httpd config file
[Step  6] Build Mellon SP metadata file
[Step  7] Query realms from Keycloak server
[Step  8] Use existing realm on Keycloak server
[Step  9] Query realm clients from Keycloak server
[Step 10] Get new initial access token
[Step 11] Creating new client using registration service
[Step 12] Enable saml.force.post.binding
[Step 13] Add group attribute mapper to client
[Step 14] Add Redirect URIs to client
[Step 15] Retrieve IdP metadata from Keycloak server
[Step 16] Completed Successfully

And to make it more legible:

[root@sp1 ~]# cat run 
keycloak-httpd-client-install   \
    --client-originate-method registration \
    --keycloak-server-url https://idp.keycloak.test:8443 \
    --keycloak-admin-username admin \
    --keycloak-admin-password Secret1230 \
    --app-name testapp \
    --keycloak-realm test_realm \
    --mellon-protected-locations "/private" \
    --mellon-root "/" \
    --force


All I changed was --mellon-root to "/".

After that, I'm now getting a proper login page when I access the /private url.

John Wade,

Can you confirm if this resolves your issue as well?  And that you're seeing the same failure in the logs?

If this fixes your issue as well, I'm going to close this bug.

Thanks,
Scott

John Wade,

FYI, I'm closing out this bug as NOTABUG since it was a configuration issue.  If this configuration change does not resolve your issue and this appears to still be affecting you, you can reopen this bug.

Regards,
Scott

It was a configuration issue, sorry for the delay.  Should have been closed as you did  NOTABUG

Hi John,  No problem on the delay.  Thanks for letting us know.