Authenticate with mod_auth_openidc and bearer token


Our team uses an OOD deployment (v1.8.20) that works behind Apache with mod_auth_openidc (GitHub - zmartzone/mod_auth_openidc: OpenID Certified™ OpenID Connect Relying Party implementation for Apache HTTP Server 2.x). We use Keycloak as our authentication server.

In one of our apps we would like to use impersonation features available in OOD that would allow us to browse exposed filesystem as a logged-in user.

To do this, we authenticate in a separate client app and obtain an access token from Keycloak. Then we would like to pass this token to OOD directly (actually to mod_auth_openidc that’s in front of it) to access the resources.

After following instructions on OAuth 2.0 Resource Server · zmartzone/mod_auth_openidc Wiki · GitHub we put this configuration to OOD config file:

<Location /pun/sys/files/api/>
   AuthType oauth20
   Require valid-user

However, HTTP requests with headers:

GET (...)/pun/sys/files/api/v1/fs/gpfs/data/

Accept: application/json
Authorization: Bearer <TOKEN>

don’t seem to work and a 401 Unauthorized is returned.

Is it possible to access OOD API with mod_auth_openidc with bearer tokens? Is there any recommended path to access these resources?

Thank you for any information and/or hints.

Hello and welcome!

The immediate problem that jumps out is that you are passing the token to the auth header. But, mod_auth_openidc is in the cookie and what OOD is checking. Beyond that I’m not sure how to get this setup correctly though.

There’s a stackoverflow topic that might help here: apache - cURL authentication with mod_auth_openidc and keycloak - Stack Overflow

@tdockendorf do you have any insight into how this can work with mod_auth_openidc?

See here for details: OAuth 2.0 Resource Server · zmartzone/mod_auth_openidc Wiki · GitHub. I’ve never uses AuthType oauth2 so no experience on what’s required.

More specifically, here: OAuth 2.0 Resource Server · zmartzone/mod_auth_openidc Wiki · GitHub

For completeness, the solution of using OAuth 2.0 Resource Server suggested by @tdockendorf worked and we were able to call the API just by providing an access_token as Bearer.

(!) The only problem is that after enabling it, the ondemand web file browser does not work anymore (it gives permission errors, not a surprise)

Anyway if someone is interested, this is how we configured using openondemand 1.8 and mod_auth_openidc 2.4.4:

Edit /opt/ood/ood-portal-generator/templates/ood-portal.conf.erb and add:

<Location "/pun/sys/files/api/">
  AuthType oauth20
  Require valid-user

And then edit /etc/ood/config/ood_portal.yml and add:

  OIDCOAuthRemoteUserClaim: preferred_username # replace by the claim you use to store the username
  OIDCOAuthVerifyJwksUri: https://yourkeycloak.server/auth/realms/<realm>/protocol/openid-connect/certs
  OIDCIDTokenIatSlack: 3600

Note that we went for locally validated tokens instead of introspecting them since the latter did not work because of the key size being too large: Inconsistent behavior with OAuth2 login · Issue #388 · zmartzone/mod_auth_openidc · GitHub

Finally exec:

/opt/ood/ood-portal-generator/bin/generate -o /opt/rh/httpd24/root/etc/httpd/conf.d/ood-portal.conf

Don’t forget to restart apache so the changes are applied.


If you are using puppet module:

Add a file_line resource to the class you are using the module from:

$oauth_line = "  <Location \"/pun/sys/files/api/\">\n    AuthType oauth20\n    Require valid-user\n  </Location>"
file_line { '/opt/ood/ood-portal-generator/templates/ood-portal.conf.erb':
  path    => '/opt/ood/ood-portal-generator/templates/ood-portal.conf.erb',
  line    => $oauth_line,
  match   => '.*/pun/sys/files/api/.*',
  after   => '</Location>',
  replace => false,
  notify  => Exec['ood-portal-generator-generate'],

And add the new variables to your hiera yaml files:

  OIDCOAuthRemoteUserClaim: preferred_username
  OIDCOAuthVerifyJwksUri: https://yourkeycloak.server/auth/realms/<realm>/protocol/openid-connect/certs
  OIDCIDTokenIatSlack: 3600

Puppet should take care of everything in the next run.

We can close this topic.

Thanks for all your help,

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.