Vorlons vs. Shadows
It was the dawn of the third age of mankind, ten years after the Earth/Minbari war. The Babylon Project was a dream given form. Its goal: to prevent another war by creating a place where humans and aliens could work out their differences peacefully. It's a port of call, home away from home for diplomats, hustlers, entrepreneurs, and wanderers. Humans and aliens wrapped in two million, five hundred thousand tons of spinning metal, all alone in the night. It can be a dangerous place, but it's our last best hope for peace. This is the story of the last of the Babylon stations. The year is 2258. The name of the place is Babylon 5.
Over 25 years ago JMS gave us Babylon 5. One of the first, if not the first, TV series with a pre-plotted beginning, middle, and end. There were lots of low-budget special effects, extensive use of CGI, cheesy costumes and some really interesting haircuts. There was also some pretty deep introspection.
At its heart, B5 was about a group of races coming of age together and telling the previous generation to get out of the way. In the show the old generation was primarily represented by two races, the Vorlons and the Shadows. The Vorlons framed the world in terms of "Who are you?" A place for everything and everything in its place. The Shadows on the other hand framed things around "What do you want?" If you wanted something then just do it. Do whatever you want and let the chips fall where they may.
The thing is, you can't have a sustainable system with either one of those frameworks. You need both, working in concert, to create a dynamic, evolving system. But what does a 25+ year old space opera have to tell us about software development?
One place where you can see the interdependence of those frameworks is in security. You'll often hear security folks talking about AuthN and AuthZ but what are they and what is the difference? AuthN is authentication, or "Who Are You?". AuthZ is authorization, or "What do you want (to do)?". And it's the interplay of those two things that gets challenging.
Consider the Hadoop ecosystem, HDFS in particular. The HDFS folks did a really good job of separating the two. A flag in a config file on the namenode enables authentication, and a separate flag enables authorization. HDFS authorization is modeled after traditional Unix file perms, and HDFS authentication is Kerberos based. What this means in practice is that almost every HDFS cluster you encounter has AuthZ, but no AuthN. And mostly you never know.
Because as long as everyone is honest and never lies about who they are things work fine. You can only read/write/modify the things your user has access to. It's easy for frameworks and middleware to act on behalf of the user with the authorization of the user. You get a lot of the benefits of security, or at least you think you do. Because with a little bit of research you can pretend to be anyone and do anything you want.
The opposite is AuthN without AuthZ. In that case, again, if your users are trustworthy and never make a mistake you're golden. Plus, you get a reliable audit trail. So when someone makes a mistake you know exactly who did it. You just have no way to prevent it, because everyone can do everything.
If you want real security you need both. AuthN and AuthZ. And I'll contend that AuthN is harder and more important. Because if you can't be sure who you're talking to, and the other side can't be sure who they're listening to, it doesn't matter how carefully you've checked to make sure the caller really can do what it wants.
