As we discussed in part I of this article, many companies are still in the process of modernizing their legacy apps. There are a number of reasons to do this, but securing your environment is typically the main goal. We’ve already identified that a (software) token-based system as essential. Let’s continue with a couple more best practices.
Provide for User Provisioning
An application needs user data — not for authentication, but because it needs to know the role and responsibilities of the person logging in so that privileges inside the app can be managed and regulated.
Therefore, a database of user information typically resides inside the app. In legacy apps, this data is manually entered by an administrator who also assigns specific privileges for each user. It’s very labor intensive, so it’s preferable to automate the process of communicating user data to apps that require it. There are two methodologies for automating that process:
Just-in-Time vs. Explicit Provisioning
With “Just-in-Time” provisioning, a user arrives at the application with an identity token. While the app may have no previous experience with or knowledge of the user, the token acts like a driver’s license, verifying that they are who they say they are and confirming that they’re allowed access to the application — just like a driver’s license verifies your identity and confirms that you’re allowed to drive.
In addition, the identity service provider can automatically insert supplementary user data such as role, department, etc. into the token. The app can then extract this information and use it to ascertain exactly what permissions should be granted to the user. It’s the app’s use of this information to populate the user database at the last possible moment that gives the method its name — “Just-in-Time.”
The benefit of this method is that no action needs to be taken before the visitor arrives and no resources are required to build a database of user information.
Alternatively, some organizations choose “explicit provisioning” for a more structured, pro-active provisioning process. When a person is hired, their information is entered into an identity service which, in turn, directly communicates that information to all the internal and external apps that person should need access to.
For example, a newly hired salesperson’s information is entered into the identity service. The service will deduce that a person in the sales department will need access to Salesforce.com. It will then automatically communicate with Salesforce to create a user account and provision it for the new hire. This way, an account is created and privileges are defined before the new hire ever logs into the system.
While slightly more complicated to set up, this method enables the identity system and the application to have a more sophisticated conversation about the user. And the more detailed the information that’s shared, the more efficient the user setup and provisioning will be.
Both of these systems offer value. If you have a very simple set of requirements, use Just-in-Time provisioning. If you need extended and precise provisioning, then use explicit provisioning through an identity management system.
Make It a Priority…but Don’t Try This at Home
Some organizations — especially those with a handful of legacy apps — feel they need a customized solution to fit their specific needs and so they opt to build their own. They believe that by using secure, proven technologies like SAML or OpenID Connect, that developing a system and designing their own tokens won’t be difficult.
The problem is that both SAML and OpenID Connect are relatively complex technologies designed to powerfully solve critical security challenges. You cannot develop your own SAML system and make it secure, usable and scalable without expending massive resources.
I met with a pharmaceutical company recently that had been attempting to modernize 20 different applications, each of which had its own identity database. Despite a number of misgivings, they’d decided to invent their own token management system, which proved to be far more challenging than they’d anticipated.
A further obstacle was the fact that one of their primary goals was to merge their existing identities into one system. Identity consolidation is much more than switching from usernames and passwords to a token-based login. There is the migration, consolidation and management of existing identities to consider. The company eventually abandoned the project and came to us.
The truth is, we meet a lot of customers that have tried to save money by designing their own systems. And after spending copious amounts of time, money and development resources, they all end up with a patchwork solution that simply doesn’t work as effectively as they need it to. By the time they come to us, they’ve spent significantly more modernizing these apps than they would have if they’d come to us in the beginning.
The bottom line is that there are myriad challenges to address when you’re modernizing applications. It’s an important project, and one that companies should absolutely be focused on. But using a well-designed, well-thought-out solution is essential.
Boost your security with Centrify Identity Service.