If you're still signing on to systems with passwords, you're not alone. Password-based authentication is universal. But if you're protecting your organization with password-based authentication alone, it's only a matter of time before your business or brand suffers a costly attack.
You can save the day with MFA.
Ideally, you're already familiar with--and have implemented--multi-factor authentication (MFA). If not, mastering MFA deployment could very well make you your organization's next hero.
When exploring MFA, you need a solution that makes it easy to not just protect, but also serve. PingID MFA does both exceptionally well. From initial development through current revs, we've maintained a focus on striking the perfect balance between user experience and security.
Our MFA solution began as convenient swipe-based mobile authentication with a simple registration experience. PingID now includes additional forms of authentication like fingerprint scanning, Yubikey support and one-time passcodes via SMS, voice and email. With a growing set of authentication choices, there's no excuse not to strengthen how users securely access applications.
If you already have an MFA sidekick, not to fear. Chances are we already support it with our extensive integration kits and native support for authentication protocols like LDAP, RADIUS and Kerberos.
Once you have authentication options nailed, the real action begins. You'll want to first target users and then identify the applications to start with. Experience tells us it's best to start with a pilot set of users. The IT group is a popular choice. Not only are they your most technical users, they're already accustomed to disruptions in their daily work routine and typically embrace new technology. A successful pilot with the IT group will give you internal evangelists and set the scene for enterprise-wide implementation.
Furthering your chances of victory, improvements to our authentication policies in the PingFederate server version 8.1 make it simpler than ever to set up your pilot.
You can supplement any IdP adapter (e.g., the HTML Form Adapter) with data source lookups using new adapter contract capabilities. This enables you to return group information from a directory server from any type of adapter. Then, within your authentication policy (formerly known as "selector results mapping"), you can conditionally chain together adapters using rules that evaluate the user's group membership. For example, an "Are you in the IT group?" condition answered "Yes" would result in a "Require PingID authentication" response.
The PingFederate 8.1 release enables this policy to be centrally defined by allowing it to be mapped into an authentication policy contract. You can then reuse the conditional chaining of adapters over and over again as you add on new applications. You can start by applying this policy to a few IT-focused apps. As your pilot progresses into a full production rollout, you can apply the policy to each new wave of applications with just a few clicks.
Talk about superpowers. And if you're also using the PingAccess server, you've gained even more weapons to protect your assets while still serving your community.
If you're already using the PingAccess server, you may be familiar with the power of inline control within web applications and APIs. Access control policies dictate who can access what under specific circumstances. At the same time, web sessions monitor users' activity. If they're idle or in the application for too long, they'll be forced to reauthenticate.
With the PingAccess server 4.0 release, the possibilities reach epic proportions. Authentication requirements can now be defined and combined with any other criteria to dictate how a user should sign on.
Say you have a corporate policy in which remote access to sensitive systems requires a stronger form of authentication than just a username and password. However, when employees are on the internal network, a username and password--or a Kerberos ticket brokered from a Windows desktop login--is acceptable. With PingAccess 4.0, you can now combine these two policies.
Imagine that an employee is in the office, signs on to the corporate network and accesses a sensitive system (i.e., gets a web session into the application). Then, this same employee closes their laptop and heads over to Starbucks (on public WiFi) for the remainder of the day.
In this scenario, your employee's web session cookie is still valid and doesn't recognize the move to an unsecure location. Are your spidey-senses tingling from the risk?
But fear not. Using the new contextual authentication policies in version 4.0, you can force that user to step up from their original username + password sign-on to PingID, even mid-session. The user's experience could be as simple as responding to a PingID prompt to swipe the app on their phone. You've mitigated risk and saved your user's sanity, all in a single bound.
Seem too good to be true? It's not. Layering MFA onto your existing policies really is this logical and easy. And your heroics don't need to end here. With the power-packed updates to our FAM solution, your superpowers will include:
triggering strong authentication based on a user's risk profile
layering MFA on top of a business partner's federated sign-on
invoking a multi-factor authentication system over SAML