As the author of a pluggable OAuth2 & OIDC Provider ( https://github.com/ory/hydra ) I am looking for an OSS IDP that solves just ID management. Is there a URL where I can expect this to land?

What about Keycloak (http://www.keycloak.org/)?

I want to be careful not to confuse between Keycloak and a few other suites like FreeIPA we (Latacora) tried because this was a while ago, way back when we started writing the IdP and I don't accidentally want to throw shade at another project, so mistakes mine... But the built artifact size is like, 10-100x larger. And that's a Go binary, so no cheating with e.g. grabbing an XML parser from the stdlib or something. You can much more plausibly audit the living daylights out of the Latacora IdP because it's tiny.

The Identity Mutilator is microscopic compared to Keycloak. It just does the two things it's supposed to do: let users log themselves in with 2FA, and then log them in to the applications they've been allowed to use.

My take is, if you were going to use Keycloak (or Shib or FreeIPA), you'd already be using Keycloak.

That's a good question, but for now you can just email me.

In your own words, you're a SAML IdP, not an SSO manger, like AWS SSO. I believe you're more akin to AWS Cognito than to AWS SSO. Unless I'm missing something in your description

What's the difference?

SAML IdP is the entity that stores the identities (source of truth), SSO provider can be the same IdP or a 3rd party entity that can federate this identity to different service providers (apps).

Yeah, I don't care about these terms at all. I'm happy to get directory integration working, or to proxy SAML from elsewhere (as long as it conforms to the minimal SAML I'm willing to speak).

You should care about these terms while building and marketing software in the space. I'm not saying you're being deceitful, however, almost anyone who read your description assumed your offering to have feature parity with AWS SSO, but the feature list probably is closer to AWS Cognito. An open alternative to Cognito might be sufficient for most, but is still not the same as a comprehensive SSO manger

I think we're just going to put it on Github for now and say "here's this thing and here's what it can do" and not worry too much about an Eric and Al Ries-approved Positioning marketing strategy. Not giving a shit about stuff is pretty liberating. :)

It doesn't have to store the entities; it's just trusted by some set of service providers to provide identity claims. Nothing in the definition says an IdP can't federate further.

Sounds interesting! But AWS SSO doesn't integrate with 3rd party SAML IdP's yet and can only integrate with AD. How can I use this with AWS SSO?

I have no idea. I don't really grok AWS SSO or Cogito as products, except that they make a lot of sense if you're trying to make your entire application footprint just a set of lambdas.

When first-class Golang support for lambdas arrives (it's on the roadmap apparently), I'm probably going to take a crack at getting the IdP to work as a set of lambdas as well. I wish I could say that was my idea, but someone DM'd it to me after I mentioned The Identity Mutilator on Twitter, and so now I'm stealing it.

But anyways that's why I'm chattering about it now, in case other people have ideas.

I believe they announced Go support for Lambda at re:Invent this year.

What's the advantage of your thing over, say, LDAP?

It's an SSO system, so think LDAP plus a "universal login page" for all your applications. Ours is a stripped down, carefully audited Golang application that does TOTP and U2F.

But, like all modern SSO systems, we (unfortunately) speak SAML --- a godawful protocol, but one we did a from-scratch implementation of to avoid crazy deps.

> SAML --- a godawful protocol, but one we did a from-scratch implementation of to avoid crazy deps.

Agree that SAML is godawful (to put it lightly) and also very curious about your from-scratch implementation. I assume that by "crazy deps" you're referring to xmlsec1 (which, disturbingly, nearly every non Java/.NET library uses) Did you implement XML-DSig yourself? (!)

I'd be very interested in comparing notes on test cases. I wrote a SAML testing tool [1][2] inspired by the "On Breaking SAML" paper [3] but the tool is incomplete and essentially abandoned because I hoped that people would stop implementing SAML.

Would you be open to comparing notes on test suites for SAML implementations?

Footnotes:

1: http://saml.oktadev.com/

2: https://bitbucket.org/jfranusic/saml-messenger

3: https://www.usenix.org/system/files/conference/usenixsecurit...

Yes, we implemented our own dsig.

In fact, I wrote the kernel of the IdP after writing my own SAML test suite (after being horrified by the quality of SAML client libraries). I'm very happy to compare notes!

Is your Golang source code public? Great 2FA methods BTW, the only two I trust. Long live OATH and FIDO.

Edit: Never mind... I read further up. Looking forward to seeing it!

Out of curiosity (and ignorance), why SAML vs JWT or some less awful protocol?

JWT is also an awful protocol, and it's also not an SSO standard. There's still time for us not to bet the farm on JWT, and I urge clients to avoid it.

Can you please elaborate on what's awful about JWT/OIDC? I ask because I've implemented SAML-based IdPs and SPs before, and SAML is a serious trainwreck of a protocol. Now I'm looking at implementing OIDC and at first glance it seems a lot more reasonable.

They're basically the same protocol, but:

* SAML has no alg=none.

* JWT doesn't have "signature smuggling" problems.

* SAML has schema validation.

* SAML has more de-facto-required protective metadata (like audience restrictions).

They are both truly terrible. Perhaps even a coinflip decision. But SAML is an actual real-world standard; it's how applications implement SSO. JWT is still floundering around trying to find a place to be essential. Let's hope it fails.

Part of the point of implementing SAML was to implement a stripped-down version of it with none of the flexibility offered by libxmlsec1, which is the kernel for basically every SAML implementation.

Thanks. Can't say I agree on the basis of this list that JWT/OIDC is equally bad to SAML. SAML is an outdated, ill-designed piece of crap that is a ticking time bomb of an implementation nightmare, in large part because almost nobody truly understands the standard or the security implications of the underlying XML Security standards (having written https://github.com/XML-Security/signxml for much the same reasons you cite, I can say it's a minefield). Reading the JWT and OIDC standards so far, they appear much more comprehensible and reasonable in their implementation options.

I understand your logic, but the thing is: nobody implements dsig; they pretty all depend on a single dsig implementation (libxmlsec1). Writing a dsig implementation is obnoxious.

That's not true of JWT; people definitely do implement their own JWT.

They're both awful protocols, and for a lot of the same reasons.

Your comments about SAML are valid, but we're not implementing _all of SAML_. We're implementing the tiny subset that we can do safely once that you're actually going to use, once. This sidesteps some of the issues you're referring to. (Also: while I agree dsig is horrendous, I don't think that stops implementors: there's like 2-3 truly unique implementations, mostly libxmlsec1. People regularly write their own JWT but not dsig.)

If you reduce the scope from every-document-with-the-letters-SAML-on-it to just-the-SAML-you-need, I think the coinflip becomes much more obvious. OIDC is pretty hairy too, for example:

A) You may or may not get cryptographic binding. You can't tell from an intercepted interaction what security properties that interaction really has. For example: my understanding is that Google's OIDC implementation will bind to a specific client cred, so a leaked token sans leaked client cred isn't a big deal -- but that's something Google's implementation did, not something OIDC guarantees you, and it's not evident from the protcol flow. Do you have to validate that ID token signature? Turns out: no, because in practice everyone just does another leg and relies on TLS cert validation anyway, so this entire JWT dance was pointless. [0] This is one of my pet peeve regressions from OAuth1.0a to OAuth2.

B) Quick: what's the difference between state and nonce? Which one do I use and why? Empirically (but somewhat anecdotally) implementers don't understand this. (I know _why_ it happened, I just don't think it should've.)

... and of course C) JWT bugs in homegrown impls: very real.

You can sort-of reduce OIDC but you still end up with at least 3 distinct flows and then you might have a JWT'd ID token (so you may or may not have to do a third leg of extra work to actually get an identity assertion). OIDC is a meandering tree of options which does not fit in my head. TinySAML fits in my head. There's one obvious general flow and one tiny validation path. The only property you're not technically guaranteed is (cryptographic) audience restriction, but the IdP UX is in a unique position to de facto guarantee that (everyone gets their own key pair).

When you add to that SAML's crushing market penetration, I think it is the right call.

Finally, just to end with a slightly cheeky joke (please don't interpret this as the crux of my argument, I get that this is apples-to-oranges):

   > cat **.go | wc -l
   17060

   > curl -s "https://openid.net/specs/openid-connect-core-1_0.html" | pandoc -t markdown | wc -l
   12897

Keep in mind that the OIDC Core spec says things like "validate per OAuth2 RFC", so the real spec is much larger, but there's also a lot of HTML markdown that pandoc doesn't compress well.

[0]: https://developers.google.com/identity/protocols/OpenIDConne...

Thanks for the thorough response. I haven't heard of TinySAML before, are we talking about https://github.com/nicolas-raoul/Tiny-SAML-IDP? In general, my experience with SAML in the wild is congruent to yours with OIDC: it's a meandering tree of crappy options that doesn't fit in my head. I'm discouraged to hear the same opinion about OIDC. Do you really think SAML has a bigger future than OIDC?

Are there implementation notes or library implementations of SAML and OIDC that you would recommend as good references? I'm aware of Okta's docs, https://www.owasp.org/index.php/SAML_Security_Cheat_Sheet, https://wiki.mozilla.org/Security/Guidelines/OpenID_Connect, and the Google docs you linked, but would like to learn more/find better libraries.

Sorry for the term confusion: TinySAML is what I’m informally calling the tiny subset of SAML we’re choosing to care about. Neither full-SAML nor full-OIDC fit in my head; I’ll also concede that full-SAML is much more complicated than full-OIDC, but that doesn’t matter: narrowing scope is much more effective for SAML than OIDC.

I hope both protocols become obsolete. SAML may not be the future, but it’s definitely the present. I’m not convinced OIDC is materially better.

‘tptacek will have much more informed opinions about relative SAML library quality so I’ll leave that to him.

The actual Go package is "trivialsaml". :)

Would be interested to see the source (for reference purposes only, anyway - I prefer Python myself) or any other resources you recommend.

It'll all be public in a few weeks.

I hope both SAML and OIDC go away.

And are replaced with what?

We don’t think it’s been written yet. But punchline: don’t support every combination of encryption and signing; sign in 1 place and 1 place only, tiny set of protocol versions...

If that's my trivialidp repo, in fairness, there are 2-3 other private repos that are important deps. :)

By "JWT" do you mean the the format? (RFC 7519) Or perhaps you meant OpenID Connect?

I can think of reasons for you to urge your clients to avoid JWT-the-format and certainly OIDC-the-standard. What do you suggest as the alternative?

(I work at Latacora and 'tptacek and I have worked on spitballing what that ideal protocol might look like.)

Right now the answer is SAML because a) we can make it not a nightmare b) it is the de facto enterprise SSO protcool. To make SAML not a nightmare, we do the tiniest part of SAML that produces valid dsigs that other apps consume. It's not so bad as long as you just get that one basic case right and then NEVER TOUCH IT AGAIN.

At some point, it's likely that we figure out what a good alternative would look like and publish that too, but it needs a clear value proposition that outweighs SAML's crushing market penetration. Something like "you can plausibly implement this in a dozen lines in every programming language" and "if you mess it up it stops working".

You're probably right about the reasons OIDC isn't it. Maybe we just need a protocol with one more CSRF token parameter!

Is there a non-awful protocol to bet on?

No. Me and LVH keep spitballing what one would look like, but I'd want to have a userbase before suggesting anything concrete.

Why not OIDC? (which is a SSO standard)

OpenID Connect is significantly less popular, especially among enterprise on-site apps, than SAML.

Just Say No to JWT

The Enterprise SSO market is close to defacto standardizing around SAML AFAICT. Either your product supports it, or the very large enterprises with very large budgets can't use it, and your competitor that does support SAML gets the dollars instead.

On a side note, is it necesary to use cryptic acronyms like "AFAICT"? If you don't want to write "as far a I can tell", why do you? It's kinda annoying to have to google for abbreviations like that all the time

It’s more annoying to have to type out the full expression each time you use it. That acronym has been in use on the internet for decades.

I thought it was a SSO protocol for a second. It sort of makes sense - Are you logged in? As Far As I Can Tell.

There is a massive amount of enterprise software on the market which predates JWT, and enough inertia that vendors keep implementing SAML support for new products. It's not going away soon.

I started talking about this elsewhere in the thread where someone suggests SAML's awful (agree) and OIDC is a better choice (disagree): https://news.ycombinator.com/item?id=15914881

I think it answers the question of why SAML nicely, but the TL;DR is: you can pare SAML down to a sane subset, and crushing market penetration.