←back to thread

312 points campuscodi | 1 comments | | HN request time: 0s | source
Show context
Diggsey ◴[] No.43375000[source]
I recently had to implement SAML and this headline does not surprise me in the slightest.

The SAML spec itself is fairly reasonable, but is built upon XML signatures (and in turn, XML canonicalization) which are truly insane standards, if they can even be called such.

Only a committee could produce such a twisted and depraved specification, no single mind would be capable of holding and combining such contradictory ideas.

It would be so simple to just transmit signatures out-of-band and SAML would be a pleasure to implement.

replies(3): >>43375038 #>>43375229 #>>43375725 #
TZubiri ◴[] No.43375725[source]
Is SSO salvageable at all? It seems like the idea of just logging into different accounts is fine.

Also just the idea of connecting your accounts together such that you can get megacompromised is foundationally riskier

replies(4): >>43376069 #>>43376167 #>>43376289 #>>43378267 #
blincoln ◴[] No.43378267[source]
The biggest problem with having separate accounts for everything is that a lot of the users will make their own "wish it were SSO" by setting their passwords in the systems to the same value. Then, when the weakest system is exploited, the attacker gets credentials that are valid across the organization. Yes, they should be using a password manager with unique, random passwords for each system, but realistically a good chunk of larger organizations' staff are not going to do that.

Some other headaches:

Having decentralised authentication means that onboarding and offboarding need to have a bunch of tedious manual steps, or custom automation.

Whoever does user support for the organization has to be trained to reset passwords/unlock accounts in a hodgepodge of systems.

Any security controls the organization wants to implement need to be reimplemented or approximated in a bunch of different systems. E.g. if there are regulatory requirements for account lockouts, time between explicit reauthentication, etc.

It becomes much more critical to collect the authentication logs/event data for all of those systems, and harmonize its formatting with everything else so that the security ops team isn't maintaining separate monitoring/alerting rules for every system.

For large-scale systems, there are also at least theoretically performance advantages to the kind of signed ticket approach that SSO mechanisms tend to use, versus having to do database lookups of session IDs or verify a password. It's possible to do that without SSO, but if you're going to the trouble of implementing that kind of mechanism, you're most of the way to having SSO anyway, and might as well just finish the job IMO.

replies(3): >>43378708 #>>43378719 #>>43380223 #
1. TZubiri ◴[] No.43378719[source]
"If there are regulatory requirements for account lockouts"

Then the vendor can impmenent those? The need for control might be a source for greater risk.