At colleges and universities across the country, a hidden danger is lurking. It may have once seemed innocent, but in today’s world, it is a legitimate threat: Custom identity and access management (IAM) solutions cobbled together with custom scripts.
We’ve encountered many higher-education professionals at trade shows and industry conferences this year who are concerned that their school is still using “homegrown” IAM solutions. These solutions are built around scripts, a series of individual commands used to execute a particular task.
Scripts are helpful in automating repetitive actions, such as automatically copying information from a student information system into a text file and then uploading that file into another downstream system. They are a quick way to get something done, but they are not a sustainable replacement for a modern and complete IAM solution.
The Problem with Scripts
Many schools got into the habit of using scripts as a stopgap for identity management tasks because an off-the-shelf, web-based single-sign-on service didn’t meet their lifecycle management needs. Today, many institutions continue to use scripts because of concerns that implementing a full IAM solution would be too challenging and/or expensive for their small teams and budgets.
In other cases, scripts are born from crisis—they are a temporary solution to an immediate need. These solutions seem harmless in the beginning, because they are usually considered a short-term answer to a problem. But they often become permanent solutions.
The Problems with Custom IAM Solutions
If your team is still using scripts, here are five reasons why it’s time to switch to an IAM software solution:
1. The key-person risk
The identity management needs of colleges and universities are complex. However, most scripting in a custom IAM solution is done by a single individual—a key person whom the school relies on for all scripting needs during a given year. In many cases, scripting is his or her secondary duty. If updates or adjustments are needed, the key person may not be able to make the solution a priority, leading to delays and broader issues. Worse still, if that person leaves or is unavailable when a problem occurs, the school is left in a lurch if there is no one else who knows how to manage or fix the system.
Since scripts are usually developed and managed by a variety of different people over the years, outages and other issues can be devastating. When a problem arises, it takes much longer to recover because no one really knows who did what. When the problem is identified, your script builder has to learn what the script is and how it works before it can be fixed, leaving the school vulnerable to a catastrophic failure or security breach.
2. Lack of identity expertise
At most schools, script builders have a great understanding of IT and scriptwriting, but their knowledge of the complex, identity management process can be limited.
This presents several problems: They are probably not familiar with identity management and security best practices. It’s also likely that they lack the knowledge to fully understand their school’s identity needs. They’re usually figuring it out as they go along, leveraging their IT knowledge, but in a position where they can cause more harm than good in the long run.
3. A lack of standards, framework, and support
A mission-critical function, like identity management, requires a full software development process with clearly defined standards and a well-established framework and rigorous testing. When something breaks, you need to know that your system is supported.
Because scripting is usually a last-minute fix, it rarely involves adequate documentation or testing. By the time one script is implemented, it’s time to move on to another challenge, leaving no time to create a more permanent fix for the original problem. As a result, your identity management solution includes a series of patches with little or no documentation or clear use cases. There is very little consistency between scripts, making them nearly impossible to effectively support and manage.
Unlike with a software solution, there is no change management structure, monitoring, or updating to meet SaaS API updates. If your underlying system is upgraded or updated, your script builder must rebuild the entire script. And, if a problem arises with the platform or a script, you have a choke point—or many choke points—that require in-depth, manual fixing.
4. Limited efficiency
Scripts are often written by various people on disparate platforms, sometimes in different languages. To execute a single action, several steps must occur, each of which is focused on a single piece of the overall task. In some cases, a third-party conversion tool is required to allow scripts to “talk to” each other. Scripts easily get tangled up in a ball of notes, leaving you with a messy orchestration issue with no central governance.
As your school adds new users, this inefficiency becomes more and more apparent. Because a series of scripts doesn’t follow any single design, the incremental nature makes them less efficient as a whole than a single, unified IAM product.
5. Limited functionality
Finally, scripts don’t address the functionality that your school truly needs. Because they are static and written to solve a single problem, scripts don’t evolve with your changing IAM requirements.
Anytime a single aspect of the system changes, you have to update existing scripts or write new ones. For example, your script builder may need to write a script to grant access to a particular group. But this approach isn’t sustainable; eventually, you will reach a point where your IT team can’t do something critical in your IAM system because the scripting process doesn’t allow it.
Remember—scripts are purpose-built. By definition, they aren’t part of a larger, comprehensive solution. Relying on scripts is not only time-consuming, forcing your script builder to constantly chase the latest need, but they can introduce security vulnerabilities and risks.
Comprehensive IAM software provides higher-education campuses with the identity management capabilities they require. Now is the time to break out of the cycle of scripting—before your stopgap measures wind up endangering your entire campus.