Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Single Sign-On

aws.amazon.com

Post reply on HN
Print view View original

81–90 of 119 posts

Re: AWS Single Sign-On

#81

Post by tptacek »

LudoA wrote: post #74
arekkas wrote: post #64

Earlier quoted context omitted.

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/ )?

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.

Re: AWS Single Sign-On

#82

Post by ak217 »

tptacek wrote: post #78
ak217 wrote: post #51

Earlier quoted context omitted.

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 fin…

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.

Re: AWS Single Sign-On

#83

Post by lvh »

jf wrote: post #58
tptacek wrote: post #40

Earlier quoted context omitted.

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.

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!

Re: AWS Single Sign-On

#84

Post by tptacek »

ak217 wrote: post #82
tptacek wrote: post #78

Earlier quoted context omitted.

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 fin…

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…

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.

Re: AWS Single Sign-On

#85

Post by intrasight »

ianburrell wrote: post #35
intrasight wrote: post #30

I'm trying to understand the use case of this over Cognito for a typical SaaS company. Anyone care to give a brief explanation?

Cognito is for authenticating users while AWS SSO is for authenticating employees. Users don’t usually need to be stored in Active Directory, authenticate to other services with SAML, or assigned groups to control access. AWS SSO should also have better integration with AWS IAM.

Everyone is a user, and most are employees. So that doesn't really answer my question. Users need to be stored somewhere. The question is, is AD a good place to store them. AD is a standard, is flexible, and has been around a long time. So perhaps I should ask the question "Now that we have AWS SSO, why would I use Cognito?"

Re: AWS Single Sign-On

#86

Post by lvh »

ak217 wrote: post #82
tptacek wrote: post #78

Earlier quoted context omitted.

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 fin…

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…

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...

Re: AWS Single Sign-On

#87

Post by lvh »

eximius wrote: post #34
tptacek wrote: post #33

Earlier quoted context omitted.

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.

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

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.

Re: AWS Single Sign-On

#88

Post by ape4 »

thiht wrote: post #68
awalton wrote: post #54

Earlier quoted context omitted.

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

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.

Re: AWS Single Sign-On

#89

Post by BillinghamJ »

will_hughes wrote: post #9
BillinghamJ wrote: post #6

Earlier quoted context omitted.

It was always pretty easy to build yourself with their federated auth system. Nice to have proper support now though. Edit: no, it still isn’t really anything like what I’m wanting. This particular product requires Microsoft AD. I just want our admins to be able to log into AWS via google apps. :(

You should be able to do this already[1]. What issues are you having? [1] https://support.google.com/a/answer/6194963 via http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pro...

Thank you very much for those links. After a couple of hours of messing around I have managed to get that working well. :)
Post reply on HN