We have a single-page web application, and we have a new SSO site (also our own) using OAuth2, and are looking to hook them up.
On our production/staging/CI deployments, it's easy to hook everything up. For instance:
- on production we'll have
https://app.company.comaccess our prod backend point tohttps://sso.company.comfor auth and vice versa - on CI we'll have
https://app.ci.company.comaccess our dev backend and point tohttps://sso.ci.company.comfor auth.
When we're doing development on the app, we access it locally at something like http://localhost:8000/, and it points to the shared dev backend. In the past, we've had it just do its own auth against the dev backend (getting the end user's credentials and submitting it), but we'd like to get it wired to use SSO to auth.
The question comes up of how we can do this without every developer who wants to develop locally needing to set up and custom configure their own SSO service. Specifically, can we use the shared dev/CI SSO and have it point to our local deployments?
What we've considered:
- Use a proxy file/hosts file and have
http(s)://sso.ci.company.compoint tohttp(s)://localhost:8000. This burdens us with setting up HTTPS locally or have the SSO direct to a non-HTTPS URL. Also, the setup is a bit of a pain. - Have our local app redirect to the SSO with an argument identifying itself, and have the SSO use that to know where to redirect. For instance, redirect to
https://sso.ci.company.com/?appUrl=localhost:8000. This forces us to punch an open-ended redirect in the SSO that we'd have to turn off for production and it is a bit "weird" but it works and can be black-boxed into the app. - Just run the SSO locally on every dev box. This is basically the non-solution since it would require a lot of setup to get to a "one box that can run everything" script, and it negates one of our valuable advantages at the moment in that basically all you need to do is check out the code on any system and have it running. I've seen this done before commonly though (often on top of dev VMs); I would just like to explore options that we are potentially closer to.
Is there a solution to this sort of problem or aspects of our ideas we haven't considered yet?
Best Answer
I've previously worked in an environment where we've had SSO and local developer environments.
The key problem that needs to be worked on with SSO and developer environments is that the domain cookie needs to be able to be retrieved when hitting the local dev environment.
Admittingly, part of this has to do with how we set up the environment (and it was many years ago that I was involved with this). It was a polyglot environment with a mixture of static html, old perl cgis, a weblogic server for Java EE, an iis server for some apps that needed to run with asp, and something that engineering ran. The way that SSO communicated this information was that a reverse proxy stuck into the http headers the authenticated user name and all associated access they had. This way, no matter who got it, they could look at the headers and continue from there.
First off, DNS was set up so that each developer had a host name in the 'dev.company.com' domain - thus 'sxu.dev.company.com' (for you) and 'jsmith.dev.comapny.com' for John Smith. All of these names (CNAMES) pointed to a single common dev reverse proxy (the reverse proxy had very little on it) that then looked at the virtual host name that was coming through and then forwarded out the request to the appropriate developer's machine. Note that the interactions with the SSO code was completely contained within the reverse proxy so that no additional libraries needed to be installed anywhere else.
The interaction with infrastructure was simply to add another cname to common.dev.company.com whenever we had a new hire, and then we would add their name to a file that was run through some m4 macros to generate the proper apache http.conf file for the reverse proxy (that did take some work the first time we did it).
With this idea in place, you may wish to consider setting up a reverse proxy that acts to just forward everything to the appropriate developer's machine over http (no matter what type of connection it received).
https://sxu.ci.company.com/xyzgoes to the reverse proxy, which handles the https, and forwards it to your dev box athttp://10.1.2.3/xyz. The gotcha with this approach that you have to watch for is that if you have any absolute paths in the code, or the dev's server tries to be aware of where its installed and the protocol being used to generate a link that is the same format, things might go a bit wonky (thats a technical term).This avoids the problem of setting up https locally (only one server has is running https) or modifying the sso server to go to a non-https url. You've got different setup in a different place.
I am unsure if your local dev boxes respond to access other than localhost (its a valid configuration), if so, those will need to be modified because the request is coming from the proxy in this case rather than the local browser.
I do want to point out the side benefit that it will mean that other devs can hit your environment (you want someone to reproduce a bug while you're watching the log files that you don't know how to repo - have them hit your server).
The second option is a not-non-standard approach (I do recall several production SSO systems being configured to allow a limited set of appUrl type parameters - in part so that the external person could use SSO and go to a specific page once logged in. Adding a mapping of 'dev->localhost:8000' would allow for this, however you will need to reconsider how to address the problem of localhost doesn't get company.com cookies. You will likely need to modify your local boxes to identify as localhost.company.com for that to work.