Show HN: BuzzFeed open source SSO(tech.buzzfeed.com)
tech.buzzfeed.com
Show HN: BuzzFeed open source SSO
https://tech.buzzfeed.com/unleashing-the-a6a1a5da39d6
41 comments
Looks super interesting. I'm looking to do something like this for my personal stuff, but I'd rather avoid the dependency on Google. Does anyone have suggestions for how to set something like that?
Right now we have a dependency on Google as an OAuth2 provider, as that's what we use internally at BuzzFeed. However we've designed sso to allow us to easily add other providers.
For example, there's this task ( https://github.com/buzzfeed/sso/issues/9 ) to create a default provider without Google dependencies for test purposes.
We'd also welcome PRs adding other providers and believe any OAuth2 provider should be straight forward to add.
For example, there's this task ( https://github.com/buzzfeed/sso/issues/9 ) to create a default provider without Google dependencies for test purposes.
We'd also welcome PRs adding other providers and believe any OAuth2 provider should be straight forward to add.
Cool, thanks for letting me know. I'll have to research this more.
I have used https://github.com/bitly/oauth2_proxy with success, and it supports a variety of providers.
GitHub repo: https://github.com/buzzfeed/sso
This is our identity aware proxy, which we've been using internally for a year.
The blog post explains our motivations behind creating it, and open-sourcing it. It's available today, under MIT license.
We'll be keeping an eye on the thread, and happy to follow up to any questions!
This is our identity aware proxy, which we've been using internally for a year.
The blog post explains our motivations behind creating it, and open-sourcing it. It's available today, under MIT license.
We'll be keeping an eye on the thread, and happy to follow up to any questions!
Thank you for not having just dumped it like that, but adding quick-start guides, examples and even did some additionnal security checks, it's just awesome for little organizations <3
thank you - We know from our own experience using other open source projects that having documentation, and guides to get started really helps.
We know there is more to do there too (some of the feedback in this HN post has helped highlight areas we need to improve the docs) and we will be adding to the docs so over the next while.
We will also welcome PRs improving the docs!
We know there is more to do there too (some of the feedback in this HN post has helped highlight areas we need to improve the docs) and we will be adding to the docs so over the next while.
We will also welcome PRs improving the docs!
Neat project, but I have to ask why you didn't go with an existing solution like Keycloak?
Hey,
there were a few reasons behind this.
- ease of migration was a big one, we had 100+ instances of bitly's oauth2_proxy, and were able to seamlessly migrate them to this, without any changes to the services being protected.
- ease of deployment was also important. Our solution doesn't have any datastore dependencies, and is stateless, so was straightforward to deploy into our PaaS ( https://tech.buzzfeed.com/deploy-with-haste-the-story-of-rig... ).
- when we built this, there were far fewer solutions than there are today. For example, Ory's Oathkeeper ( https://github.com/ory/oathkeeper) was released after we were already using sso internally at BuzzFeed.
thanks!
there were a few reasons behind this.
- ease of migration was a big one, we had 100+ instances of bitly's oauth2_proxy, and were able to seamlessly migrate them to this, without any changes to the services being protected.
- ease of deployment was also important. Our solution doesn't have any datastore dependencies, and is stateless, so was straightforward to deploy into our PaaS ( https://tech.buzzfeed.com/deploy-with-haste-the-story-of-rig... ).
- when we built this, there were far fewer solutions than there are today. For example, Ory's Oathkeeper ( https://github.com/ory/oathkeeper) was released after we were already using sso internally at BuzzFeed.
thanks!
Is it possible to use this with Nginx auth_request? I use bitlys oauth2_proxy like so because it doesn't support websockets.
Maybe - we've not tried it, but I just asked Justin who architected sso, and he suggested that maybe https://github.com/buzzfeed/sso/blob/master/internal/proxy/o... could be used.
However there would be some caveats - like for example `skip_auth_regex` (see https://github.com/buzzfeed/sso/blob/master/docs/sso_config.... ) would not work with this, because the original URI would not be checked.
However there would be some caveats - like for example `skip_auth_regex` (see https://github.com/buzzfeed/sso/blob/master/docs/sso_config.... ) would not work with this, because the original URI would not be checked.
Have you contracted an independent pen-testing company to assess your design and implementation?
Yes, as mentioned in the blog post, we worked with Security Innovation to do a week long security assessment with full access to source code, design documents and endpoints.
We also have a long term consulting arrangement with a widely respected security architect, and they helped review our design and implementation.
Additionally, BuzzFeed has a bug bounty program on hackerone (https://hackerone.com/buzzfeed), and have invited partipating researchers to report on any issues found. We’ve paid out bounties for a number of minor issues, which were addressed prior to open-sourcing.
Additionally, knowing that security is never done, we continue to make it eligible for bounties -- see https://github.com/buzzfeed/sso/blob/master/README.md#securi...
We also have a long term consulting arrangement with a widely respected security architect, and they helped review our design and implementation.
Additionally, BuzzFeed has a bug bounty program on hackerone (https://hackerone.com/buzzfeed), and have invited partipating researchers to report on any issues found. We’ve paid out bounties for a number of minor issues, which were addressed prior to open-sourcing.
Additionally, knowing that security is never done, we continue to make it eligible for bounties -- see https://github.com/buzzfeed/sso/blob/master/README.md#securi...
This is mentioned in the article
> In preparation for open sourcing we also engaged with Security Innovation, a widely respected agency who count Microsoft, Symantec, and Amazon as clients, to do a more in-depth, week long assessment, with full access to source code and design documents. This found no major issues, which gives us the confidence to open source sso today.
> In preparation for open sourcing we also engaged with Security Innovation, a widely respected agency who count Microsoft, Symantec, and Amazon as clients, to do a more in-depth, week long assessment, with full access to source code and design documents. This found no major issues, which gives us the confidence to open source sso today.
It was only a week long assessment though, I don’t know Security Innovation but I’m sure they would have appreciated more time.
That is understood, and is always why we engaged with some of the top researchers who contribute to our bug bounty program, from the start with this project.
For example offering increased bounties during certain windows, or providing early access to the source code.
We highly value our bug bounty program, and find it to be a very effective mechanism for continuous security validation.
I'll write a tech blog post in the near future about how we facilitate our program.
For example offering increased bounties during certain windows, or providing early access to the source code.
We highly value our bug bounty program, and find it to be a very effective mechanism for continuous security validation.
I'll write a tech blog post in the near future about how we facilitate our program.
Looking forward to read about it. Thank you for the project!
xeromal(2)
How have you found working with Go?
Golang is pretty beloved at BuzzFeed.
It’s one of our two standard languages - the other being Python - and whilst the vast majority of our services are Python, Golang is being used for growing and significant number too.
Touching on my first point, we have observed people enjoy writing Go apps, and it is a great fit particularly where performance and scalability are needed.
Therefore when engineers have moved to another team internally, they often will evangelize Golang to their new team members.
So we expect it to continue to grow and thrive here!
It’s one of our two standard languages - the other being Python - and whilst the vast majority of our services are Python, Golang is being used for growing and significant number too.
Touching on my first point, we have observed people enjoy writing Go apps, and it is a great fit particularly where performance and scalability are needed.
Therefore when engineers have moved to another team internally, they often will evangelize Golang to their new team members.
So we expect it to continue to grow and thrive here!
Jagat(1)
GApps supports Custom SAML app. What's the benefit of using this Oauth2 over SAML2 protocol?
https://support.google.com/a/answer/6087519?hl=en
https://support.google.com/a/answer/6087519?hl=en
Great question.
We found that SAML doesn’t typically have great support on mobile devices [edit: had originally written browser here, hence the comments below], and since BuzzFeed has many remote employees around the world, we needed to support those workflows, so OAuth2 made more sense.
That doesn't make sense. SAML is only a bunch of POST and redirections as far as the browser is concerned. There is no specific support required from the browser.
IMO That's opposite of what I understand. The selling point of Oauth2 is SAML works great on web (mobile browsers included) but not so on apps.
I’ll correct my post above. I meant to say `mobile devices`, not `mobile browsers` . My bad.
The other reason, which I didn’t mention above, but is talked about in the blog post, is we decided to use bitly’s oauth2_proxy as a basis for our solution. This had been widely used in BuzzFeed (we had over 100 auth proxies in place prior to rolling out sso), and so the OAuth flow was something everyone was familiar with.
The other reason, which I didn’t mention above, but is talked about in the blog post, is we decided to use bitly’s oauth2_proxy as a basis for our solution. This had been widely used in BuzzFeed (we had over 100 auth proxies in place prior to rolling out sso), and so the OAuth flow was something everyone was familiar with.
never expected BuzzFeed on HN frontpage (:
BuzzFeed has been on the HN homepage quite frequently.
https://news.ycombinator.com/from?site=buzzfeednews.com
https://news.ycombinator.com/from?site=buzzfeed.com
https://news.ycombinator.com/from?site=buzzfeednews.com
https://news.ycombinator.com/from?site=buzzfeed.com
Buzzfeed news is ... surprisingly good. The Buzzfeed name is just associated with painfully stupid content.
> Buzzfeed news is ... surprisingly good.
This is literally news to me...
This is literally news to me...
We took a slightly different approach to solving a similar problem: https://github.com/thomseddon/traefik-forward-auth
We were already using traefik as a proxy for our docker/swarm clusters and this is a single container drop in to add authentication to every traefik request.
It's still missing a few key features but it can get you started, we're testing the use of a single auth domain (so you don't have to add every internal service domain as a refirect_uri in Google - looks similar to how sso works) internally and we expect to release this shortly once finished.
Additionally, if you want an even lighter weight option, we also use, with great success, cloudflare's lua script on a few services we don't run with docker/traefik: https://github.com/cloudflare/nginx-google-oauth
We were already using traefik as a proxy for our docker/swarm clusters and this is a single container drop in to add authentication to every traefik request.
It's still missing a few key features but it can get you started, we're testing the use of a single auth domain (so you don't have to add every internal service domain as a refirect_uri in Google - looks similar to how sso works) internally and we expect to release this shortly once finished.
Additionally, if you want an even lighter weight option, we also use, with great success, cloudflare's lua script on a few services we don't run with docker/traefik: https://github.com/cloudflare/nginx-google-oauth
a bit ignorant in this area, but how is this functionally different than Google Cloud IAP?
It’s not. We acknowledge that in our blog post, and our approach was definitely influenced by the BeyondCorp philosophy.
However google IAP requires that your infrastructure is all in Google cloud.
Whilst we do use GCP, most of BuzzFeed’s infra is in AWS, we needed a solution which worked for both.
However google IAP requires that your infrastructure is all in Google cloud.
Whilst we do use GCP, most of BuzzFeed’s infra is in AWS, we needed a solution which worked for both.