One of the reasons why I joined Ping Identity is that the identity market is undergoing a significant transformation as a result of changing user behaviors. The demands that mobility and APIs are putting on businesses, and how architectural limitations in traditional IAM stacks mean their relevance in the market will invariably decline. This is an exciting time to be in the security technology market and while I won’t claim that security is suddenly sexy, what I can say confidently is that customers are looking at identity as a strategic initiative for driving growth rather than something they need to cover the bases on for risk and compliance.
One particularly interesting opportunity for Ping is in the web access management (WAM) market, which has existed since the late 1990’s and features some very mature products. We are not suggesting companies turn off their WAM products and start over, and point-in-fact, the history of enterprise software is not rich with examples of things being turned off, at least not until the last device is turned off. What typically happens is that more modern products are implemented in parallel to extend legacy investments and eventually what happens is that the legacy products fade into the background and assume a maintenance orientation.
WAM solutions built on a 1.0 framework have declining utility in a world where the security perimeter is changing from firewalls to identity. If your approach to WAM is through a session token and a role-based authentication process, you are not well equipped for the environment that customers find themselves in today. It is with this backdrop that we launched PingAccess last year, but this product is just one piece of a broader strategy to deliver federated identity solutions for web, mobile and API usage that meets the needs of companies in customer, workforce and extended supply chain scenarios. Read more about PingAccess in David Gorton’s latest blog – ‘The WAM Identity Gateway That Can‘.
Mobility and device proliferation impose architectural limits on WAM 1.0 products… but rather than turn those things off, the better strategy is to implement Ping Federated Access Management to manage identity and sessions with standards rather than proprietary tokens.
By unlocking dependency on specific vendors, Ping Identity has the opportunity to lead a generation of ‘IAM refresh’ that will put stack vendors in a box that they cannot break out of with the existing architecture and product portfolio they bring to market today. The Ping Identity advantage of implementation flexibility and speed is coupled with a standards-based approach in a superior architecture and that has real value for companies looking at their mobile strategies and ecosystem enabled services driven by APIs.
CA, IBM, Oracle, et al are not standing still. They are adding mobility and API support into their product set, but the Ping Identity architectural advantages and our proof points for speed, cost and reliability are substantial. Another way to think of this is that if you evaluate products on the basis of who checks the most boxes, you will invariably end up buying the product with the most bloat, not the one that meets your needs today and tomorrow with speed, cost and deployment advantages.
Here are a few examples of how you should consider Ping Identity against stack vendors:
- Support for mobile browsers and desktop as equal classes. We support user access to apps from any device.
- REST API deployment model. We use next-gen standards that eliminate the need for a username and password for every app’s authentication and authorization.
- Administrators have the option of building their own tools because we built the products on a modern API for the administration of the platform.
- Self-service onboarding for apps. We eliminate the reliance on IT.
- Federation everywhere. It’s where we came from and influences everything we do.
- No proprietary tokens. We use standards and this increases integration options while reducing integration cost (friction).
- No vendor lock-in. An example of this in action is how we use upgrades to deliver new features rather than require the upgrading of agents to maintain support availability.
- Scope-based access control at authentication rather than role-based, an example of the architectural distinction.
We put together a solutions brief on web and API access management, if you are interested. I know this sounds spammy and anything labeled “solutions brief” is suspect on the basis of being labeled “solutions” however there’s a lot of good info in here and our marketing approach in 2014 is summed up as “be the best answer”.