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:
- 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.
- The front-end only supports standalone mode (it does not retrieve a token for you, when in proxy mode).
- 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.