How to make the webUI works with the st2 Proxy Auth Mode

I am trying to integrate the webui into our project so I need authenticate users with the SSO, which is not supported by the st2 by default. If I configure the st2 authentication as the Proxy Auth Mode, then the authetication can performed on the webUI, and get the token from the st2.

Has anyone tried this method? Thanks

After more digging in, it turns out current code is indeed correct - Fix "proxy" authentication mode by Kami · Pull Request #4224 · StackStorm/st2 · GitHub

The only thing which needs updating is documentation. “REMOTE_ADDR” and “REMOTE_USER” values should come in as a CGI environment variable and not as header values.

In some scenarios, it might also make sense to allow proxy to pass those values as a header, but this is harder to do correctly and has more safety risk - you would need to configure proxy which sits before st2auth and handle authentication to always set those two headers and to make sure user can’t directly overwrite those headers.

I updated documentation in Clarify remote_user and remote_addr need to come in as a CGI environment variable by Kami · Pull Request #761 · StackStorm/st2docs · GitHub to clarify that.

Sorry for bumping, but I think opening a new topic is not desirable, as my question relates to this one.

The documentation is lacking information about how to setup this environment correctly. Currently, I got around the header passing limitation by transforming headers to variables using uwsgi and nginx. With this setup I can retrieve tokens from the auth backend in json format.

I’m not sure how to continue from here. The webui does not seem to have native support for proxy mode. After digging through the st2web repo, I found that the webui only grants access when localStorage contains an st2session. I cannot force this through regular SSO redirects and server-side magic. The only hack I could come up with is creating a login helper page, that is loaded when the auth-token cookie is not set. This page could potentially load values in the local storage and reload the page, loading the actual frontend.

This sounds like a very convoluted way of getting something done that should be fairly easy. Is there any support for passing the token to the frontend in an elegant way?

Edit
I’ve implemented the fix described above. Simply adding an extra page and forcing nginx to load this page, if the auth-token cookie does not exist. The page’s sole purpose is to retrieve the token, set it in the local storage and as a cookie and reload the page. This fix does what I want, but its still a hack to get functionality that I expected to work out of the box.

We actually had some of the similar issues while working on SSO support for our proprietary version (EWC - Extreme Workflow Composer).

In the end we went with the approach where server (st2auth) returns a piece of JavaScript which writes token to local storage after successful SSO exchange before redirecting user to the main page of WebUI.

Thanks for your reply. Nice to know that SSO will be supported in the future. But what I’ve seen from the PRs, it will support saml directly, while we would like to use the proxy mode.

However, according to the documentation, proxy mode should already be supported by the open source version, but from my experience, this is not entirely true. I’ll share the roadblocks we stumbled upon and the solutions we found.

There are three fundamental problems:

1. st2auth only accepts “CGI” parameters. While the documentation explains that “CGI” parameters are used by st2auth, it does not explain how these should be passed.
2. The front-end only supports standalone mode (it does not retrieve a token for you, when in proxy mode).
3. Internal tools (the st2 command line utility) only support standalone mode (they’ll only do a basic auth request to auth backend, which is not accepted in proxy mode).

We wanted to run the docker setup, so we used as many components that were already in the stackstorm image as possible. To fix the problems above, we created a new image based on the original stackstorm image, adding some modifications.

We solved the first problem with uwsgi. Our SSO solution expects backends to accept a header with the username. So, we used nginx to transform the incoming header to a uwsgi parameter, which is passed to the st2auth backend.

The second problem was solved by adding an extra html file (auth.html) to the static directory, which retrieves a token (simply by sending a plain post request to /auth/tokens) and storing it in the local storage. After that, it sets the auth-token cookie and reloads the page. In nginx we added a rule to load auth.html if the auth-token cookie was not set on the incoming request, otherwise, load the normal front-end. This trick ensures the login page is never shown.

Finally, for the third problem, we added a modifying proxy in front of st2auth on the default port (9100). Since we configured st2auth using uwsgi on a unix socket, port 9100 was still free. This allowed us to setup a simple uwsgi vassal, written in python, that proxies all request to the real backend. We do this by forwarding the request to https://localhost/auth/tokens, with the cookie header set to “auth-token=”. The cookie prevents the auth.html page to be loaded. When the proxy encounters a Authorization header, it extracts the username from it and passes the username in the appropriate header to the backend. This trick fixes logins from the command line (st2 login ). This is far from ideal, as this allows you to login as any user with any password (password doesn’t really matter), it is sufficient for our current use case (the command line will only be used for debugging purposes).

This setup seems to accommodate our scenario. We understand that the first problem is not a bug, but a features (according to the documentation). But the second and third problem are bugs in my opinion. You would expect the stackstorm front-end and tooling to know how to handle requests to the authentication backend, when it runs in proxy mode.

Hi @chris

We’re having the same problem as this - we’re trying to use Auth proxy mode to generate tokens for our users - but can’t figure out how to pass the required IP / Username to st2auth in order to get the token.

You mention you have used uwsgi to transform a header to a CGI parameter in nginx. We’re trying to do this using a uwsgi_pass to our ip:port but we get a 502. I think you mention you used a socket for this.

If you could share what your nginx config looks like / how you set up the unix socket, that would be most appreciated.

Thanks in advance,

Jeremy

Hi Jeremy,

The code is a bit involved. To simplify the matter for you (and possibly others), I’ve created a small repository with the a simple setup to get a basic stackstorm docker image which accepts X-Forwarded-User headers correctly. You can find the repository here.

Hi Chris,

That is fantastic, thank you! We’ve had to tweak it a little bit to get it working on a Centos box but we’ve got it working perfectly now.

You are a true and absolute legend.
Thank you!