OOD 1.8 and SAML2 and ADFS authentication

I am installed OOD 1.8.12 on CentOS 7.8 and configured it to authenticate using mod_auth_mellon using the provided instructions. https://osc.github.io/ood-documentation/latest/authentication/adfs-with-auth-mellon.html. I am getting an error when I try to authenticate that the post URL does not exist. The ADFS authentication appears to be successful. I am wondering if I missed something on the OOD side. I get a 404 error with this request https://xxxx.xxx.xxx.org/mellon/metadata/postResponse.

The apache log provides this information.

Endpoint “metadata/ls” not handled by mod_auth_mellon.
[Mon Sep 28 11:05:19.781119 2020] [auth_mellon:error] [pid 143499] [client x.x.x.x:56253] Endpoint “metadata/postResponse” not handled by mod_auth_mellon.


MellonCacheSize 100
MellonLockFile “/run/httpd24-mod_auth_mellon/lock”

MellonSPPrivateKeyFile /opt/rh/httpd24/root/etc/httpd/mellon/mellon.key
MellonSPCertFile /opt/rh/httpd24/root/etc/httpd/mellon/mellon.cert
MellonSPMetadataFile /opt/rh/httpd24/root/etc/httpd/mellon/mellon_metadata.xml
MellonIdPMetadataFile /opt/rh/httpd24/root/etc/httpd/mellon/idpmetadata.xml

MellonEndpointPath /mellon
MellonEnable “auth”

My guess is mod_auth_mellon is not configured correctly but I am not sure where to start to debug this. What should apache return for /mellon/metadata/ls and /mellon/metadata/postResponse? Any help is greatly appreciated.


Hey, I’m so sorry for the delay. @tdockendorf do you have any experience with this? I’d guess setting that module’s log level to debug or trace is a good place to start if you haven’t already.

I’ve never used mod_auth_mellon, so I am not sure what could be wrong. That particular documentation was a community contribution I believe, not something I was involved with.

I’m also getting same error. Nothing useful in debug logs.

Is there any update on this? we’re currently struck at this step with our OOD implementation.

ls seems to be a mellon api. from the docs it was #1 in pre-requisites, “The SAML 2.0 service URL”.

In any case, here are my thoughts on next steps:

  • the docs also indicate to wrap the entires in auth_mellon.conf in a <Location> block. I can’t say this is the issue, but I’d like to rule it out one way or another. OIDC adds a new location, so maybe this is important as /mellon really isn’t found or isn’t understood.
  <Location "/oidc">
    AuthType openid-connect
    Require valid-user
  • turn debug logs on with LogLevel auth_mellon_module:debug (that may or may not be the right module name).
  • I could only find this related auth mellon issue where the user had a directory in /var/www. Mabye that’s a part of the mod_auth_mellon install? I can’t say - but I’d look for that directory.
  • OIDC requires and adds a new location

I think I found the issue, testing now.

The instructions for generating metadata mentioned in SAML Authentication with Active Directory Federated Services (ADFS) and mod_auth_mellon — Open OnDemand 1.8.12 documentation are wrong.

I think Actual command for metadata generation should be the following (swap ARG1 <-> ARG2)
/usr/libexec/mod_auth_mellon/mellon_create_metadata.sh “{mellon_endpoint}/metadata" "{mellon_endpoint}”

1 Like

Thanks! from these mellon docs it looks like you’re right. Let me know what happens and I’ll update our docs for the same.

Hi @jeff.ohrstrom,

Took really long time than expected, but I can confirm that creating metadata after swapping both ARG is working.

From my experience, most users would need this workaround as most ADFS systems return Attributes like “sAMaccountName” which is case-insensitive where as unix won’t like it.
Perhaps adding a section in the page with above info might help others.

Initially I configured SSSD to be case-insensitive, which didn’t work all the way (logs suggest my login was successful) because nginx failed to get lock on socket which is expected because PUN is started as REMOTE_USER.