5 ms·
What's the advantage of your thing over, say, LDAP?
by angersock 9y ago
What's the advantage of your thing over, say, LDAP?
- tptacek 9y agoIt'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.
- eximius 9y agoOut of curiosity (and ignorance), why SAML vs JWT or some less awful protocol?
- jvoorhis 9y agoThere 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.
- tptacek 9y agoJWT 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.
- gridscomputing 9y agoJust Say No to JWT
- whatusername 9y agoWhy not OIDC? (which is a SSO standard)
- lvh 9y agoOpenID Connect is significantly less popular, especially among enterprise on-site apps, than SAML.
- ak217 9y agoCan 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.
- tptacek 9y agoThey'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.
- ak217 9y agoThanks. 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 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.
- tptacek 9y agoI 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.
- 9y ago
- jf 9y agoBy "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?
- lvh 9y ago(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!
- eximius 9y agoIs there a non-awful protocol to bet on?
- tptacek 9y agoNo. Me and LVH keep spitballing what one would look like, but I'd want to have a userbase before suggesting anything concrete.
- awalton 9y agoThe 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.
- thiht 9y agoOn 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
- lvh 9y agoI 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 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.
- deleted 9y ago[deleted]
- jf 9y ago> 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/ http://saml.oktadev.com/ 2: https://bitbucket.org/jfranusic/saml-messenger https://bitbucket.org/jfranusic/saml-messenger 3: https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91-8-23-12.pdf https://www.usenix.org/system/files/conference/usenixsecurit...
- tptacek 9y agoYes, 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!
- w8rbt 9y agoIs 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!