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
What about OpenID Connect? That seems a lot simpler, and also has open source implementations that aren't too intimidating.

>>closep+yg
It's not a technology problem. Integration with "foreign" SSOs is complicated no matter what protocol you use, with lots of corner cases and support costs, but these features are expensive for the same reason that single-day-turnaround short-notice flights between Chicago and NYC tend to be expensive: the people who want them have money to spend on them, and it isn't their money. That money pays for the cheap seats everyone else sits in.

>>tptace+Jo
SAML is a technology problem, on top of all other problems.

The messages are under specified and overcomplicated, doing incredibly obscure stuff (XML signing and canonization for one) that nobody can understand and implement. That's mainly why it's so hard to use and there is so little support from libraries.

As security researcher, we could nitpick all days on security being hard, no matter the solution. It is factually true but it doesn't help developers, fact is, developers would be better off ignoring SAML and going with OIDC instead.

>>user59+kS
1. I don't think this particular thread is a good venue to litigate SAML vs. OIDC.

2. I think the product complexity issues are, like, 95% the same whether you use OIDC or SAML.

3. I think no matter how much simplification you got from using OIDC instead of SAML, none of it is going to offset the actual reason why SSO integration is a paid feature.

4. I agree that SAML is much worse than OIDC from a protocol implementor's perspective even if I'm not so sure that it's much better from a developer's perspective, so wouldn't want to find new reasons to disagree.

>>tptace+0U
I basically agree with the points.

Ironically, the first point makes me realize that half the work to bring in a product in an entreprise is to deploy and set it up -properly with authentication- while the other half is to get the budget and approvals to buy it. Thus it's rather relevant to the thread in an unfortunate way.