[thramp]

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.

[Saaster]

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.

[Haegin]

It's a paid service, but AWS Cognito supports SAML in a similar way to Okta/Auth0 but with a much lower initial cost (you just pay a reasonable rate for what you use, not multiple thousands of dollars to get it up and running). I used it to build a SAML integration at the end of last year and have been pretty happy with it so far.

[Saaster]

I've looked at Cognito in depth, and it seems like an abandoned service. Hundreds of open issues that got rolled into the Amplify issue tracker, with little to no response. It lacks some pretty basic SAML capabilities, like IdP-initiated logins. If your customers want to put you as an icon in their Okta dashboard or whatever, can't do it. They reported that as being "on their roadmap" in 2017.

It does work for the basic use cases, so I would still consider that an better option than rolling your own for the average service provider.

[derefr]

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.

[Saaster]

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.

[user5994461]

If you want JWT tokens, you should be using OpenID Connect instead of SAML. There is very little reasons to use SAML in 2020, it's over complicated and has little support. OpenID Connect does 95% of the same, much better.

If you want self hosted IAM solutions. The most common one is Microsoft active directory. It provides both SAML and OpenID Connect integrations out of the box as of ADFS 2016.

Still, SAML requires to onboard applications individually, create keys, and stuff. It's not plug and play, it really needs humans on both sides to add a new service.

[Saaster]

Unfortunately the demand for SAML is 100% customer driven. As service providers, we don't control the other end (the customer's IdP/AD).

Even in cases where the IdP supports both SAML & OIDC, I see almost no one choosing to use OIDC (a case of the devil you know?). The only real users of OIDC in an enterprise setting I see as a service provider, is G Suite businesses.

[user5994461]

I think this is mostly driven by history. OIDC came in few years after SAML, so people are still thinking of SAML first and asking for it for enterprise integrations.

I'm pretty sure OIDC can be supported everywhere now. Okta, Oauth, PingIdentity, ForgeRock, Microsoft all support both. The last offender was Microsoft but it's included with active directory since 2016 both on premise or through Azure.

I'm working on auth for a big bank and it's definitely there, although not necessarily advertised and not everybody understand what is supported or preferred.

If a company were to only support OIDC nowadays, and maintain that OIDC is the preferred protocol when customers ask "can you do SAML?", I am willing to bet that most customers would integrate just fine either way.

[vetinari]

> 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

You want Keycloak - https://www.keycloak.org/ - then.

[tasssko]

+1 for keycloak

[hunter2_]

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.

[snuxoll]

Nod to Keycloak / Red Hat SSO here, it’s my goto solution for dealing with identity these days.

[chrisweekly]

+1 Wish I had more upvotes to give. This should exist.

[cactus2093]

This doesn't make sense. Login of any kind can be a tricky problem, you need to handle passwords, rate limits, email verification, password resets, etc. In most popular web frameworks there are libraries you can drop-in that handle all of this for you (like Devise in rails). There are drop-in libraries like OmniAuth (again for ruby/rails) to make handling multiple types of Oauth login simple.

The same could clearly be done for SAML (and I've even implemented SAML and SCIM auth and user management for Okta before in an app, it's not difficult).

The problem is that the only organizations that would make this single issue of SSO support a deal-breaker are bigger companies who can afford to be upsold, so everyone treats this as an up-sell feature. This comes at the expense of the smaller companies, who can't afford to care as much about security. The industry should be making things secure by default as much as possible, and there's a big gap here in what basically every SAAS company is doing.

[vetinari]

> The problem is that the only organizations that would make this single issue of SSO support a deal-breaker are bigger companies who can afford to be upsold

That's not true. We are a tiny company (~10 ppl), but SAML, OIDC (or GSSAPI or Radius, if really necessary) support are a deal-breaker for anything we use.

We used to have separate accounts for everything we had. It became a drag, we had to solve it. Nowadays, either it can be integrated with SSO, or we will do without.

> so everyone treats this as an up-sell feature.

And that's the mistake.

[Saaster]

Passwords, rate limits, resets, etc. are the same for everyone, and so are the problems and the solutions to those.

SAML on the other hand is different for each organization. Providers pay Auth0 and the like to have developers on staff who know the pitfalls and quirks of ADFS 3.0 on Windows Server 2012 R2, so they don't have to. Dealing with a single Okta as IdP integration is like the absolute best-case scenario there is. There is also zero consistency in what actual data IdPs returns out of the box to the SPs, so now you're walking the customer's admin through setting up the proper attribute mappings, etc.

I also very much disagree that SAML is a net security benefit, at least directly. It's for convenience, top-down visibility and control into what people are using, de-provisioning services, onboarding and offboarding users at scale etc. e.g. problems that only big companies have. Many SAML implementations are just as likely to add truck-sized security holes to the service provider when done poorly, and a lot of them are done poorly.

[tptacek]

It's a little odd to say something is not a "net security benefit" and, in the next sentence, make a powerful case for it as a net security benefit. SSO is probably the most important organization security tool there is, and a survey of tech company CSOs will average it in the top 3, if not the top 2 technology acquisitions most would make at a new firm (this is a question I've actually surveyed).

[Saaster]

SSO is a great benefit to the customers, with real tangible security and management benefits.

I'm however speaking from the point of view of the service provider (the SaaS app) and about SAML in particular. I feel that the addition of SAML into a given service is a net-negative from that service's security point of view. It's a large additional complex attack surface, many open source SAML libraries that I've reviewed have a history (and in some cases open issues right now) of "pants on head" type of security errors. A popular library in use right now, has a known race condition where it gets confused if there are concurrent SAML requests happening.

And that's just the libraries. Then you have to use them correctly. The libraries do the absolute minimum checking since they don't have the context, you have to add a laundry list of your own checks to them. Just recently there was a HN article about taking SAML assertions posted to provider A and re-using them on provider B, where clearly the most basic of checks aren't in place at all. There's all kinds of confused-deputy type of problems I believe most service providers don't think about at all. And that was an easily offline checked attribute, I believe if you'd start to check how many services correctly implement even the basic "inResponseTo" check on SP-initiated flows (which requires a distributed cache on the service provider side), you'd find they don't.

[tptacek]

I'm a security researcher with a minor focus in SSO libraries, working on OIDC and SAML right now. I've discovered and reported some of the kinds of issues you're referring to. Both OIDC and SAML are fraught in implementation, but so are all login features.

Meanwhile: we're discussing Github, not a random cat-sharing startup. Github has one of the larger security teams in the industry. The parties implicated in Github SAML are Github, Okta, and Github customers, who do not actually have to implement SAML. Github SAML is not in fact a net-negative for security.

[user5994461]

What's are the other contenders for top 3?

[tptacek]

MDM or endpoint tracking, and then it gets diverse.

[closeparen]

What about OpenID Connect? That seems a lot simpler, and also has open source implementations that aren't too intimidating.

[tptacek]

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.

[user5994461]

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.

[tptacek]

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.

[user5994461]

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.

[JMTQp8lwXL]

Stuff like SAML is kind of the only leverage freemium SaaS has for rationalizing charging enterprise customers.

[atonse]

Not true. There are other things (like audit logs, invoice/PO payments, better support) that enterprises will still want.

[ryanisnan]

Yeah but considering SAML is one of the primary asks of enterprise, it kind of makes it a big selling point.

[Spivak]

And people keep saying that it's a security feature but that's not why large orgs pay for it. It's a "I'll pay you to not have to manually manage account access to all these different services.

[JMTQp8lwXL]

If it's possible for GH to run a profitable business while offering SAML integration for free, I am 100% supportive of the suggestion. It's hard to say exactly how many enterprises pay specifically or exclusively for this reason, as opposed to other enterprise features, like audit trails.

[Corrado]

Yes, I'm pretty happy with the new pricing but my employer will probably have to go with the Enterprise plan to get access to the "Audit Log" and HIPAA compliance. :frown:

[tptacek]

Since they just said they were waiting for Enterprise revenue to reach a level where they could free the core product, and since SAML is an important driver of Enterprise upgrades (I've seen it happen), I wouldn't hold your breath.

Now that the core Pro features are free, I wonder if Rob will update sso.tax to set Github to :inf:.

[thramp]

I was _just_ thinking of https://latacora.micro.blog/2020/03/12/the-soc-starting.html and https://sso.tax/ as I was writing my comment!

[vptr]

Agree. I sell simple sass product myself and offer SAML to everyone. I view security as a basic right, not something to be used to extract more money for. Charging for additional features is ok, charging for keeping your account more secure is just plain wrong.

[hirako2000]

But saml is for integration (SSO). Github provides 2fa for free.

What enterprise is paying is the convenience, not security itself.

[tptacek]

SSO is a security feature, not a convenience. It happens to be a security feature that comes bundled with some extra convenience, but it's not the only one like that; so are password managers.

[tobinfricke]

I'd never heard of SAML before. Is it like a more complicated version of OAuth?

[tptacek]

SAML is the de facto standard single sign-on protocol for enterprise-grade applications. If a SAAS app integrates directly with Okta or OneLogin, it probably does so with SAML.

There's a lot of functional overlap between SAML and OIDC/OAuth, but SAML is a very different (and idiosyncratic) protocol; the "what" is the same, but the "how" is very different.

[kube-system]

SAML has been around longer and handles AuthN and AuthZ

OAuth only does AuthZ. I've always found OAuth more complicated because you have to combine it with other technologies to get AuthN

[gknoy]

For those like me who had never heard these abbreviations:

AuthN: Authentication (who you are) AuthZ: Authorization (what you are allowed to do)

[thinkharderdev]

OpenID Connect is the standardized AuthN process built on top of OAuth. It’s “on top of” but in practice it’s a simplification if OAuth for the specific purpose of AuttN

[kube-system]

I know, I just personally find it to be a fragmented and confusing set of standards. And a lot of people say OAuth when they mean OpenID Connect, which doesn't help with the confusion... or they abbreviate OpenID Connect as "OpenID" which also means something else.

I've never had to clarify what someone is actually trying to accomplish when they want "SAML 2.0"

[tptacek]

You said "OAuth only does authz and must be combined with other technologies to get authn"; obviously, that's not true, in the sense that you can simply use OIDC --- a dialect of OAuth --- to get both.

Since OIDC is better than SAML, which is probably the scariest security standard on the Internet, I think it's worth being clear to people that OIDC/OAuth is viable.

The SAML authz story, for what it's worth, is pretty shady.

[kube-system]

For sure. I never said SAML was any good -- I said I found it to be simpler. :)

[cactus2093]

SAML is pretty simple, it just uses XML which I think turns people off to it by default. I've implemented it once and I feel like I have a decent handle on what it is (though maybe I've just avoided the worst edge cases).

OAuth is way more complex, I've used it countless times and still get confused by it. It has more complex patterns like having a separate resource server and authentication server, it's used for more purposes, e.g. sometimes for API access and sometimes for login and sometimes a confusing mix of both, and there are big differences between v1 and v2 and some services are still using v1.

[recursive]

> SAML is pretty simple, it just uses XML which I think turns people off to it by default. I've implemented it once and I feel like I have a decent handle on what it is (though maybe I've just avoided the worst edge cases).

I once tried to implement it, and found that the specification was spread across ~500 pages of dense PDFs. I find it to be complex.

[cactus2093]

Well, relatively simple. If you added up the number of pages in the specs for http, html, css, ecmascript, and all the various apis that web developers use every day it would likely be hundreds of thousands, maybe millions of pages. That doesn't seem like a particularly useful metric, because you don't have to read and understand the entire spec to use a technology.

[jaywalk]

Basically, yes. Give me a choice between SAML and OIDC, and I'll choose OIDC every single time.

[vermorel]

Agreed. SAML even makes sense for solo dev.

[nogabebop23]

So you care a lot about this, but not $4/month care?

[dfabulich]

SAML is an enterprise feature; it's $21/user/month.

[Spivak]

Right but $5/month/service is where it starts to add up. Unless you're managing hundreds of users across a bunch of disparate services the value/cost doesn't work out in your favor.

[harha]

could you elaborate further with use-cases?

[eastbayjake]

As a business customer of a SaaS product, being able to revoke any employee's access to the SaaS tool if they are terminated. (Imagine how hard this would be for e.g. the SaaS tool your company uses to view financial reporting if it required every user at your company to create their own username/password. If you wanted to prevent someone from "going rogue" during termination, you would need to have an admin remove their account access prior to termination -- and do it on every SaaS product that person used. With SSO you revoke their access and everything gets locked out.

Source: Watching an alcoholic CTO get fired by the board and taking the startup's hosted Mongo database hostage

[jfkebwjsbx]

I agree, but I think the GP was asking about use cases for a solo dev.

[eastbayjake]

Good clarification! If you're a solo dev who wants to sell your side project to any company >500 people, SAML integration is tablestakes. If you're a solo dev who needs to secure your hobby project on the public internet, it's like bringing a Space Shuttle engine to a knife fight.

[jholman]

If I was in a knife fight, and my buddy showed up and just hit the guy I was fighting with a SSME, I would be totally impressed and also grateful.

[tiffanyh]

Not having to create separate usernames and passwords with yet another service (GitHub)

[m01]

With GitHub (cloud version) specifically it doesn't (currently) work that way, you still need a "normal" GitHub username and password, and you do the organisational SAML login in regular intervals when trying to access that org's resources. I'm not aware of this being a widespread way of doing SAML, but I guess it supports certain use-cases (like keeping a GitHub identity despite switching jobs/OSS projects).

sources:

* https://help.github.com/en/github/setting-up-and-managing-or...

* https://help.github.com/en/github/authenticating-to-github/a...

[edit: formatting]

[alberth]

+1

Even the ability to just “login with gmail” for non-enterprise accounts would be huge