If you work in an office environment, tell me if this sounds familiar.
You’re issued a computer for your everyday tasks. And on your first day of employment, you’re also issued a corporate e-mail address and a login ID.
Your e-mail address is the official address that any other corporate employee, or anyone who does business with your organization, will send e-mail correspondence to.
More importantly, your login is what you will use as your primary digital identification.
This login ID will be your all-purpose identification you use to get access to any software application, website, database, or any other password protected file in your organization.
You’re going to be using that login a LOT. You’ll need it to sign into your corporate e-mail system. You’ll need it for any software application, website, or database system. All these applications, databases and files typically challenge you with some sort of login window where you enter your login ID and the password associated with your login.
This is all well and good. After all, your organization wants to make sure there is always a searchable record of WHO does WHAT and WHEN, and the only way to get that information is through the use of applied security conventions like passwords and logins.
Logins, passwords, and digital security has been with us since the earliest days of computing and software development.
And although the specific form of technology will always evolve and change, the general need to bake security into applications will always be needed.
But how many of you struggle to keep track of all the passwords and login IDs you need for your day to day activities?
Perhaps your e-mail application requires one specific password. And, of course, any access to remote servers needs their own unique passwords.
Then let’s not forget all the custom web applications you use on a daily basis that have their own unique passwords.
Pretty soon, you have to use a password safe application to keep track of them all. Not to mention the common practice of expiring passwords, which forces you to change your password after so many days, weeks or months.
And of course, it’s human nature that people forget their passwords, which forces them to either call the system administrators or IT helpdesk to reset their passwords.
All this digital security comes at a heavy logistical price. For software developers, you have to bake your own security mechanism into each and every application you want to bolt down with security. Then there’s the whole administrative side of security and password management that someone, or an entire team of support folks, will have to maintain.
In the course of my professional career, I’ve seen this same problem of multiple security accounts, passwords, and password management happen over and over again.
Yet the solution to this redundancy is actually quite simple and quite feasible.
YOU CENTRALIZE IT.
In software development, probably one of the most important golden rule principles is DRY, short for DON’T REPEAT YOURSELF.
Repeating code, that is, code that duplicates itself all over an application is probably one of the greatest obstacles to easily maintainable software.
When you duplicate a function or set of libraries in multiple places in your application, it means anytime you have to change and modify said code, you have to do it in multiple places. The same goes for trying to debug your application. Duplicate code means duplicate places where you have to go in and fix your code.
Security management is no different.
At the most general level, digital security is really only about two things.
- Identification
- Authorization
Identification
Identification is figuring out WHO you are. If we’re talking about within a corporate environment, identification means every person working with the organization.
Usually, every employee is issued some sort of employee number or unique identifier value. It uniquely guarantees there can be no other identifier that can be used to identify that particular person. Since every employee is usually issued some sort of digital login ID to sign into their computer, as well as a unique e-mail address, those can also be used to uniquely identify a person.
Since the Human Resources department of every organization is where information about every past and current employee is stored, it’s actually a logical data repository from which to identify people within an organization. How it gets stored, varies with every organization, but it’s usually in the form of some sort of database system.
This specific repository of employee information is considered the “golden source of truth” for employee identification since the HR department also has to make sure this list is always updated with an employee’s current work status and any other relevant information about that employee… their physical address, their marital status, and any other number of relevant attributes which HR keeps track of.
Therefore, this employee repository is what every other application and system should be using, to identify WHO is trying to use a particular application, server, database, or computer system.
Sadly what often happens is a development team will “roll their own” identification system. Meaning they will create their own duplicated list of users who wish to access their application, even when the HR employee repository is completely available to use.
So then that means that custom list of users will need to be continually maintained and updated over time. And you can eventually end up with hundreds, if not thousands of custom applications, using multiple and redundant databases of users and employee information.
Authorization
The other half of security is the AUTHORIZATION. If you successfully sign into a custom application, database, computer or remote server, what needs to happen next is to figure out what kind of permissions and capabilities you have within said system.
Most applications have at least two major ROLES. One role is as a person who needs to use an application with base level security privileges.
The other role, commonly referred to as ADMIN or ADMINISTRATIVE, is intended for folks that need elevated security privileges to do things like add new users to the application, change their passwords, or do things within the application that should only be allowed if your job title or business role within the organization allows you to.
For instance, say the organization uses some general ledger accounting software to keep track of all corporate revenue.
You wouldn’t want just anyone to be able to use that general ledger software. You only want the designated and authorized accounting person to be allowed access.
So if I was an employee in the shipping department of an organization, I would be able to log into the general ledger application, because I’m a valid employee of the organization, but I would be denied access to anything that would allow me to add, edit or delete any important information within that ledger software.
This is what authorization guarantees is that only the right people are granted access to perform the major activities needed in an application, computer, or database.
So this kind of authorization information would ideally be centralized in a single location as well.
The Value of Centralization
Logistically speaking, creating centralized repositories of IDENTIFICATION and AUTHORIZATION information is very straightforward.
The problem is really a human problem. Or what I like to refer to as the “herding cats” problem.
Too often, development teams don’t take advantage of common enterprise libraries and resources.
[bctt tweet=”Too often, development teams don’t take advantage of common enterprise libraries and resources. ” username=”profocustech”]Many times, this can be out of ignorance or the organization is not proactive about advertising the fact there are enterprise resources in place, that can help ALL development teams.
And of course, just plain stubbornness. Even if enterprise resources are readily available and highly publicized, a team may decide to go with their own system. Maybe because they’re under a tight deadline and they don’t want to rely on an external dependency like an enterprise security framework, to affect their deadline.
This is extremely shortsighted. Perhaps it may even be true that not using an enterprise security framework could speed up development in the short term, but in the long term, you’re setting yourself up for lots of maintenance headaches and technical debt down the road.
When you take advantage of enterprise security frameworks, you offload the burden and maintenance headaches that go along with security, and free yourself up for more time and resources to concentrate on what matters, which is your actual custom functionality your application is supposed to deliver.
You also take advantage of some huge benefits that can come with hooking into enterprise security frameworks, like SINGLE SIGN ON.
How it typically works is every person needs to sign into their work machine with a user ID and password. Some machines even have biometric security where you don’t even have to manually type in your user ID and password… the machine may have some sort of facial recognition software or fingerprint reader on the machine to identify who you are.
Once the machine figures out your IDENTIFICATION and AUTHORIZATION roles, any application, database, or remote system will automatically know who you are and what kind of security rights/roles you have, and determine what kinds of privileges you have, without prompting you to type in any additional user IDs and passwords… hence the term SINGLE SIGN ON.
It’s a HUGE time savings.
I’m confident near future technology will get advanced enough where as soon as you enter a particular building or room, perhaps a combination of biometric sensors and cameras will figure out exactly who you are, and then determine what exactly you can access at any given time and place.
Well, maybe not EVERYTHING… let’s leave the restrooms as is, shall we?
