Challenge Overview
We have a customer who loves Heroku as much as we do. They have a big initiative to move hundreds of their static informational micro-sites over to Heroku and will have a dev and production version (think pipelinish). But they need sso on the dev version, until it gets approved for release then it becomes public. We have two ideas on how to accomplish this but we would like to hear from you. …. Even though this is classified as a code challenge, you only need to submit your prosal or justification as a document.
We are using Heroku as a code hosting platform and as a business, we have a need to spin up many Heroku apps for various web pages. These web pages have 2 statuses: “Pre Production” status and “Production” status. Any web page that is in “Pre Production” status needs to be secured via our SSO methods because it need several different approvals before it can be promoted to “Production” status. Once an app is in “Production” status, anyone in the world should be able to view it.
Our ask for this challenge is what is the best way to accomplish this? We have some preliminary thoughts on what to do, and we’d like to share them with you, but please do not limit yourselves to these solutions. We are open to what the community thinks the best solution is.
Potential Solution 1: We are considering creating a “Proxy” to hide the “Pre Production” servers from the public Internet. This Proxy would pass credentials to a 3rd party federation/sso server and allow for only one callback from this 3rd party service to be used. Once the callback from the federation service resolves, the Proxy can then forward on to the correct Pre Production server. This Proxy would be built by keeping all Pre Produciton apps in a Heroku Private Space and whitelisting those IP addresses from the Proxy.
Advantages
- One solution will cover all apps of any language
Disadvantages
- Single point of failure
- Tight coupling to Heroku Private Spaces/Private IP Whitelist
Potential Solution 2: Since we will primarily be running node based web applications, we are considering creating a node package that utilizes Auth0. With this architecture, we could have Auth0 backed by the single callback from the 3rd party federation service. We could create multiple apps under Auth0 for each app.
Advantages
- Less custom code to develop than Potential Solution 1
- Don’t have to create and support a new product (Proxy)
Disadvantages
- Only works for node (without creating more libraries for more languages)
- Need to create tools to ensure this package is included everywhere and configured correctly
This is a code challenge but there is no coding involved here, we are just looking for a detailed discussion and recommendation on the idea of securing many apps behind SSO access, but then allowing these apps to eventually “graduate” from Pre Production status to Production status where they don’t live behind the SSO protection. This challenge is subjective not objective, which means that all the submissions will be compared with each other and ranked based on how persuasive they are. This is not a classic code challenge which is measured on how well it meets technical goals.
2. Include your experience with the technologies, architectures, or tools mentioned. This will not be a judging criteria but rather for consensus.
3. Please submit a single pdf which is between 2 and 10 pages.
4. Please include an executive summary at the top of your proposal. It should be 1-2 paragraphs that summarize your conclusion succinctly.
5. Although we have provided the 2 solutions above, we welcome any more solutions that you think are better and why they are better.
6. Please list any more Advantages and Disadvantages you can come up with for the 2 listed solutions in addition to any solutions that you come up with.
Good Luck
ricka
We are using Heroku as a code hosting platform and as a business, we have a need to spin up many Heroku apps for various web pages. These web pages have 2 statuses: “Pre Production” status and “Production” status. Any web page that is in “Pre Production” status needs to be secured via our SSO methods because it need several different approvals before it can be promoted to “Production” status. Once an app is in “Production” status, anyone in the world should be able to view it.
Our ask for this challenge is what is the best way to accomplish this? We have some preliminary thoughts on what to do, and we’d like to share them with you, but please do not limit yourselves to these solutions. We are open to what the community thinks the best solution is.
Potential Solution 1: We are considering creating a “Proxy” to hide the “Pre Production” servers from the public Internet. This Proxy would pass credentials to a 3rd party federation/sso server and allow for only one callback from this 3rd party service to be used. Once the callback from the federation service resolves, the Proxy can then forward on to the correct Pre Production server. This Proxy would be built by keeping all Pre Produciton apps in a Heroku Private Space and whitelisting those IP addresses from the Proxy.
Advantages
- One solution will cover all apps of any language
Disadvantages
- Single point of failure
- Tight coupling to Heroku Private Spaces/Private IP Whitelist
Potential Solution 2: Since we will primarily be running node based web applications, we are considering creating a node package that utilizes Auth0. With this architecture, we could have Auth0 backed by the single callback from the 3rd party federation service. We could create multiple apps under Auth0 for each app.
Advantages
- Less custom code to develop than Potential Solution 1
- Don’t have to create and support a new product (Proxy)
Disadvantages
- Only works for node (without creating more libraries for more languages)
- Need to create tools to ensure this package is included everywhere and configured correctly
This is a code challenge but there is no coding involved here, we are just looking for a detailed discussion and recommendation on the idea of securing many apps behind SSO access, but then allowing these apps to eventually “graduate” from Pre Production status to Production status where they don’t live behind the SSO protection. This challenge is subjective not objective, which means that all the submissions will be compared with each other and ranked based on how persuasive they are. This is not a classic code challenge which is measured on how well it meets technical goals.
Final Submission Guidelines
1. Provide citations from sources around the Internet that support any statements you make or conclusions you come to. You don’t have to cite everything, but finding other experts in the community that agree with you is valuable.2. Include your experience with the technologies, architectures, or tools mentioned. This will not be a judging criteria but rather for consensus.
3. Please submit a single pdf which is between 2 and 10 pages.
4. Please include an executive summary at the top of your proposal. It should be 1-2 paragraphs that summarize your conclusion succinctly.
5. Although we have provided the 2 solutions above, we welcome any more solutions that you think are better and why they are better.
6. Please list any more Advantages and Disadvantages you can come up with for the 2 listed solutions in addition to any solutions that you come up with.
Good Luck
ricka