Higher ed institutions across the world are using homegrown identity and access management (IAM) solutions cobbled together with custom scripts. These homegrown solutions are built around scripts which are a series of individual commands used to execute a specific task. These scripts are helpful in automating some repetitive actions such as automatically copying information from SIS to a text file or uploading that file to another downstream system. But, they fall short of modern-day IAM solutions in many ways.
Why Higher Ed Institutions Use Custom Scripts?
Many higher ed institutions are using custom scripts as a substitute for their identity management needs. Some are using these scripts to run SSOs while others are using them to provision users from their source of truth (such as SIS, LMS etc.) to target applications (Active Directory, OpenLDAP etc.). They’re using these scripts as implementing a complete IAM solution would be too challenging and expensive for their small team and budgets.
In other cases, these scripts are a temporary solution to immediate needs of the institutions. It’s a short-term answer to a problem, often becoming a permanent solution. In the beginning, scripts are harmless, but they’re rarely sustainable in the long term, and using them might have a much broader impact on your institution.
Why Identity and Access Management is not a DIY Project?
If your IT team is still using custom scripts, here are top five reasons why your team must switch to a modern-day IAM solution.
1. Relying on Single Person to Write Custom Scripts
The IAM needs of higher ed institutions are complex. However, scripts are written by a single individual or a small team in a homegrown IAM solution. The institution relies on this small team or individual for all their scripting needs. And in most of the cases, writing scripts is not the primary responsibility of these people. If any update or adjustment is needed, the individual or team might not be able to do it on a priority basis, leading to delays and broader issues.
Things get worse when these developers leave the institution or is unavailable when problems occur. The institution is left with no one to help them fix their problems.
Since these scripts are developed and managed by different people over the years, outages and other issues might occur leading to devastating results. When a problem arises, the recovery can take long as no one really knows who did what. After the problem is identified, the developer should learn what the script is and how it works before fixing it, leaving the institution vulnerable to disastrous failure or a security breach.
2. Lack of Identity Expertise
A self-service password resetting tool allows the end-user to reset their passwords on their own while following all the necessary security protocols. Therefore, a self-service password reset tool avoids any involvement of the IT help desk for resetting the password. Hence, there is no more delay in resetting the end-user passwords.
If developers are not familiar with IAM processes, they might not be familiar with IAM and security best practices and also lack the knowledge to fully understand their institution’s identity needs. Most of the times, they’re figuring it out as they proceed, leveraging their coding knowledge. This may cause more harm than good in the long run.
3. Lack of Standards, Framework and Support
A mission-critical solution like IAM requires a foolproof software development process with clearly defined standards, well-established framework and rigorous testing.
As scripting is a last-minute fix, it seldomly involves adequate testing or documentation. By the time one script is implemented, it’s the time to move to another challenge, leaving no time to create a permanent fix for the actual problem. As a result, your homegrown IAM solution will include a series of patches with little or no documentation. This inconsistency between the scripts makes it nearly impossible to effectively support and manage functions.
Also, there is no change management structure, monitoring or updating to meet SaaS API updates unlike a software solution. If your current system is updated, your developer must rebuild the entire script. And if the issue arises with the platform, you have choke points that require in-depth manual fixing.
4. Less Efficiency
Scripts are written by different people on different platforms, sometimes in different languages. For execution of a single action, several steps must occur, each of them focusing on a single piece of the overall task. In few cases, a third-party conversion tool is required allowing scripts to talk to each other. These scripts easily get tangled up, leaving you with a messy orchestration issue.
When your institution adds new users, this inadequacy becomes more and more deceptive. As series of scripts doesn’t follow a single design, it makes homegrown IAM less efficient when compared to a unified IAM product.
5. Limited Functionality
Custom scripts don’t address the functionality your institution truly needs. Scripts don’t evolve with changing IAM requirements as they are static and are written to solve a single problem. Anytime a single aspect changes, you have to update the existing scripts or write the new ones.
Let’s take an example: Your developer might have to write the script to grant access to a specific group. You can’t live on this approach as you’ll eventually reach a point where your developer can’t do something critical in your homegrown IAM system as the existing scripting process doesn’t allow it.
Scripts are built on a purpose. They aren’t the part of a larger inclusive solution. Relying on such scripts can be time-consuming and bring security vulnerabilities and risks.
The Bottom Line
Homegrown IAM solutions cobbled up with custom scripts are erroneous and labor-intensive. They can’t handle institutional complexities in the long run and are prone to fail. Your institution needs a comprehensive IAM solution with powerful identity management capabilities. Break out of the cycle of scripting before these stop-gap practices start endangering your institution.
