[deergomoo]

I feel like this article misses the point that SSO is intended to benefit organisations, not users. The selling point is that if an IT department can point a new service at Active Directory or something, it's going to be much less of a headache than managing n sets of user credentials.

[hinkley]

I can think of two times in my life where I even considered the possibility that one of my peers would do something malicious on their way out the door, but management worries about this all the time.

On the one hand, Precautionary Principle. The costs of being wrong - and having to explain it to the Board - are just unimaginable. So sure, if you want IT to have a way to push a button and block someone out of the entire network in the time between when their boss says, "Hey, can we talk" and the office door goes 'click', then centralized credentials at least can be somewhat atomic. Session caching, to make this arrangement perform, undermines that immediately of course.

On the other hand, when someone accuses you of something way, way out of character, we learn as we mature that it's fairly likely this person did some mental arithmetic that went, "What would I do in this situation?" and that popped out. The person who accuses you of stealing their mug at the drop of a hat may have a passing fancy with stealing mugs themselves.

So we learn that in perhaps 95% of cases, non-sequitur suspicions are either the product of the mind of a suspicious person, of someone who is jaded by bad experiences (steal someone's lunch enough times and they will start accusing random people), or of someone who deep down knows they kind of deserve whatever is about to happen.

So it troubles me a bit how quickly the C Suite prioritizes having a giant switch to lock people out.

I've developed a nervous habit of any time I hear someone getting 'talked to for a second' or suddenly a bunch of 1:1s show up, of cleaning up my computer a little bit, then my desk. Rarely do I have anything that is worthy of cleaning up, but it doesn't hurt and gives me somewhere to put some of that feeling of impending doom. If I had a bad experience of having to clean out a messy desk, I don't remember it very well, but I'm sure it's happened. I know the first time I quit I learned not to try to take everything home on the last day. Somehow my stuff always ends up being bulkier than I estimate.

[IncRnd]

> I can think of two times in my life where I even considered the possibility that one of my peers would do something malicious on their way out the door, but management worries about this all the time.

Because employers see how some employees act as they depart, even though they don't act similarly around their coworkers. Employers also see trusted employees smile and leave for competitors even after signing that they would not do that. Employers are right to suspect departing employees, because some steal information or otherwise cause issues before they leave.

> So it troubles me a bit how quickly the C Suite prioritizes having a giant switch to lock people out.

I've seen dozens of systems that had to be accounted for when an employee left. Almost all of those systems required separate action to remove the departing employee, plus follow-up checks that sometimes had to be from humans.

It only makes sense to have your employee separation procedure get automated, and during automation it makes sense to communicate with one system instead of communicating with 30 systems that each respond in different ways - some of which require human intervention.

[feoren]

> Employers also see trusted employees smile and leave for competitors even after signing that they would not do that.

Employers who ask their employees to sign immoral and usually illegal non-compete clauses deserve whatever they get, honestly. Employers should expect their employees to go work for competitors when they leave. Where else are they going to go work, but companies with similar operations? An ecology management company fires and ecologist and they clutch their pearls when that ecologist goes and works for another ecology management company, instead of McDonalds!? Gasp! The nerve of that person!

Don't want your employees to go work for a competitor? Don't treat them like shit.

[IncRnd]

> Employers who ask their employees to sign immoral and usually illegal non-compete clauses deserve whatever they get, honestly. Employers should expect their employees to go work for competitors when they leave.

That's my point as to why employers want to immediately stop access to employees who leave for competitors.

> An ecology management company fires and ecologist and they clutch their pearls when that ecologist goes and works for another ecology management company, instead of McDonalds!?

You can word it that way, but what can and does happen is that employees leave and steal confidential processes or information to boost their own value at a competitor. Many people agree with you, until they start their own company and theft happens to them, draining their work straight to a competitor.

[Bellend]

If that was the goal, wouldn't you do that in advance anyway before any suggestion you were bailing?

[thwarted]

Sure, but it doesn't always happen like that.

You're in sales at a company in a highly competitive space and are exited. You're not the kind of person to premeditate taking anything with you, perhaps you left on good terms. You join another company and someone there asks you for the book of business or sales leads you were working on that the previous company. Oh look, your login to the CRM system is still working, and you can get a glimpse of information that you shouldn't have access to as a non-FTE. It seems benign, so you copy down a few phone numbers and email addresses. This isn't an academic example.

This wouldn't even be a possibility if the account was locked down immediately. It's obviously much more difficult to control access to information while you are employed (this is a subplot of Snowcrash, afterall), but immediate lockout isn't meant to mitigate that risk. It's meant to mitigate risks from an account being active that shouldn't be.

[mhink]

> You can word it that way, but what can and does happen is that employees leave and steal confidential processes or information to boost their own value at a competitor.

I mean, couldn't you make an argument where that's just capitalism at work? If Firm A is going to be competitive, they'll need to compensate their employees well enough that Firm B doesn't have the ability to poach. An employee with a considerable amount of stock in Firm A is gonna think twice before they devalue their shares by running to a competitor.

> Many people agree with you, until they start their own company and theft happens to them, draining their work straight to a competitor.

Again: tough luck.

[phh]

> Because employers see how some employees act as they depart, even though they don't act similarly around their coworkers

It's fun, because in my experience, departing employees are always playing ball, while employer starts doing stupid things.

In France, we have 3 months (!) of resignation notice (and it usually really lasts 2). I've always seen departing colleagues still working the whole notice. However managers start asking stupid things "please prepare demo for this prospect, it should take you one month and a half, so 2 weeks to spare!", "hey we need this feature, you're the only one who can do it, please code it before you leave", but rarely "write documentation for everything you did".

> Employers also see trusted employees smile and leave for competitors even after signing that they would not do that.

What? Such clauses actually exist and are actually used?

In France, such a clause requires (ex)employer to pay at least 50% of salary during the period where the (ex)employee isn't allowed to work for competitors (I can't see how this can be a fair agreement without that compensation), but companies pretty much never enact those clauses, because well, they don't care about employees going to the competition /that/ much

[kelnos]

> What? Such clauses actually exist and are actually used?

Unfortunately it's pretty common in the US, though in some states (like California) such clauses are illegal and unenforceable.

I'm always torn on these sorts of labor requirements/protections. I think anti-compete agreements are gross, but I also wouldn't want to be subject to a mandatory notice period of any kind, let alone 3 months.

[Johnny555]

I can think of two times in my life where I even considered the possibility that one of my peers would do something malicious on their way out the door, but management worries about this all the time.

Proper offboarding protects you too, not just the company. If you leave the company and someone compromises one of the 27 hard-coded credentials left behind on various machines and services, then it puts you under suspicion.

In companies where I do have hard coded creds (including shared passwords), when leaving a company, I compile a list of all of them and send it to my manager and tell them to make sure they are all disabled.

[ghaff]

Yep. It's like sharing passwords to important personal accounts more generally. Sure, the main reason you don't is that stuff can happen in relationships and people can end up doing things you didn't think they would. But a secondary reason that if something does happen in an account that you've shared a password with someone, it's hard not to have at least a glimmer of suspicion.

[xyzzy123]

Ignoring the "actual security" angle for a minute.

When you have thousands of accounts and dozens to hundreds of services, manual management just stops being practical.

Most large orgs are subject to one form of compliance or another, and it's inevitable that at some point you have to prove to an auditor that you have onboarding / offboarding processes for everything as that's in their checklist.

This is difficult to prove "at scale" and removing tons of per-service UAR processes is the main value. Each service is an opportunity to screw up - forget to document the process, forget to execute the process, (my favourite) forget to record that you executed the process, or execute the process wrong.

The alternative to automation in a big company is that accounts get left dormant for years.

[dasil003]

You're overly focused on individual behavior of ex-employees, and overestimating the amount of thought the C Suite is putting into the matter.

The risk does not come primarily from disgruntled employees doing bad things—there's already a huge legal deterrent to that since they know exactly who you are. The bigger risk is what can happen when credentials are stolen by actual criminals. This is context dependent, but scales with the number of employees times the number of accounts, the latter of which has trended up dramatically as cheap B2B SaaS has proliferated.

What happens when a laptop is lost? What happens if a DB is hacked and users had reused passwords? How do we know who even has access to what when teams self-administer access control? These start to become real security problems at relatively modest scale even if we assume every employee is a saint.

Even leaving security aside, the management of accounts starts to become a significant pain point in the low hundreds of employees and so it will typically be the IT team that pushes for SSO first well before compliance comes into the picture.

[paranoidrobot]

As the de-facto Security team - the main concern for me isn't so much "lock everyone out immediately" aspect, it's the reduction in the number of sets of credentials for people. It is a benefit in the onboarding/offboarding process, too - it's one less thing you need to go in and manually turn off accounts.

People suck at remembering passwords, and even if you go and give them Password Manager tools like 1Password/Lastpass/whatever, they'll still tend to re-use the same password they use for their personal email, and that random service that recently got pwned.

It's worse when they have credentials like AWS IAM Keys that are while not difficult, are inconvenient to rotate. Those are likely to just sit around on someone's machine and get leaked inadvertently in logs or test code.

[jordanbeiber]

It’s just bad practice having accounts scattered through bunches of systems that shouldn’t be used anymore.

It’s often a licensing issue, and definitely a security issue.

Either you maintain this manually - proper time consuming chore at larger companies with many systems and applications.

Or write automations to manage it. Better, but still a lot of work and not always technically possible.

Or you hook as many of these systems as possible up to an SSO solution backed by some kind of identity provider.

This grants many benefits for everyone during the lifecycle of systems and its users - sysadmins, it-support, infosec but perhaps most of all the end-users.

As a manager myself I first and foremost think about how the on-boarding works: is it smooth, and are new hires gaining access to the systems they need without 15 calls to the service desk.

[Too]

Hah. If you worry about malicious employees I can tell you that SSO is the opposite of a solution.

Most SSO integrations have very bad Single-Sign-Out design, if any at all. So as long as the token in your session has not expired yet, you have full access to resources, even if account is blocked in the Id Provider.

[rtpg]

ignoring all of this, the fact that you can use SSO and then people will have access to most services without having to login to most of these services (loads of services have "anyone in this G Suite org can get into your account") is a godsend.

No more chasing around for each service figuring out who is the admin for what.

[Aeolun]

No, SSO also helps me. Having only one password to change is really nice. It’s the SSO process that annoys me. Between all the redirects and duplicate information, signin takes 4 times longer than user/password auth.

[remram]

My company's single-sign-on got upgraded with mandatory 2FA a couple years back, and somehow requires it every time. It's really more of a non-stop-sign-on, I probably do it 10 times on any given day (including waiting for the SMS, etc, I wonder how much this one poorly-configured service costs them).

[toastal]

It would also help an adversary that only needs to know your one password.

[dlp211]

Which is why we also use 2FA. You are using 2FA right?

[toastal]

Implying 2FA is bulletproof? I use separate 2FA and passwords for everything.

[enraged_camel]

I don’t think the OP implied that 2FA is bulletproof…

[mooreds]

I also don't think that the client certificate solution that is trumpeted at the end (for which I don't blame them, content marketing has to content market) is a great option. From the post:

"The UX and tech for PKI Infrastructure isn’t great, and the client UX sucks."

Guess what, it has for years and years. Deployment is hard. Creating certs at scale for normal users has been available for a long long time, but no one has done that.

I think that a more fruitful approach would be to go the webauthn path, and tie into the browser/OS for support (as mentioned in the article). Boom, deployment solved (https://caniuse.com/?search=webauthn has the list; it's most major browsers on mobile and desktop--the only one missing that I'd love to see add it is FireFox on Android).

Now you need to tie into the application and I don't want to diminish that effort. But many apps use libraries or auth servers, so your surface area for deployment is far smaller.

[codebje]

Having persisted with user authentication X509 for years, I can in fact tell you the UX got _worse_ over time. We wound up sometimes making key pairs and certificates for end users and emailing them because browser enrollment is so shonky.

[tootie]

Not just miss the point but isn't also just incorrect? SSO typically doesn't require you to login more than once a day. Unless they explicitly set a policy to expire sessions really fast. If you have Okta/Auth0 or the like in your enterprise it should cookie your session in the identity provider and automatically admit you to anything gated by that identity provider

[kelnos]

My former employer set expiration at 3 hours. It was super annoying.

[number6]

Yes. I sign on by typing my email address and then... redirect... redirect... signed in. Guess the interface could be nicer but generally it's nice

[throwawayboise]

That's centralized identity management, not single-sign-on. Single-sign-on is/was supposed to mean you sign on once. I've never seen it actually work.

[jodrellblank]

Single Sign On works beautifully in the Windows environment. Logon to one workstation, access any server's file or print shares, SQL server, IIS websites, and tons of third party software without any logon prompts but still with granular permissions.

One of those things people who say "I don't understand why anyone uses Windows" don't understand. Something so pervasive and convenient that "we" the industry have given up in moving everything to the web, along with standard menus, ubiquitous keyboard accelerators for menus and dialog boxes, scripting with the likes of COM, ActiveX, AppleScript, or embedded Python/Lua, local snapshots or volume shadow copy, tools like DNSpy and AutoHotkey and SysExporter able to introspect into running programs and their windows and system controls (and they generally weren't obfuscated javascript inside), being able to see different programs in task switchers without them all being wrapped in a web browser.

It was a different and in many ways better world 10-15 years ago.

[Jenk]

SSO can be both Single Sign-On, or Same Sign-On.

The latter is the LDAP integrated thing - (re)using the same credentials for multiple/disparate services, controlled centrally.

The former ("true" single sign-on) is logging in once and accessing everything from there.

FWIW there are single sign-on services out there. Okta is used by my current employer, I log into the Okta portal and it has links out to all of the services it supports from there.

[hinkley]

SSO is the source of truth, and centralized identity is the system of record. They go hand in glove. It's not a non-sequitur so much as a tangent.

[gkop]

for the benefit of others (I had to search it): https://www.linkedin.com/pulse/difference-between-system-rec...

[Spivak]

Yeah, the manifestation of "LDAP Integrated" still means you have to sign into every single service, it just uses the same credentials.