The subject of modernizing apps has been around for years, but while talking to a partner organization recently, I was reminded that there are a number of companies with legacy apps that are just now getting around to dealing with them.
What Apps Need Modernization?
The commercial apps you’re implementing into your environment today should not need to be modernized. If, however, you’ve developed your own apps or you continue to use legacy commercial apps developed several years back, you may have some work to do.
Why Modernize an App?
Companies most often modernize apps as a method of improving security. Legacy apps typically employ their own database which requires users to create their own usernames and passwords. You probably already understand the risks associated with that. Other reasons to modernize include:
- The high cost of setting up users and managing privileges manually
- The benefits of allowing partners and customers to connect directly to key applications rather than contacting your call center staff for information
- The process of rehosting apps from an on-premises datacenter to AWS, for example, provides organizations with an opportune time to update them
All are good reasons to modernize, but there are a few best practices to follow when doing so:
Employ a (Software) Token-based System for Secure Access
From an identity management perspective, the primary goal of modernizing apps is to prevent users from logging in with usernames and passwords. Beyond the security issues, managing usernames and passwords is time consuming, and nobody wants to maintain a database they don’t really need.
Nor do they want the responsibility. Storing user data makes you responsible for that data, and there are all too many examples of why you don’t want that responsibility. The best case scenario is that your partner company’s employees are able to log into your system without having to replicate their user database into your own. To achieve this, you need a trusted system that will vouch for their identities. In short, a token-based authentication system that leverages SAML or OpenID Connect is required. If you need a quick refresher on SAML, here’s a brief synopsis.
SAML vs. OpenID Connect
There’s some sentiment in the industry that SAML is a heavyweight, old-fashioned system and that OpenID Connect is a modern, superior alternative. The truth is that both fundamentally do the same thing. They remove the responsibility of user authentication from the target application and place it on an identity management system. The system then vouches for the user as they attempt to connect to the app.
The two provide the same basic functionality, and the user experience is virtually identical. The key things to consider when selecting between them are: Whether you have the necessary tool kits on the application side, and which of the two are supported by the identity service engine you’re using. Centrify supports both.
Whatever the reason you’re looking to modernize your apps, and whether you choose to do so with SAML or OpenID Connect, the important thing is to fortify your environment with a token based system. I’ll provide a couple more best practices in the coming days.
Learn more about SAML integration from Paul here.