If this is interesting to you but you're iffy about setting up another directory service or having AWS be your central list of identities for all your apps, we're open sourcing The Identity Mutilator, a Golang SAML IdP, in a couple weeks. It's self-contained (for now) so doesn't depend on AD or LDAP --- just Postgres --- and runs just fine in a tiny Docker container.
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?
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.
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
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.
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.
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?
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!
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.
* 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):
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.
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?
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.
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...
(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!
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
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.
I tested this out just yesterday. It was fairly easy to set up - enable SSO, create a Directory Service, add a management EC2 instance, and you're pretty much up and running.
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.
Wonder if and when we’ll see decent Excel/Word replacements from Amazon, perhaps coupled with a thin Linux distro. At that point you’d be able to completely do away with Microsoft in many organisations, and Amazon could simply gobble up those dollars. They’ve got enough money they could make it work.
Never. Can't happen. See, while it is true that 80% of the people only use 20% of the features but it is not the same 20%! The only viable Excel replacement would need to have the exact same functionality pile.
Google has been working on that for ~10 years, but still doesn't have a full replacement. Though it's about 80% there - we're a Google Docs office, but about 20% of employees (mostly finance and marketing) need real MS Office products.
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.
This. It'd be a hell of a project for Amazon, considering that they've done nothing in this direction as far as anyone knows, while Google has been working at it for a decade+, and is still a long way from a full replacement.
Decent Excel/Word replacements are a hard problem to solve. OOo/LibreOffice and Google Docs have been at it for a while, and aren't there. Meanwhile, I can't imagine wanting an Amazon office suite. I've used their video and music streaming services, and holy wow, the usability is awful. Their photo storage service is so pants compared to Microsoft or Google in terms of usability. I shudder to think what an Amazon equivalent of Google Docs would be like.
It isn't. But what do you replace it with? Better solutions are likely to only cover a fraction of use cases, so they really need to be stellar to win over users.
It's about the data, and the better solution is to use a database. The problem is that retraining everyone from Excel to use some sort of SQL frontend is not a small problem, and neither is getting the company to commit to operating a data warehouse.
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.
But would you though? They only integrate with AD and looks like they are trying to address a gap that AWS has with managing access to resources. These other IdaaS have a lot more functionality.
PSA: Remember to keep your contact data up to date when using 2FA.
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
I'm a little confused at the third-party thing - is AWS generating SAML assertions based on your internal AD that it sends to other websites like Box or Office 365 or Slack? Why would you want AWS in the loop?
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.)
AWS SSO looks to be an IdP (identity provider) which maps artifacts from AD like ldap groups to entitle access to trusted service providers.
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.
Nice to see this, one that Google Cloud always had a nice advantage with seamless identities when using G-Suite for productivity and email. I'm expecting the next version to integrate deeper into workspaces/docs/mail so that they reach parity with the other clouds here.
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?"
Are you talking about the `gcloud compute ssh` stuff? I wonder what magic google is using to grt public keys on boxes. I’d think there’d have to be some coordination with the machine image being run for this to work, so it wouldn’t be something Amazon could just turn on for everybody. You could probably roll your own using an SSH CA though.
Daemons running on user VMs? Or is ssh terminated in a bastion and forwarded somehow?
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?
Kerberos / Needham-Schroeder usually refers to an authenticated encryption protocol that uses symmetric keys (shared secrets). It lets two parties who have never communicated, but who both mutually trust some third party, establish one another’s identities and negotiate a symmetric key for encrypted communication.
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.
They did not reinvent the wheel here. This is just the SAML 2.0 standard. The only consequence of launching this product is that there is another competitor on the SSO market, which is a good thing I think.
Technically true. But when it comes to writing a website, do you plan to add "SAML 2.0 auth" or "Google SSO, Facebook SSO, Amazon SSO"? I think all need to be configured, tested and debugged, even if they are based on the same communication protocol.
Update: I realize now this is Amazon offering SSO services, not just supporting SAML / Federated authentication.
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.
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. :(
I want the ability to use Google/G-Suite as an identity provider to log into multiple AWS accounts. We have dev and prod workloads that run in completely separate AWS accounts. I want to be able to use Google SSO and the ability to select which AWS account to log into
I don't have access to a G-Suite account to test this with, but afaict you should be able to do this by just adding each AWS account in turn and giving it a different Application Name and description in the G-Suite interface.
While this will undoubtedly make a lot of people's lives easier, I'm a bit hesitant to use SAML just yet.
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).
While there are a thousand reasons to hate SAML, your concerns are not accurate.
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.
> 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.
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.
It’s new if you’re not informed about identity as a technology area. Some people in that space consider SAML2 to be outdated!
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.
It's outdated enough that even the Enterprise vendors are starting to look at OpenID Connect to replace it.
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.
> 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).
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.
We build non-technical SaaS software targeted at anywhere from pre-IPO to Fortune 25 companies. I'd say SSO is a hard requirement for at least half of our new customers (which to them means SAML 2.0 - ADFS, Azure AD, Okta, OneLogin, etc). And this number has been rapidly growing in the last 2 years as companies become comfortable with using cloud-hosted SaaS solutions rather than on-prem.
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.
You might want to double check those facts. There are probably billions of SAML users.
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!
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.
There's a lot of FUD here, starting with SAML being new. SAML 1.0 was ratified in 2002, and SAML 2.0 was ratified in 2005. Compare that to OAuth, with version 1.0 published by IETF in 2010 and version 2.0 in 2012. Likewise, there are multiple, mature SAML implementations including the open source Shibboleth project, which started in 2000, and SimpleSAMLphp, which started in 2007. I consider Shibboleth the gold standard, against which I measure all SAML implementations.
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.
