Consumer Authentication – Background
Over the last few years, consumer facing web applications that require some form of security to protect access to their resources have faced a significant increase in issues related to online fraud. Combined with the anticipated need to support new mechanisms and channels for consumer authentication (e.g. CardSpace, OpenID and Higgins, mobile devices, flash, Ajax and voice) many companies are now beginning to rethink their approach to consumer authentication, and their homegrown systems, they realize, are simply not architected to take advantage of many of these anticipated advancements.
That was then…
Most consumer-facing web applications were developed in the mid 1990’s, and implemented only a simplistic userid and password based mechanism to authenticate their consumers. This mechanism has been repeatedly implemented (independently) in some proprietary manner within thousands of web applications. When just requiring a password was enough to authenticate the user (prior to pfishing); implementing an LDAP Bind or a JDBC call to a data store to validate the password, was deemed ‘good enough’, and as a result, most companies rolled their own. To the extent web session management was also required, many companies implemented their won proprietary session token which they then stored in a cookie.
Why not the WAM products?
About the same time we saw the advent of the 1st generation of web access management (WAM) products (e.g. Netegrity, Access360, Securant, ClearTrust, Oblix etc.). While their focus was primarily on the notion of centralized policy management (authorization) for web applications, they also implemented mechanisms to provide user authentication and more importantly single sign-on; but only as a byproduct of offering policy based access management.
Given the cost and complexity of the 1st generation of COTS Web Access Management products, the vast majority of companies with customer facing use-cases chose NOT to deploy these products in their consumer facing scenarios, but instead use them ONLY for internal / employee facing use cases only. This is the dirty little secret we discovered when first approached to build a next generation framework for consumer authentication. The logic was simple, the existing WAM products were deemed too ‘heavy’, too complex and too expensive to deploy for customer/consumer facing applications.
So what about now in 2007?
What was interesting to us here at Ping Identity was that if you roll the clock forward now to 2007, with regards the WAM products, nothings changed. In fact, things have gotten even worse, in that many of the WAM vendors have been acquired, and are now part of an even LARGER, even MORE proprietary or EXPENSIVE stack. That said however, things have changed in the architecture and environments surrounding these products and the need for a new, lightweight, laser focused approach towards consumer authentication. With the advent of SAML, authentication has now become ‘portable’. ISV”s are building SAML into their products and we’re seeing a natural bifurcation of AuthN and AuthZ services. It’s this clean separation of authentication and session management services from policy, authorization and entitlement management that PingLogin was designed to address.
Feeling the Pain
For the first time in several years, companies that rolled their own simplistic password based consumer authentication are feeling the pain and stretch of their systems to the breaking point. And that’s where PingLogin comes in. For those companies now feeling the pain of consumer authentication (need for strong auth, need to support new mechanisms such as CardSpace, OpenID or Higgins, need to support multiple consumer ‘channels’ such as HTTP, AJAX, Flash, Mobile, Voice etc.), the existing products, for all the reasons they weren’t originally chosen, still didn’t suffice. They are still too focused on policy, still to light on authentication flexibility and still deemed too expensive to deploy in consumer facing use-cases.
Most consumer facing applications will have to address strengthening their existing consumer authentication mechanisms over the next two years and consider implementing new methods of consumer authentication. It is highly likely that this will be an iterative process that will continue ad infinitum. The attackers will always be looking to break through the next generation of consumer authentication techniques. It is an arms race that will not decrease, considering online transaction volumes and are likely to continuously increase.
What Ping Identity is doing about it
Starting around a year ago, Ping Identity and two large design partners began working together to create a 2nd generation web authentication product that fundamentally re-addressed the need for extensibility and flexibility when it came to consumer authentication & single sign on. The major design goals for this new product was performance, extensibility and flexibility to address the continuously shifting landscape of online consumer authentication. A landscape that that will be impacted by regulators, consumer whims, the media, and existing and unknown attacks.
Now for the first time, organizations that have implemented their own proprietary system have the opportunity to implement a commercial solution that eliminates maintenance and development going forward while allowing flexibility to meet specific business and risk requirements.
But What if I’ve Deployed a WAM Product?
Organizations that have implemented an access management product also have the opportunity to migrate to a more focused authentication platform that provides far more extensibility and flexibility to address identity theft and fraud detection. And of course, it works with PingFederate out of the box.
Who Should Take a Closer Look at PingLogin
PingLogin isn’t for
everyone, but for those organizations that have massive consumer
authentication requirements and want a commercially supported framework
which is going to provide out-of-box functionality designed for the
future of consumer authentication, you should take a closer look.
PingLogin 2 is now available for download.
PingLogin Technical Overview | PingLogin Datasheet | Download PingLogin
PingLogin Design Principles
PingLogin was designed to support consumer authentication and SSO for large-scale, mission-critical, consumer-facing Web ap¬plications. The product has been architected with specific governing principles to ensure it can be successfully used in these target environments to provide a framework for the next decade:
- Open and Standards-Based: Wherever possible, PingLogin supports open standards instead of proprietary protocols (CardSpace & OpenID to be supported modules of PingLogin). In addition, certain product modules are made avail¬able to customers and partners through both shared source and open source licenses.
- Extensible and Flexible: A flexible set of APIs is included to give customers a robust framework for integrating PingLogin into existing Web applications and environ¬ments. As business and security requirements change, organizations should be free to add or modify functionality and not be bound to the release cycles of the product.
- High Performance: Consumer applications authenticate millions of users daily. Con¬sequently, lightweight mechanisms to support authentication, session management and single sign-on are critical to meet consumers’ expectations for response time and performance.
- Focus on Authentication: PingLogin is a best-of-breed solution for consumer authen¬tication. PingLogin retains a distinct separation between authentication and application authorization.
- Web Services Integration: While LDAP is supported, the PingLogin architecture as¬sumes that Web services will be one of the primary mechanisms used by customers to integrate with external authentication providers and identity stores.
- Simplicity: Throughout the product, there is always a simple implementation model for basic use cases that can be built upon as necessary to address differing (and sometimes opposing) business and technical requirements.