Guest blog post by Kevin Shanley, Associate VP of Access Management, Cyberinc

Enterprises have logged a lot of mileage out of first-generation web access management (WAM) solutions. WAM technology that became available in the late 1990s has served companies well, providing users with single sign-on (SSO) and automatic login from workstations. However, new forces at work have brought about the need to secure REST-based APIs, native mobile applications and software-as-a-service (SaaS) providers. And these first-generation WAM solutions simply can't be extended to meet the demands of these new requirements.

APIs continue to proliferate and are fundamental to building applications. There's often a native mobile application component to new services being built that relies on these APIs. Businesses sometimes forego building a service and elect instead to leverage a SaaS provider. Further, legacy on-premises applications stubbornly remain active and often need to integrate with SaaS providers. DevOps is accelerating development, and security teams have to keep up. Customers want any application, from any device, anywhere, anytime. Finally, enterprises need to be nimble and dynamic--monolithic WAM solutions are a thing of the past.

As most architects and engineers know, first-gen WAM solution typically consisted of an agent on a web tier that enforced authentication and authorization for web applications. Even before trying to address the challenge of APIs and mobile, there were numerous challenges with the security and maintenance of a typical first-gen WAM solution.

• Proprietary tokens were maintained in cookies, which were susceptible to replay attacks.
• Identity was propagated to applications via HTTP headers, which left applications vulnerable to insiders who could impersonate other users.
• Incompatibility with other WAM vendors made it difficult to integrate SSO with partners and cloud applications. SAML and other federation solutions were later paired with WAM products to provide cross-domain SSO in a vendor-neutral fashion, but dealing with compatibility between federation and WAM providers was still a challenge.
• Dealing with multiple administration interfaces created a maintenance burden and governance issues.

The problem was complicated even further when API requirements were introduced. Enterprises tried to extend WAM to provide security for these services using WS-Trust and API gateways for APIs and native mobile application security, as well as SMS for multi-factor authentication (MFA).

Security for REST services and APIs

WS-Trust was introduced to provide a standard of security for web services. However, trying to reuse the WAM token within a web application to call an API was difficult to build and scale. WS-Trust didn't have a token exchange profile for these proprietary cookie tokens. Native mobile applications couldn't easily use WAM authentication services because the WAM solution was browser-centric. Protection of REST-based services with WAM enforcement had the same problem. REST is stateless by nature, but WAM vendors typically require stateful sessions. WAM vendors assume the client is a redirect-reliant browser, which isn't appropriate for REST services.

SaaS was another challenge. WAM vendors couldn't install an agent on a SaaS provider. WAM vendors tried to build reverse proxy solutions for cloud, but scaling to match a global SaaS provider wasn't feasible. As a result, SAML became the de facto approach to SSO for SaaS applications, but the typical browser POST profile left a lot of concerns unaddressed, including authorization. 

SMS for MFA

Key tenants of WAM security have also proven to be less than optimal. Short Messaging Service (SMS) to end-users' phones became the primary second factor to provide security. However, NIST 800-63B (Authentication and Lifecycle Management) has exposed that SMS-based MFA solutions as being insufficient for sensitive data. Without the ability to validate phone numbers tied to identities, SMS messages can be intercepted and redirected. The assignment of the phone number to the identity was identified as a weak link as well. Early WAM vendors used a numeric assignment of authentication strength, but once a level was reached, that session was privileged for its entirety.

To sum it up, there was no foundation or mechanism for policy-driven step-up authentication. If you'd like to learn more about leaving your legacy WAM in the decade it worked best, see our Ultimate Guide to Modern Access Management. Or if you're using CA Siteminder (now called CA Single Sign-on), check out our CA Siteminder Migration Guide.

Editor’s Note: Kevin Shanely is now a Director, Cyber Security Services at KPMG following the January 2018 acquisition of Cyberinc by KPMG.