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
- 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
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.