AWS Single Sign-On
aws.amazon.com
aws.amazon.com
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 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.
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.
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
[0]: https://developers.google.com/identity/protocols/OpenIDConne...
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.
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.
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?
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!
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.
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:
2: https://bitbucket.org/jfranusic/saml-messenger
3: https://www.usenix.org/system/files/conference/usenixsecurit...
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!
Edit: Never mind... I read further up. Looking forward to seeing it!
My take is, if you were going to use Keycloak (or Shib or FreeIPA), you'd already be using Keycloak.
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.
You've got to set up your own Active Directory using Directory Services, which is $288USD/month minimum for two domain controllers.
In order to have MFA for logging into the console (non-negotiable in my opinion), you have to configure your own RADIUS server.
And the question of how to manage access keypairs still remains unanswered, as far as I can tell.
I don't know if this is going to supplant Azure AD as our SSO method of choice.
I believe you can use AD connector to connect to on-premise AD.
It looks like AD Connector is much less: https://aws.amazon.com/directoryservice/other-directories-pr...
$0.12 * 24 * 30 = $86.40/month.
I'd change the statement in my parent post, but I don't seem to be able to edit it.
* Create an AWS Cognito User pool
* Create an Azure AD Enterprise Application
* Set up Azure AD federation to the Cognito User Pool
I was a business analyst (excel grunt) for 2+ years in a biotech startup. Sheets is just different in enough ways to positively irk even the "casual power user" of Excel, IMO.
It's for the other 97%. A list here; a table and a chart there. Now to make it look pretty.
It's really about the data though, and if the database has access to more data, and requires less work from analysts, it becomes a replacement for some work that was previously done in Excel, even if the system still supports exporting to CSV, for importing into Excel for the parts that the system does not support.
The system I am familiar with is Redshift, and we are able to generate daily or hourly graphs for various parts of the business with it.
I lost my phone 2 weeks ago and i lost access to the reauth phone number years ago. I have not been able to get this resolved all this time. The German Website support is clueless about 2FA (that was recently introduced) and AWS support wants a form signed by an US Notary (which are hard to come by in Germany).... Really annoying
Is this an alternative to running ADFS? I guess the fact that you're not running ADFS servers is nice, but as far as I understand, your ADFS servers don't have to be publicly facing. (And honestly, not being able to sign in using corporate credentials if you're not on the corporate network is a security policy that will make lots of admins happy.)
It looks like there's an old AWS blog post about using ADFS to enable SSO to AWS: https://aws.amazon.com/blogs/security/enabling-federation-to...
This would be an alternative to ADFS. It solves a big problem, because for many customers of cloud services, you’re paying for 99.9% reliability from the service provider, but the ADFS farm in your office or in another cloud is a single point of failure with a lower uptime commitment.
https://aws.amazon.com/blogs/security/introducing-aws-single...
Would have been so smooth and so nice before implementing custom SSO...
Edit: sorry didn’t read far enough and have now answered my own question. In VMs. So yea, Amazon could not duplicate without getting people to change AMIs or install some agent. Still seems like an SSH CA is a better option. Curious why google didn’t go that route. Maybe not an option when they built this?
The SAML core is an XML-based system for serializing, signing, and encrypting assertions. There are also SAML flows, and they likely use something Kerberos-esque. So SAML is to Kerberos what HTML is to HTTP, or what x.509 is to TLS, or something like that.
Reference: https://xkcd.com/927/
Ignore rest of my comment:
Proof you can build a massive, multi-billion dollar enterprise business without supporting SSO.
I would not have immediately guessed that statement to be true, and I would have thought AWS already had SSO support.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. :(
[1] https://support.google.com/a/answer/6194963 via http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pro...
SAML is still relatively new, isn't very widely used (AFAICT), and I'm not sure how much security research has been done on the topic thus far.
To illustrate, just a few weeks ago there was "a new attack vector discovered that ... enables an attacker to create a ... forged SAML 'authentication object', and authenticate across every service that uses SAML 2.0 protocol ..." [0].
> In a golden SAML attack, attackers can gain access to any application that supports SAML authentication (e.g. Azure, AWS, vSphere, etc.) with any privileges they desire and be any user on the targeted application (even one that is non-existent in the application in some cases).
Vulnerabilities like this one really do give up the proverbial "keys to the kingdom" and provide an attacker with pretty much everything they need to really ruin your day.
Now, this particular attack isn't real practical as it requires things like the "token-signing private key". You don't need domain admin although you do need access to the ADFS account and if an attacker has access to that, well, you're probably already screwed (or well on your way). The point is that SAML is still shiny and new and there will almost certainly be additional flaws found in the future -- flaws which may very well compromise you completely.
It's certainly a nice solution to a big problem and, as I said, will make a lot of people's lives easier. I'm just not yet ready to trust it 100%.
Edit: To prevent a dozen more "2005!?" comments, I mentioned this in a reply:
> True, but it's still relatively new to most people, similar to how IPv6 has been around for a few decades but is still "new" to many.
The spec has been around for a while. Common deployments -- outside of AWS, MS, RH, etc., haven't (unless I've just been unaware of them).
[0]: https://www.cyberark.com/threat-research-blog/golden-saml-ne...
Any significant O365 implementation is using SAML. Any SaaS that allows enterprise login is using SAML. If you do business with Spectrum, you are using SAML when you login. If you interact with most government agencies, you are using SAML.
That’s not to say that it does not have risk, but adoption is not an issue!
1. I guess "relatively new" is a vague term, but SAML v2.0 (the current version) was standardised in March 2005 - it's now 12.5 years old, I don't call that new.
2. SAML is very widely used in certain segments. Every SSO product supports SAML, including cloud vendors like Azure, Google and now AWS, and also specialist vendors like Okta and OneLogin. Within the dreaded "enterprise" space, SAML is absolutely the #1 SSO technology in play.
3. The golden SAML attack is a load of crap. It basically says "If you can get the private keys of an identity provider, then you can impersonate that identity provider". Yes, SAML relies on the confidentiality of the signing keys. That "attack" is the equivalent of saying Linux security is broken because if you have the root password you can modify any file.
True, but it's still relatively new to most people, similar to how IPv6 has been around for a few decades but is still "new" to many.
> SAML is very widely used in certain segments.
Perhaps but it's only been in the last few years that I've been hearing about it, mostly WRT the cloud vendors (AWS, specifically).
> The golden SAML attack is a load of crap.
Yeah, I think I mentioned it isn't very practical. To me, though, this seems like just the unexpected kind of thing that, some day down the road, is going to come back and bite you in the ass. That is, some major issue in some piece of infrastructure that is overlooked, forgotten about, or taken for granted (e.g. heartbleed or similar), that suddenly causes everybody to drop everything and react immediately to fix it.
The beauty of a federated identity system is that you keep your credentials away from business partners. If you were a corporate customer of Dropbox relying on them to host your identity, you were kind of fucked when they had an account breach. If you used federated identity, Dropbox never had access to your account credentials.
Federated identity also lets you control posture and control access better. Perhaps your email system requires multi-factor auth, but your time card system does not, unless you are approving expenses. You can build that “step up” to multi factor auth on your servers, and use a single MFA credential to do so.
The draw with SAML was definitely for enterprise requirements -- the main one, as I understand it, was the requirement of sharing metadata out-of-band between the IdP and SP to establish trust. While that sounded like a good idea at the time, it turns out that if your organization ends up needing to trust and exchange metadata with more than a few other entities, managing all those certificates and properly validating them is enough of a pain that metadata aggregators have sprung up to handle them.
As business have become more willing to move core services to cloud platforms, they've demanded that those platforms provide a single sign on solution that integrates with their corporate directory.
So, the popularity of SAML has certainly risen with the popularity of cloud / SaaS, but it's perfectly normal for a technology to become more popular with time (until it eventually goes into decline), and that increase in popularity means that it becomes more widely known, and some people who have never had to deal with it before, now come into contact with it.
I've been involved in SAML implementations at fairly conservative technology organisations (banks, pharma) for more than 6 years (and for most of that time it wasn't my core role). It's old tech, that's in wide usage, it just isn't something that most people need to deal with because it's boring identity management infrastructure that most application developers don't get involved in.
While it may not be the prettiest protocol, today it is the only broadly supported SSO option that does not expose your credentials to a third party. LDAP was the way to go at one point, but this only makes sense for on-prem software where you can trust your credentials to flow through.
Also, I am pleasantly surprised by the number of orgs that are introducing regular key-rotation into their SAML iDPs.
In just the global research and higher educational community (eduGAIN), there are currently 2588 SAML identity providers and 1792 SAML service providers.
> Now, this [golden SAML] attack isn't real practical as it requires things like the "token-signing private key".
It isn't a flaw in the SAML protocol. If an attacker compromises your IAM infrastructure, be that a domain controller, directory server, KDC, IdP, or OP, they can impersonate your users.
Is there a reason you would expect to be aware of them? Is this a field that you work in?
Your experience doesn't align with those of us who work in the application security and identity management space, yet you seem to be speaking so confidently about it.
Sailpoint (a large enterprise SSO/SAML vendor) IPOed at $1B in early November. I think they are probably smaller than Ping Identity.
Don't use SAML if you don't have to (it's horrible to program!). But it is very widely adopted.