By now everyone is aware they should be implementing Multi Factor Authentication (MFA) across the board to strengthen their organization’s security posture. From cybersecurity regulations to cyber insurance policy mandates and Zero Trust Architecture Executive Orders, to the massive uptick in cyberattacks and breaches over the past several years, helping users help themselves with this additional layer of protection is a top priority. Some cybersecurity insurance companies are even requiring the implementation of MFA to keep policies active and in compliance. But, easier to mandate than to do.
For modern applications, implementing MFA is pretty standard stuff. But in complex environments with many legacy or “nonstandard” applications, it can be a daunting task to implement MFA at scale. These legacy applications don’t support modern protocols and lack mechanisms for easily adding MFA, and you don’t want to mess with their logic through custom coding either. Centrally managing authentication policies and adding stronger security is no easy feat for organizations with technical debt and identity sprawl. The hard part is to get the various identity sources, Identity and Access Management (IAM) solutions, and applications to play well together—which is where an Identity Data Fabric approach comes in.
We have a very fun magic trick for helping organizations roll out MFA to strengthen security, meet regulations, and protect their users from the cold, cold world—keep reading to learn how we get it done.
Adding Stronger Security to Legacy Applications (and Beyond)
RadiantOne includes a framework for calling authentication services like RSA SecurID and Yubicloud, PingID, or Google Authenticator. This allows standard LDAP applications to benefit from stronger, multi-factor security without custom coding the application.
Unifying all the sources of identity data into a central identity platform with authentication skillz enables MFA to be extended easily to even legacy applications. Those applications can call on RadiantOne to handle authentication as usual, and behind the scenes RadiantOne will call the MFA service on their behalf, returning the authentication result back once the multiple checks (of the user’s credentials, and of the additional factor via the MFA service) have been completed.
Let’s break it down. A user attempts to log in to a legacy LDAP application that has been configured to authenticate against RadiantOne. The user enters their login information, a password for example, and an additional factor—let’s say a One Time Password (OTP) sent to them via the RSA SecurID application.
The client application, just as it normally would, passes these credentials to the LDAP service (in this case, RadiantOne). So far, everything has been “standard” from the application’s perspective—and now this is where RadiantOne does some magic to make MFA happen for this application. RadiantOne translates the standard LDAP authentication (bind) request into a validation of the user’s password to the authoritative source (whatever source that may be) and a call to the external authentication service to validate the rest of the credentials.
Managing Access across a Complex Identity Infrastructure
Let’s break it down further. As everyone knows 😛 authentication has two stages. 1. Identification and 2. Credentials checking.
The first step, identification, can be harder than it sounds depending on the complexity of the environment—how many identity sources need to be searched, what types of sources, what formats, what protocols does it take to access them, is there user overlap and how much? All these variables and more add difficulty in searching the identity system for a specific user and correctly identifying them.
Step two, credentials checking, also has to be done according to the specifications of the identity store. Just as different repositories support different schemas and naming which poses a challenge during the identification phase, they also support different authentication mechanisms which are the challenge of the credentials checking step. This may involve hashing the password value to compare it against a value in a database, delegating the password check to an LDAP or Active Directory, or calling an external MFA service like RSA SecurID.
It’s challenging to authenticate users across an array of sources. If you don’t have a single source of user information, an application would have to look in all the different data stores across the enterprise to find a particular user. We want to avoid this—it’s costly in terms of authentication time, not to mention a pain to set up and maintain.
Let’s break it down… moooooore. Even if a user is listed in only one store, an application still needs to locate them across a number of sources, resulting in multiple queries issued (at least one to each source the user could potentially be located in). However. If you have a master index of identity data, the application only needs to query this ONE list to locate a user, which results in queries to only the backend stores where the user is located. The more sources involved, the more valuable this global index is. It is this miraculous list that is created and maintained by RadiantOne.
All this to say, RadiantOne knows where the user is located and immediately delegates the checking of the credential to that source, bypassing any unnecessary rigmarole of hunting for them in N locations. RadiantOne will handle whatever remapping/transformation is required, and it will support the checking mechanism of that source, which is not a guarantee on the application side (so again, saving you that hassle). Boom, authentication.
Whew! Back to MFA.
Plug In to MFA
Where were we? Oh yes, the legacy client application passed the users credentials to RadiantOne, which is now looking up and identifying the user in your system (using the global index it has built and is dynamically updating all the time), to retrieve the identifier that this user is known by in the SecurID system.
RadiantOne can then use that identifier to call the SecurID authentication service (via its REST API) to check the OTP. After it gets a response (was the OTP valid or not?), RadiantOne checks the user’s password against the appropriate source in your system. If both tests are passed, RadiantOne returns a successful bind to the client application (and the user gains access 🙂 ).
And THAT is the EASY way to implement MFA for legacy applications.
What are Modern Applications, Chopped Liver?
What about the applications in your system that are “federated”—that support modern security protocols like SAML, OIDC, OAuth, etc? Do they get to benefit from this platform? Of course they do.
The RadiantOne platform has six modules to choose from, one of which is the Single Sign On module. It builds off of the identity data foundation created with RadiantOne’s Federated Identity Engine, leveraging that authoritative source to deliver SSO and apply fine-grained access control to users based on attributes in their global profiles. The SSO module has the functionality of a Security Token Service (STS), generating, translating, sending, and receiving security tokens that enable seamless access to claims-aware applications.
Our SSO module, by supporting the standards of the trade (SAML, OAuth, OIDC, WS-Federation and WS-Trust), can of course also communicate with other trusted IdP’s and “chain” together to widen the circle of SSO. You’re now very easily and securely able to connect internal users to the cloud—and external users to your enterprise applications.
As a federated access solution, the SSO module supports a variety of authentication methods—like ye olde forms-based authentication (login and password), certificate or PIV/CAC card authentication, Active Directory, other IdP’s, and two-step verification or external MFA services.
So you have the complete spectrum covered with RadiantOne—from legacy to modern applications and everything in between, it’s easy to incorporate additional security mechanisms when you’ve unified identity as a resource for the organization.
- Wrap your users in a warm, cozy blanket of security and MFA by laying the groundwork for success with RadiantOne
- RadiantOne includes a framework for calling external authentication services like RSA SecurID and Yubicloud; This allows standard LDAP applications to benefit from stronger, multi-factor security without requiring any changes to their authentication logic
- The plug-in mechanism makes it easy to add multiple external MFA modes to existing applications making LDAP calls
- RadiantOne offers a Single Sign-On module that supports MFA and other enhanced security features to enable a secure, seamless user experience for claims-aware applications
Subscribe to receive blog updates
Don’t miss the latest conversations and innovations from Radiant Logic, delivered straight to your in-box every week.