URL-based profile selection

Get Help
1

Hi! We want to setup multiple profiles to be used by different groups in our HPC clsuter.
The idea would be to have the main OOD instance at (example):

loginhost.domain.com

and the different profiles for the groups (group A, group B) based on the URL (example):

groupa.loginhost.domain.com → uses Group A profile
groupb.loginhost.domain.com → uses Group B profile

We setup some DNS so when accessing groupa.loginhost.domain.com or groupb.loginhost.domain.com it resolves the IP to loginhost.domain.com

The problem is that, having in the ood_portal.yml configuration something like:
servername: loginhost.domain.com

it seems OOD always redirects to this URL and doesn’t apply the group profile.

So I don’t get if the documentation suggests a profile configuration like:

profiles:
  www.production.com: &production_profile # Anchor definition
    config_property: config_value
    config_property: config_value
    config_property: config_value

  www.local.com: *production_profile # Defining an alias to the previously set anchor.
  www.test.com: *production_profile
  www.staging.com: *production_profile

just to be able to share the configuration file but to get a different profile you should use different OOD instances or I’m configuring it in the wrong way.

So I hope my need is clear: having different URLs resolving to the same OOD instance and select a profile based on the URL used.

Moreover, we also wanted to give the possibility to the users to select a different profile using the menu but I feel if you enable host_based_profiles this will be the only way the profile gets selected. Is it right?

2

In the meantime I tried to add:

server_aliases:
  - groupa.loginhost.domain.com

in ood_portal.yml but this didn’t help. OOD is still redirecting to servername

It looks I’m still missing some Apache Server setting to have it working

3

I’ll have to look into this a little bit more. The feature host_based_profiles is supposed to work as you indicate, with the configurations you’ve given.

Though I am now recalling something about YAML anchors in either the new Ruby version or Psych itself - I’d ask you to check your logs to see if those configuration files are being red correctly with anchors.

In any case, this was how this was supposed to work, but I don’t know if anyone’s actually used it in production yet. I’ll look into it more next week (I’m on vacation the rest of this week) and let you know.

4

I have the feeling the Apache server should not redirect the request to the URL configured in the servername. When this happens than the “profile” part will always see the same name and no possibility to have different profiles. So I’m looking at Apache configuration in the meantime.
Thanks for your help (and from anyone else which tried already this already)

5

Thinking about this a little more, this may be fixed in 3.1 with the patch Added support for multiple domains for Apache config in portal generator by abujeda · Pull Request #3264 · OSC/ondemand · GitHub

6

I updated the template ( I think the other file in the commit is just an examples so probably not needed).

Anyway, it still doesn’t work. I tried 2 cases.
Case 1.

servername: groupa.loginhost.domain.com

server_aliases:
  - loginhost.domain.com

only: groupa.loginhost.domain.com works.

when accessing loginhost.domain.com I get an error in the logs:

==> groupa.loginhost.domain.com_error_ssl.log <==
[Thu Feb 22 14:28:50.288083 2024] [auth_openidc:error] [pid 1503193:tid 140063950984960] [client 10.165.16.254:57001] oidc_authenticate_user: the URL hostname (groupa.loginhost.domain.com) of the configured OIDCRedirectURI does not match the URL hostname of the URL being accessed (loginhost.domain.com): the "state" and "session" cookies will not be shared between the two!

Case 2:

servername: loginhost.domain.com

server_aliases:
  - groupa.loginhost.domain.com

only: loginhost.domain.com works.

when accessing groupa.loginhost.domain.com I get an error in the logs:

==> loginhost.domain.com_error_ssl.log <==
[Thu Feb 22 14:25:24.976667 2024] [auth_openidc:warn] [pid 1502055:tid 140076591867648] [client 10.165.16.254:56164] oidc_clean_expired_state_cookies: state (mod_auth_openidc_state_21Yp4JHSV0VT0H5NkN2WZ69Vj0A) has expired (original_url=https://groupa.loginhost.domain.com/pun/sys/dashboard)
[Thu Feb 22 14:25:24.976723 2024] [auth_openidc:warn] [pid 1502055:tid 140076591867648] [client 10.165.16.254:56164] oidc_clean_expired_state_cookies: state (mod_auth_openidc_state_nCAgwmU4xf035aeRy4bPFIpI4T0) has expired (original_url=https://groupa.loginhost.domain.com/pun/sys/dashboard)

[Thu Feb 22 14:25:25.460778 2024] [auth_openidc:error] [pid 1502055:tid 140077371340544] [client 10.165.16.254:56114] oidc_restore_proto_state: no "mod_auth_openidc_state_BEfCxeJcR63kJtzqpu6f6TRoMH8" state cookie found
[Thu Feb 22 14:25:25.460817 2024] [auth_openidc:error] [pid 1502055:tid 140077371340544] [client 10.165.16.254:56114] oidc_unsolicited_proto_state: could not parse JWT from state: invalid unsolicited response: [src/jose.c:809: oidc_jwt_parse]: cjose_jws_import failed: invalid argument [file: jws.c, function: cjose_jws_import, line: 781]
[Thu Feb 22 14:25:25.460821 2024] [auth_openidc:error] [pid 1502055:tid 140077371340544] [client 10.165.16.254:56114] oidc_authorization_response_match_state: unable to restore state
[Thu Feb 22 14:25:25.460824 2024] [auth_openidc:error] [pid 1502055:tid 140077371340544] [client 10.165.16.254:56114] oidc_handle_authorization_response: invalid authorization response state and no default SSO URL is set, sending an error...

So, the only URL which works is the one configured as servername .

7

Have you tried the same on 3.1? As I say, this may have been patched since 3.0.

8

I copied the template from version 3.1 and it didn’t fix it. I will try again with version 3.1. Do you think you will be able to test the configuration on your side too?

The other question is what’s the right configuration, case 1 or case 2?

9

Just tried with version 3.1.1, same issue.

10

OK thanks. I’ll have to replicate on our systems which may take a bit to configure DNS and all that. When I figure it out, I’ll patch 3.1.

11

This issue could be related with the way the ood-portal-generator creates the OIDC configuration for the OIDCRedirectURI directive. It is currently being constructed with the value from servername.

I believe that mod_auth_openidc supports relative URLs.

@fenz a quick test you can do is to hot-fix the ood-portal.conf.erb template, the following line:

with:
OIDCRedirectURI <%= @oidc_uri %>

To see if that fixes the issue.

We use basic auth for authentication in our installation (and multiple domains work with the 3.1 fix in this context), so I was not able to reproduce. We are transitioning to OIDC and we use multiple domains, so we will have this problem soon enough.

12

Thanks for chiming in @abujeda!

I forgot about this actually - so I’ll create a ticket internally to set this up at OSC and debug it sometime this week.

13

I’m just circling back to this now. There are a few issues, but what @abujeda mentions is also correct. We’re building OIDCRedirectURI to have the full URI in it, when it should be relative. The patch/hack Aday suggests will get this working if your users always use the https url. if they use plain http they’ll be routed back to the default servername.

14

Sorry for getting back to you so late. I just had time to test it.
The changes proposed fix the issue, the host-based profile can now be used.
Thanks for your help!