OOD 2.0.13 update_ood_portal and oidc configuration

Running OOD 2.0.13 on CentOS 7 with these /etc/ood/config/ood_portal.yml configs:
oidc_provider_metadata_url: https://auth.globus.org/.well-known/openid-configuration
oidc_client_id: <value_removed>
oidc_client_secret: <value_removed>

After running:
/opt/ood/ood-portal-generator/sbin/update_ood_portal -f

Looking at the resulting Apache configs:
grep '^\sOIDC’ /opt/rh/httpd24/root/etc/httpd/conf.d/.conf

does not show the configured oidc_* parameters in the Apache ood-portal.conf. It has other values like:
OIDCProviderMetadataURL https://ondemand.xsede.org:5554/.well-known/openid-configuration

I also noticed when I edit ood_portal.yml and run update_ood_portal it does not generate new configs always. Sometimes it does and sometimes it doesn’t.


Do you have ondemand-dex installed? It looks like it saw that it’s installed and defaulted to those configurations (or forced them as the case may be). If you have that installed - it will populate that stuff because we assume you’re using dex if you have it installed. Removing ondemand-dex through yum should resolve that.

This could also relate to your updates given we’re just ignoring some oidc configs since you have ondemand-dex installed.

Dex is installed but not configured: all the dex entries in ood_portal.yml are commented out, per this comment:

Dex configurations, values inside the “dex” structure are directly used to configure Dex

If the value for “dex” key is false or null, Dex support is disabled

Dex support will auto-enable if ondemand-dex package is installed

I guess the last two comments could be contradictory, and the second one takes precedence?

Oh, but dex is configured! I know you’re having trouble with this right here, but it’s actually a feature.

If you have ondemand-dex we’re going to automatically set a lot of OIDC configs to point to it (that’s what’s running, or would run on port 5554 - your OIDCProviderMetadataURL). We’re going to ignore settings like your oidc_provider_metadata_url because we auto setting it to dex.

All the items in the dex are extra settings you’d want (like different themes and so on).

We autopopulate these to get dex to work out of the box. Just on ondemand-dex's presence alone. Not on any setting - just the fact that /usr/bin/ondemand-dex exists, we’re going to configure ood that way.

Right, we will uninstall it. We left it installed because of this comment in the ood_portal.yml:

→ If the value for “dex” key is false or null, Dex support is disabled

Which would only make sense if it was installed in the first place. I suggest clarifying the comment.



Thanks and sorry for the headache. It looks like the comment may actually be right (or tries to be). It looks like if you set it to false it would work. There seems to be a bug around setting null (like you have) where the comment is right - we’re trying to support that - it’s just a bug that it doesn’t. I’m filing a ticket now to fix that.

dex: false

:man_facepalming: Sorry to continue the confusion. In making the ticket I found that the comment is actually correct.

You can disable dex through explicitly setting that key dex to null or false. Leaving it commented implicitly keeps it enabled. I think that it’s implicit tripped us both up.

So if you have ondemand-dex installed you have to explicitly disable it, just leaving it commented is not enough.

Uninstalling ondemand-dex fixed our problem. Thanks.