module does not handle multiple provider sessions

[bertramn]

We configured the mod_auth_openidc module as per wiki entry https://github.com/pingidentity/mod_auth_openidc/wiki/Authorization#access-to-different-url-paths-on-a-per-provider-basis for 2 separate locations and respective identity provider.

But when we setup 2 locations and 2 separate identity providers the module does not consider that a "different" session is needed when altering the browser URL from location 1 to location 2. The module lets the identity authenticated in location 1 just pass to location 2 but the required issuer is not checked. If the Require rules are different (e.g. IdP1 has different groups than IdP2) the module just fails with a 401 instead of going off and authenticating the user agent against the identity provider configured for location 2.

That does not look very healthy. Any idea or examples that show how 2 sessions can co-exist in the same browser against the same base url/vhost?

[zandbelt]

When you say "the required issuer is not checked" do you mean that you actually get access to to location 2? The expected behavior is that access is rejected, is that not happening for you?

Redirecting to IDP2 would required changes that are more fundamental and would be a feature request, at this point I just want to verify that the module works correctly security-wise.

[bertramn]

Yes correct a subject authenticated for location 1 through identify provider 1 is just let through to browse location 2 that is protected by a different identity provider and technically the subject from idp1 is not a valid user at location 2. I can also see that the headers send through to location 2 are in fact for the subject identified against idp1.

I will try to make a very wery simple example but effectively I set up a reverse proxy and want to protect 2 separate locations with 2 completely separate identity providers on the same vhost.

I could separate the 2 locations into separate vhost but I am a bit worried that this "mod openidc session" is global to the httpd process.

[bertramn]

I was just reading through issue #13 and tried to restructure my protected paths and set a different OIDCCookiePath in each location to restrict the user agent sending the session cookie mod_auth_openidc_session for the wrong location but the problem I ran into was that I can only configure a single OIDCRedirectURI per vhost.

Here the configuration I was hoping would work. Basically configuring 2 completely independent root locations and then explicitely use 2 different OIDCRedirectURI's within each location and also set the cookie to be restricted to this location.

## 2 apps that need auth from different identity providers

## one in sub path /v
ProxyPass /v/app/ ajp://localhost:8009/app1/
ProxyPassReverse /v/app/ ajp://localhost:8009/app1/

## the other one in sub path /e
ProxyPass /e/app/ ajp://localhost:8009/app2/
ProxyPassReverse /e/app/ ajp://localhost:8009/app2/

## configure openidc mod

# both identity providers configured as per wiki and independently verified, as in: 
# clear browser cache/history/cookies then test redirect to each respective identity provider
OIDCMetadataDir /var/cache/mod_auth_openidc/metadata
OIDCCryptoPassphrase supersecret

## protect path /v
Alias /v/oidc /data/www/htdocs/oidc
<Location "/v">
  OIDCDiscoverURL https://localhost/v/oidc/redirect_uri?iss=identityprovider1
  OIDCRedirectURI https://localhost/v/oidc/redirect_uri
  OIDCCookiePath /v/
  AuthType openid-connect
  Require valid-user
</Location>

## protect path /e
Alias /e/oidc /data/www/htdocs/oidc
<Location "/e">
  OIDCDiscoverURL https://localhost/e/oidc/redirect_uri?iss=identityprovider2
  OIDCRedirectURI https://localhost/e/oidc/redirect_uri
  OIDCCookiePath /e/
  AuthType openid-connect
  Require valid-user
</Location>

Unfortunately that does not work as OIDCRedirectURI is not allowed inside the Location directive and this path can also not be configured in the [issuer].client file in the metadata directory for this specific relying party.

So when trying this another way around I basically get an infinite loop because the cookie location is set to /oidc and not /v or /e because the redirect_uri is at the wrong level. If I remove OIDCCookiePath then I am back at the original issue 🎱 ...

## 2 apps that need auth from different identity providers

## one in sub path /v
ProxyPass /v/app/ ajp://localhost:8009/app1/
ProxyPassReverse /v/app/ ajp://localhost:8009/app1/

## the other one in sub path /e
ProxyPass /e/app/ ajp://localhost:8009/app2/
ProxyPassReverse /e/app/ ajp://localhost:8009/app2/

## configure openidc mod

# both identity providers configured as per wiki and independently verified, as in: 
# clear browser cache/history/cookies then test redirect to each respective identity provider
OIDCMetadataDir /var/cache/mod_auth_openidc/metadata
OIDCCryptoPassphrase supersecret

Alias /oidc /data/www/htdocs/oidc
OIDCRedirectURI https://localhost/oidc/redirect_uri

## protect path /v
<Location "/v">
  OIDCDiscoverURL https://localhost/oidc/redirect_uri?iss=identityprovider1
  OIDCCookiePath /v/
  AuthType openid-connect
  Require valid-user
</Location>

## protect path /e
<Location "/e">
  OIDCDiscoverURL https://localhost/oidc/redirect_uri?iss=identityprovider2
  OIDCCookiePath /e/
  AuthType openid-connect
  Require valid-user
</Location>

[zandbelt]

You're not using the Require claim iss: identityprovider1 on the /v path nor the Require claim iss: identityprovider2 on the /e path. As suggested in https://github.com/pingidentity/mod_auth_openidc/wiki/Authorization#access-to-different-url-paths-on-a-per-provider-basis those statements are required to protect the content, the OIDCDiscoverURL is merely to by-pass the OP Discovery phase.

I've verified that this actually produces the expected behavior such that the content is only accessible by users that have authenticated with the right OP. Unfortunately it needs a patch because currently it only works if iss is returned from the user info endpoint or when there is no user info endpoint and only claims from the id_token are used. I will commit that patch separately.

To actually support simultaneous sessions, something like you suggest would be required, i.e. OIDRedirectURI and OIDCCookiePath tuples would have to be configured on a path level. That requires more work later.

[bertramn]

I updated my example with the issuer claim check but now when I start with a clean browser and go to either location I get the correct login prompt but the final redirect to the protected resource (apache Require check) fails with 401 in both locations. I also dumped the headers on server behind mod_auth_openidc after disabling the Require claim iss:bla directive and I can see the OIDC_CLAIM_iss claim being dumped out exactly as entered in the Require directive. This battle looks like a lost one, what a shame.

Do you know if the "mod_auth_openidc_session" is local to the vhost or apache global? I'd hate to setup 2 separate vhosts and have the same issues again running it in one httpd process.

Updated configuration as per wiki, which is now giving a 401 in both locations:

## 2 apps that need auth from different identity providers

## one in sub path /v
ProxyPass /v/app/ ajp://localhost:8009/app1/
ProxyPassReverse /v/app/ ajp://localhost:8009/app1/

## the other one in sub path /e
ProxyPass /e/app/ ajp://localhost:8009/app2/
ProxyPassReverse /e/app/ ajp://localhost:8009/app2/

## configure openidc mod

# both identity providers configured as per wiki and independently verified, as in: 
# clear browser cache/history/cookies then test redirect to each respective identity provider
OIDCMetadataDir /var/cache/mod_auth_openidc/metadata
OIDCCryptoPassphrase supersecret

Alias /oidc /data/www/htdocs/oidc
OIDCRedirectURI https://localhost/oidc/redirect_uri

## protect path /v
<Location "/v">
  OIDCDiscoverURL https://localhost/oidc/redirect_uri?iss=identityprovider1
  AuthType openid-connect
  Require claim iss:identityprovider1
</Location>

## protect path /e
<Location "/e">
  OIDCDiscoverURL https://localhost/oidc/redirect_uri?iss=identityprovider2
  AuthType openid-connect
  Require claim iss:identityprovider2
</Location>

[zandbelt]

yes, as noted in my previous answer: it needs a patch if the identity provider has a separate user info endpoint and that endpoint does not return an "iss" claim; the "iss" claim in the id_token is not considered when there are claims from a user info endpoint: that is added in 50ac4ec