Reverse proxy

[tinova]

Description

Include support for SAML as auth backend:

https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

Use case

User management with SAML based products.

Progress Status

• [ ] Branch created
• [ ] Code committed to development branch
• [ ] Testing - QA
• [ ] Documentation
• [ ] Release notes - resolved issues, compatibility, known issues
• [ ] Code committed to upstream release/hotfix branches
• [ ] Documentation committed to upstream release/hotfix branches

[tinova]

Reference: #620

[terafirmanz]

Just adding my formal vote for this. These days it is imperative modern apps support SSO using SAML or even better OpenID Connect.

[kvaps]

@terafirmanz I had success with configuring OpenID Connect and OpenNebula, it was required just a little change in sunstone #3592

[tipirk]

@kvaps hi Can you share how you did it?

[kvaps]

Hey @tipirk just enable remote authentication method for sunstone:

https://github.com/OpenNebula/one/blob/213dada892dccda573d66a02cca2e299a879d80e/src/sunstone/etc/sunstone-server.conf#L81-L89

make it listen 127.0.0.1 only:

https://github.com/OpenNebula/one/blob/213dada892dccda573d66a02cca2e299a879d80e/src/sunstone/etc/sunstone-server.conf#L30-L33

then run keycloak-gatekeeper auth-proxy in front of sunstone.

I have configuration like this:

listen: 0.0.0.0:80
redirection-url: http://opennebula.example.org
secure-cookie: false
#listen: 127.0.0.1:8080
#redirection-url: https://opennebula.example.org
discovery-url: https://keycloak.example.org/auth/realms/opennebula
client-id: opennebula
client-secret: 4830a502-ac61-4a83-b198-adc0690db15c
enable-refresh-tokens: true
encryption-key: ve8aiSa0aeB8ya5ni1auluay2ohp7ocu
upstream-url: http://127.0.0.1:9869/
resources: 
- uri: /*

Note you can use any Oauth2 provider with keycloak-gatekeeper (not only Keycloak server), but you still need to create users in OpenNebula manually.

[tipirk]

Thanks a lot! I'll try it

[TheTesla]

Something is missing here. For me it works through selecting id provider, login, redirect to opennebula, but I see the login screen of opennebula only, logging in does not work. What is missing?

[kvaps]

@TheTesla have you created user in OpenNenula before logging?

[TheTesla]

@kvaps: Now I have created the user. But can you tell me please, which "Authentication" I have tu choose? core, public, ... custom? What is the Username? I am logging in with this Github account via helmholtz aai.

[kvaps]

which "Authentication" I have tu choose? core

the public one

What is the Username?

Check what's passed in your X-Auth-Username header

[TheTesla]

There is no X-Auth-Username header in the browser. Is this only in the proxy connection between keycloak-gatekeeper and opennebula?

[TheTesla]

I am using Opennebula 5.12.0.1. I also can't login with users created via sunstone, same for oneuser create. It looks like a bigger problem.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. The OpenNebula Dev Team

[TafkaMax]

Keycloak-gatekeeper seems to be a stale/archived thing.

It is unfortunate ON does not have OIDC/SAML support.

The best I can understand is that if you have a reverse proxy inbetween, that proxy can send headers to sunstone for authentication.

1. Openresty with OIDC plugin
2. You auth against a OIDC provider for example inside the openresty reverse proxy.
3. If the authentication is successful that proxy will SET new headers REMOTE_USER or X-AUTH-USERNAME (or whatever)
4. Sunstone accepts the two headers (REMOTE_USER) or the other one
5. IF sunstone has :auth: remote and :driver: public or whatever then you are in the UI.

This seems to be what can be done looking at the available posts from the past.

EDIT:

https://docs.opennebula.io/6.6/installation_and_configuration/authentication/sunstone.html#remote-auth

The login screen will not display the username and password fields anymore, as all information is fetched from the Kerberos server or a remote authentication service.

This is exactly what I was explaining? So in the past kerberos support has been added using those ENV vars, now we just need a ruby plugin like: https://github.com/omniauth/omniauth_openid_connect ???

Gitlab is built on ruby and its OIDC support is superb

[tinova]

Our current approach (in both Ruby and FireEdge Sunstone) to SAML support is through a reverse proxy. Taking into account the cost of implementing this support natively, we would need to understand the benefits very clearly.

Closing until the discussion renders a motivation to reconsider this for future roadmaps.

[TafkaMax]

Our current approach (in both Ruby and FireEdge Sunstone) to SAML support is through a reverse proxy. Taking into account the cost of implementing this support natively, we would need to understand the benefits very clearly.

Closing until the discussion renders a motivation to reconsider this for future roadmaps.

OK this is exactly what I was talking about. But could you elaborate the docs on how to implement this properly? Currently I have skimmed everywhere and I seem to understand that what i pointed out before.

1. :auth: remote
2. driver public
3. proxy needs to return REMOTE_USER or X-AUTH-USERNAME to the sunstone?

Is this correct or is there something else I need to do for SAML integration, btw OIDC should work with this aswell, its about what headers are returned from the reverse proxy to the sunstone that matter.

[tinova]

Those are the needed steps, correct. Proxy needs to allow these headers, that should come from the authentication backend (for instance, Shibboleth).

We haven't test OIDC, we would appreciate feedback on this!

[TafkaMax]

Hmm currently I am using Openresty OIDC plugin to do the authentication. On successful authentication it sets the headers (X-Auth-Username).

-- Set logging to INFO
local openidc = require("resty.openidc")
openidc.set_logging(nil, { DEBUG = ngx.INFO })
local opts = {
    redirect_uri = "REDACTED",
    discovery = "REDACTED",
    client_id = "opennebula",
    client_secret = "REDACTED",
    introspection_endpoint_auth_method = "client_secret_basic",
    redirect_uri_scheme = "https",
    logout_path = "/logout",
    redirect_after_logout_uri = "REDACTED",
    redirect_after_logout_with_id_token_hint = true,
    renew_access_token_on_expiry = true,
    revoke_tokens_on_logout = true,
    session_contents = {id_token=true}
}
-- call introspect for OAuth 2.0 Bearer Access Token validation
local res, err = openidc.authenticate(opts)
if err then
    ngx.status = 403
    ngx.say(err)
    ngx.log(ngx.ERR, err)
    ngx.exit(ngx.HTTP_FORBIDDEN)
end
ngx.req.set_header("X-Auth-Username", res.id_token.preffered_username)

In my /var/log/one/sunstone-server.conf authentication I get this:

Wed Jun 21 12:54:18 2023 [I]: Updating user pool cache.
Wed Jun 21 12:54:18 2023 [E]: [one.userpool.info] User couldn't be authenticated, aborting call.
Wed Jun 21 12:54:18 2023 [I]: REDACTED - - [21/Jun/2023:12:54:18 +0300] "POST /login HTTP/1.1" 500 - 0.0067

[TafkaMax]

I have created the user with the necessary driver public.

I then set the auth to remote and then restart the sunstone service.

[nachowork90]

An easy environment to illustrate is the new WHMCS integration, as the user need to login in the WHMCS to create an order with one account and after that need to loggin separately into the Fireedge/Sunstone web!

[atodorov-storpool]

The reverse proxy approach is partial, if not limited. The login could indeed be redirected but the logout is not handled. Currently, on logout, the user is driven back to the Sunstone "login" page with the keepalive option (that is opening another can of issues itself...). There is no handler to do signoff from the SSO when signing off from sunstone. Also, if the OAUTH token expires there is just an "internal server error" message until the user refresh the page.

The above issues manifest on both Nginx and Apache configured to do the OAUTH...

[tinova]

Ok, we'll consider another approach for SAML support that overcomes this limitations https://github.com/OpenNebula/one/issues/6496