When I posted "The Subtle Oppression of the Code Library," I said I would explain later why I had to go through all the mess I described in that entry. That time has come.

Last year -- I think it was last year, time has no meaning anymore -- $EMPLOYER had a major data exploit. Or maybe it was a major phishing incident. I forget which. Maybe both. It affected one of the parts of my part of $EMPLOYER, which is bad, because it made us look bad ... but instead of doing what I thought would have been the correct thing to do, which would have been to pick up everybody in Group That Got Phished (or Exploited), shake them by the shoulders until their eyballs collided, shout LEARN SOME GODDAMNED SECURITY POLICY AND DATA DISCIPLINE AND JUST FUCKING COMMON SENSE in their ears until their eardrums withered, send them off for security-policy training, and move on ...

Uh, sorry, lost my sentence there somewhere ... as I was saying, that's not what they did. Instead, $EMPLOYER's central IT department said "That's it, there have been one too many incidents like this, we are changing how we handle security and if that penalizes the people who were doing it right to begin with, too fucking bad."

This is and has always been my gripe with computer security, and web security in particular: the people who are doing it right always get penalized for the sins of the people who aren't. Because you can't keep your passwords secure, I have to deal with ridiculously Draconian password policies. Because you don't know how to keep your database locked up, I have to wonder who's stolen my information from your files this week, every week. Because you can't spot when you're being scammed, I have to clean up your messes.

What I mean is, there are actually two groups of bad actors here: the assholes who have nearly destroyed email with spam and who attempt to hack and break and exploit every system they can find, and the idiots who don't know how to lock up their computers or protect their passwords or know when something smells phishy ... and I dislike the second group only slightly less than I dislike the first group.

My $EMPLOYER has a single-sign-on (SSO) method, which, despite my griping about it years ago when I had to implement it, has turned out to be a pretty good idea. I don't have to remember seven hundred different passwords for all the applications and sites at my workplace; they all go through the same gateway. That gateway switched to requiring two-factor auth (2FA) a while back. In practice what that means is "you can't just use your SSO password to get in, you also have to do a second verification step somewhere else," and for 99.99999% of the users, that somewhere else was their phone, and the 2FA handler was a program you may have used called Duo.

All 2FA is a pain in the ass inflicted on us by people who can't keep their shit locked up, but Duo wasn't bad. It had reasonable session storage (that is, "I remember you are already logged in on this machine, I won't ask you for second auth again just yet, maybe in a week or so") so it wasn't constantly chirping and asking you to tend to the phone. (I log into websites and tools at $EMPLOYER dozens of times a day.)

However, now that central IT was cracking down, they decided to change to a different 2FA provider, called Okta, because Okta was capable of handling "passwordless" auth.

Now, there's a reason that word is in quotes, and I wish I didn't have to put it in quotes. When "passwordless" first became a buzzword, my initial reaction was that it was the biggest crock of shit you ever heard. Wandering through the articles and documentation about it, which were eighty percent gibberish and twenty percent buzz, did not contradict that impression. But "passwordless," when you actually see what it means in implementation terms, is not actually all that dumb an idea. It's also not passwordless.

What passwordless really means is that you establish trust in devices, rather than trust in the user. A normal password system places all the trust in the person providing the password -- they could be anybody, they could be anywhere, but as long as they have that password, they can get in. And that is kind of a problem in a world where people can't keep their fucking passwords secure (I'm sorry, I'm sorry, I'll try not to fly off the handle again).

With passwordless you have to jump through some considerable hoops to register trusted devices. Now, of course, someone could still steal your phone or computer and use that and you'd have the same problem -- except that, to establish that trust, each of these devices must have some way of independently verifying your identity.

Back in the days of the initial hype and buzz, the idea was that that verification was going to be biometrics. Notably, facial recognition. However, I don't use facial recognition anywhere. The camera on my laptop is "permanently out of service" (it isn't, but that's what I tell people who don't get to see my ugly face in Zoom meetings). And on the phone, hell will freeze over because if you turn it on, then the cops can unlock your phone easily without your consent just by slamming your fucking face against it, and because AC actually AB, it could happen to you.

So I don't use biometrics. I do, however, now have three devices that have established Okta trust. How? They are locked with PINs. Four-digit PINs. Which is deemed good enough.

Now, the punchline: I have always used password lock on all my Windows computers. Yes, even my personal ones. It's just good security. (Look, look, I didn't fly off the handle that time!) So, on two of these machines, I had to change from using a much longer, mixed-character password to a four-digit PIN. (My phone, which also always has lock enabled, was a four-digit PIN to start with.) This is an improvement in security? But whatever. It's a lot faster, anyway.

I realize none of this is about my code change. I'm about to get there.

So, in the old system, I used a method of slinging the login data around called CAS. But Okta doesn't accept CAS. They consider it insecure or outdated or something, I never could get an answer on that.

So I had to change from auth code that used CAS to auth code that used SAML, a different protocol ("protocol" means "method of slinging shit around").

And this proved to be incredibly frustrating.

As I said in "Subtle Oppression," my method when Doing New Things Wot I Ain't Done Before is to find out everything I can find out about it, dig down to the guts, find the ten lines of code that actually do the thing, discard all the surrounding bullshit and cruft and overhead, and just implement those ten lines on my own. Not only is it better for maintenance in the long run -- "maintenance" meaning "me, trying to figure out WTF I did ten years later" -- but, as I said in that entry, I strongly believe that when you use code, you need to understand what it is doing.

The problem with SAML was I could literally find no coherent information on what it was doing. Every last bit of information and documentation I could find was one hundred percent worthless. Gibberish. Nonsense. Garbage.

I have never had that happen before. I've had topics where I had to do a lot of digging, but usually I do manage to get down to the one scrap of real information that tells me what's actually going on. Or find someone else's code example to take apart. Not this time. The first two code setups I tried flat-out didn't work; the one which I did eventually install works, but is so overdesigned (see that entry) that it could take me years to dig down to the guts.

Nonetheless, I did get it working, and once I did get it working, I realized (predictably) that there is Far Less There Than Meets The Eye. Predictably, because that is usually the case. Now I'm convinced the obfuscation levels here are deliberate, so that people won't know how little is there.

(The only real wrinkle with SAML as a protocol is that at various points you must encrypt/decrypt the message packets via SSL, which means, among other things, that you must have a site certificate and know enough about the maintenance and upkeep of that certificate to know where your encryption key is. Fortunately, I do.)

It was not, ultimately, several days of wasted time. The system as currently implemented is better and more secure than the one I had before, and it's a bit more flexible if I need to move things around. So, no real complaints on my part -- about my own implementation.

But.

The entire organization was forced to move to Okta auth. All of $EMPLOYER. And $EMPLOYER is quite lorge. And for various reasons, the central IT identity-management department insisted that only a small handful of IT personnel from each unit of $EMPLOYER could submit and track and followup on auth "migration" requests. Which had to be filed with every single SSO-using app or website.

That meant that three of us were handling all the applications for our entire unit. This was not trivial. I only handled the third-party stuff (e.g. "Hey, you know that tool from an outside vendor you rely on? Well, it may have to change its auth code. We need to contact them and get the ball rolling on that"), and I had something like twenty applications to file and track and nurse all the way through the process. My co-worker, who handled our web sites, had hundreds.

All of this had a deadline of the first of June.

So if you talk to me in other places, and I seemed unexpectedly work-frantic the last two weeks of May, now you know why.

(We made it. We have a couple of stragglers, but nothing of serious concern.)