zlacker

>>ig0r0+(OP)
Hi HN, I'm the CEO of GitHub. Everyone at GitHub is really excited about this announcement, and I'm happy to answer any questions.

We've wanted to make this change for the last 18 months, but needed our Enterprise business to be big enough to enable the free use of GitHub by the rest of the world. I'm happy to say that it's grown dramatically in the last year, and so we're able to make GitHub free for teams that don't need Enterprise features.

We also retained our Team pricing plan for people who need email support (and a couple of other features like code owners).

In general we think that every developer on earth should be able to use GitHub for their work, and so it is great to remove price as a barrier.

>>natfri+V2
This is a great change! One request: I wish that SAML was not an enterprise feature. SAML ought be a basic security feature like 2FA—it's especially valuable for open source teams who might use a mixture of services, and an easily accessible and cheap SSO solution would go a long way in raising the security bar for all teams, not just open source teams.

>>thramp+Q3
SAML (and 2FA to a lesser extent) comes with some serious support burdens on the companies offering it. There's a long tail of more or less broken SAML implementations on both the service and identity provider sides, provisioning issues, configuration issues, "Sally can't login on Tuesdays" issues, duplicated slightly-inconsistent data in IdP and Service side records issues...

If you as a SaaS provider outsource your SAML integration to a third party provider like Okta or Auth0, the auth provider pricing is immediately on a "call us" tier, with a per-federation pricing in the low four figures for each company connecting via SAML. Let me just state that again, to have company X connect to my SaaS via SAML, I as the SaaS provider have to pay my auth provider $X,000 per year for the privilege, not counting the base enterprise tier pricing for the auth.

>>Saaste+Q8
Sounds like SAML needs the same "everyone gets together to make a FOSS implementation that knows about the weird quirks of all the implementations it interacts with" approach that e.g. the Samba project was founded upon.

>>derefr+Kd
I agree. There's a million SAML for Java/Python/Node.js/Foo libraries out there, all with a long list of issues and known cases that don't work correctly, security issues etc. but it's the wrong model in my opinion.

Instead of directly bolting SAML into your app, I think a FOSS implementation of an independently running service is the way to go. You run the battle tested open source service (locally / in your cloud), it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta. Doesn't even need to do any user management, just focus on rock solid interoperability and forward all decision making to the actual app server.

>>Saaste+wj
This sounds like Shibboleth. The SP bolts onto httpd and delivers things like user attributes as server variables that apps can simply read. It even works if httpd is a reverse proxy in front of nodejs or whatever else, since you protect the app using location directives which play nice with proxypass directives.

The opposite certainly exists though, for example simplesamlphp which gets commingled into a php app codebase as you described.