I remember when we implemented AAA (Authentication, authorization, and accounting) at Amazon, which enforces a central authority and secondary encryption on all inter-service communications. What was great about it was there was several services that simply refused to integrate and we had to let them have unfettered access to other services. To cover up this issue, we simply ignored it. Hasn't been a problem yet.
I dig it, and I suspect this might be a big part of my next role given that I’ve always been the “Active Directory/AAD/Entra/IAM/Okta” guy. I like my directories lean, clean, tightly integrated, highly available, and with as few “branches” from the centralized authorization pipeline as possible - so all of this seems to hit my core strengths.
SSO being the single point for security is the entire point.
Compare that to every application having a login mask and querying active directory. There are so many more points of failure. If even just a single application has a vulnerability, then an adversary can just log the credentials and hope he finds one with elevated access rights.
It is vastly easier to manage and strongly secure that single point, for administrators, security professionals and users.
You can enforce a much higher security credential, as it only has to be used once. You don't have to worry that your users are re-using the same weaker credential across multiple independent services (hint: they will).
Using SSO does not mean you have no defence in depth. You should always consider defence in depth in the context of the overall system. It's not a strong reason IMHO against centralising or simplifying one type of control.
I can see why this is an unpopular opinion for IT administrators and security responders alike, but I totally agree. Centralised authentication means if an attacker can compromise the SSO layer, they've compromised everything. This is far less desirable than an attacker having to compromise each system individually.
I think most often these days the users themselves are the centralized point of entry for attackers—a focused attacker is not necessarily going after every application a company uses and trying to breach it individually, but instead trying to compromise a user who has access to all of them.
So in that scenario, centralizing auth is desirable because you don’t have that user holding dozens of weak passwords, and you can monitor access and use heuristics to lock the user out of everything automatically if, say, they access the SSO portal from an unexpected IP. You can also always set things up to require re-auth or MFA whenever someone actually signs into something through the IdP, as an extra layer on top.
Especially when it's "modern" SSO aka browser-based crap which means the same software that you use to browse untrusted sites on a daily basis is also the one in control of your entire SSO session.
I’ve always thought of Kerberos as a centralized authentication system, to establish users’ identities.
Authorization, in the sense of deciding to allow or deny a requested action by a known user on a specific object, remains distributed, even with Kerberos. For example, a Windows file server, having received a Kerberos ticket showing a user’s identity and security group memberships, consults its own access control lists to determine what operations to allow on files and directories.
The article here argues that those authorization decisions should also be centralized, presumably using the sponsor’s “cloud-native authorization platform,” instead of being made within each service or application.
I remember when we implemented AAA (Authentication, authorization, and accounting) at Amazon, which enforces a central authority and secondary encryption on all inter-service communications. What was great about it was there was several services that simply refused to integrate and we had to let them have unfettered access to other services. To cover up this issue, we simply ignored it. Hasn't been a problem yet.
> Hasn't been a problem yet.
You mean, refusing to integrate was the right decision after all?
I work in a "zero trust" environment and it kinda sucks.
Latency and hitting a fob on every connection is not fun
I dig it, and I suspect this might be a big part of my next role given that I’ve always been the “Active Directory/AAD/Entra/IAM/Okta” guy. I like my directories lean, clean, tightly integrated, highly available, and with as few “branches” from the centralized authorization pipeline as possible - so all of this seems to hit my core strengths.
Guess I’ve got some weekend research ahead of me!
SSO is a single point of failure for security and violates defense in depth. SSO is a gift to the adversary
SSO being the single point for security is the entire point.
Compare that to every application having a login mask and querying active directory. There are so many more points of failure. If even just a single application has a vulnerability, then an adversary can just log the credentials and hope he finds one with elevated access rights.
Your example is almost equivalent since even if you implement SSO on every of those apps, this doesn't mean that every app has integrated it well.
This is a very one sided view of SSO.
It is vastly easier to manage and strongly secure that single point, for administrators, security professionals and users.
You can enforce a much higher security credential, as it only has to be used once. You don't have to worry that your users are re-using the same weaker credential across multiple independent services (hint: they will).
Using SSO does not mean you have no defence in depth. You should always consider defence in depth in the context of the overall system. It's not a strong reason IMHO against centralising or simplifying one type of control.
I can see why this is an unpopular opinion for IT administrators and security responders alike, but I totally agree. Centralised authentication means if an attacker can compromise the SSO layer, they've compromised everything. This is far less desirable than an attacker having to compromise each system individually.
I think most often these days the users themselves are the centralized point of entry for attackers—a focused attacker is not necessarily going after every application a company uses and trying to breach it individually, but instead trying to compromise a user who has access to all of them.
So in that scenario, centralizing auth is desirable because you don’t have that user holding dozens of weak passwords, and you can monitor access and use heuristics to lock the user out of everything automatically if, say, they access the SSO portal from an unexpected IP. You can also always set things up to require re-auth or MFA whenever someone actually signs into something through the IdP, as an extra layer on top.
Especially when it's "modern" SSO aka browser-based crap which means the same software that you use to browse untrusted sites on a daily basis is also the one in control of your entire SSO session.
If no conditional access rules are set up then yes. Same way relying on just a firewall for network security is a single point of failure.
So then you are relying on access rules being set up perfectly. Which may be actually more difficult than alternatives.
What are the alternatives?
What are the alternatives in case of SSO?
Not SSO?
I'll consider it!
i don't follow you there. what do you mean?
i came to a stark realisation after abandoning youtube premium that i may one day be banned for adblocking
due to nearly all of my authentication being done through google i would lose nearly all my digital content
I’ve worked hard not to use “Login with XYZ” buttons over the years for reasons.
My email address is even using an owned domain so that I have a better chance of getting it back if my email provider cuts me off.
No mention of Kerberos? That's been doing centralized authorization for decades. It's built into Windows, even.
I’ve always thought of Kerberos as a centralized authentication system, to establish users’ identities.
Authorization, in the sense of deciding to allow or deny a requested action by a known user on a specific object, remains distributed, even with Kerberos. For example, a Windows file server, having received a Kerberos ticket showing a user’s identity and security group memberships, consults its own access control lists to determine what operations to allow on files and directories.
The article here argues that those authorization decisions should also be centralized, presumably using the sponsor’s “cloud-native authorization platform,” instead of being made within each service or application.
Kerberos does support authorization. Windows supports this at the Windows group level.[1] Finer grained control requires something else.
Outsourcing "authorization" to an external service comes across as a really bad idea with huge "backdoor" potential.
[1] https://security.stackexchange.com/questions/36072/what-is-i...