The report concludes that complexity, performance and lack of vendor support for SPML v2 is a crippler for seamless interoperability between provisioning systems and target applications
But it is not the final word. I spoke today to Richard Sand, CEO for Skyworth TTG, a global systems integrator, who said he is working to revive the OASIS SPML TC, dormant for nearly two years, and work toward a SPML 3.0 focused more on needs for the cloud.
Sand said we should hear news on the new or revised TC this week or next. He is talking to a number of companies about joining in.
If that does not work out , Mary McRae, director of standards development at OASIS and a technical committee administrator, told me the current SPML TC would be laid to rest. She had been set to shut it down May 1, but has been actively working with Sand, who nominated himself to chair the TC.
Standards based provisioning just isn’t getting the traction that Sand says it deserves as cloud computing evolves. He acknowledges the complexity as a major hurdle.
When I talked to Diodati a few weeks ago, he told me Burton took the step of writing its own SPML connector to get the 20-miles-of-bad-road view on what it takes. His conclusion: “[The industry is] at a crossroads now.” And Diodati wrote in his report that his "unachievable" conclusion is “a sad prognosis, as SPML (or something like it), is desperately needed for interoperable provisioning services associated with locally hosted and cloud-based applications.”
“I have a lot of ambition around what SPML 3.0 should be,” said Sand. Foremost on the list is that it won’t be backward compatible with 2.0, which for all intents and purposes has no takers. But he says a SPML 3.0 effort would take “building blocks” from the existing work.
Sand says he is looking at simplification of some of the use cases. “I also want to put in some higher level use cases,” he said. “One problem with SPML is that adoption is a low-level thing. I want to give it some higher level function so it solves more of the integration challenges.”
He says he would like to spec out a REST specification and minimize the focus on SOAP. “I think this can make adoption a bit easier and make it more appealing to existing products. I want to get ahead of the curve for use cases around cloud enablement and what products will need to support.”
And Sand wants to attack the standard schema issue that was never really finished by the SPML TC.
“I want to put a stake in the ground. There can be more than one common schema. There could be one SPML recognizes out of the box so to speak. In the long term that could facilitate adoption because there would be a basic pre-fab schema that end points can translate into.”
Sand has a heavy rock to push up a steep hill, but he hopes SPML has a Chapter 3. This time with some tangible results.
OpenID Connect was ratified early last year by the OpenID Foundation, opening the way for digital identities to be used across websites and applications in a simple, secure and privacy-enhancing manner. The standard has been widely adopted since then, often replacing legacy OpenID 2.0 and OAuth implementations because of the increased security and usability offered by OpenID Connect.
This week, the Open Identity Exchange (OIX) launched OIXnet, an "online registry of trust frameworks and identity systems," and the OpenID Foundation announced that they are the first group to utilize the registry with the OpenID Connect Certification program. Google, Microsoft, ForgeRock, Nomura Research Institute and PayPal have joined us in being the first certified OpenID Connect identity providers.
The OpenID Connect Certification program aims to provide assurance to developers that the participating providers conform to the OpenID Connect standard. The certification outlines detailed conformance profiles, and the OpenID Connect Conformance Test Suite™ is used by providers to self-certify that their product conforms to one or more of these profiles.
Brian Campbell, a distinguished engineer here at Ping Identity, was responsible for much of the OpenID Connect implementation. In a recent discussion, he explained that "certification plays an important role in ensuring that predictable and interoperable implementations of open standards are available in the marketplace. This is critical to the success and adoption of OpenID Connect at scale. The OpenID Foundation has taken a unique and more lightweight approach with self-certification and we are pleased to be a part of the launch of the program."
As you can see from the certification overview, we've certified PingFederate as an OpenID Provider for the basic, implicit, hybrid and config profiles. You can read more about these profiles in the conformance document linked above, but it should come as no surprise that we offer broad support for OpenID Connect since we've been involved with drafting the standard from the beginning.
As a certified OpenID Provider, PingFederate can be used to authenticate users against any number of disparate data stores and provide tokens that can be consumed by any compliant relying party, including services like Amazon Web Services (AWS) Cognito as well as many software as a service (SaaS) and cloud applications. We also offer an open source module that enables the Apache web server to operate as an OpenID Connect relying party, providing a complete, standards-based solution for identity federation and single sign-on for web services provided by Apache, the most popular web server in use today. PingFederate also supports other OpenID Connect providers as a relying party, such as Google's authentication service. Finally, we've also leveraged OpenID Connect to provide a standardized integration with PingAccess, our web and API access management solution.
The OpenID Foundation will continue to expand the certification program by adding relying party certification next month, and then make the OpenID Connect Certification program generally available early next year.
OpenID Connect will continue to mature, and the ability to certify these profiles and implementations is a huge step towards broader adoption of the standard--and a more secure, connected world. It might not be as satisfying as that last diaper that needs changing, but it's certainly a good indication that the standard is indeed growing up.
Next-Gen Identity ensures that all identities are tracked and managed, including users, software, and devices. Next-Gen addresses use cases seamlessly across human and machine to usher in the Post-Password Era.
To start, migration is hard, expensive and filled with disruption. As you look at your identity and access management (IAM) infrastructure and evaluate whether the power and simplicity of a Next Gen Identity solution is worth the disruption to business-critical infrastructure, realize that you are already disrupting and adding complexity to your current identity solution to keep up with business demands.
If you are using a traditional IAM product like CA Single Sign-On, you have probably been wrestling with your infrastructure through upgrades, add-ons and difficult support issues. It might feel like everything is 'good enough', but the reality is that new IT business models are forcing another round of upgrades, add-ons and difficult support issues--impacting revenue and impeding worker productivity.
As we have architected and developed our Next Gen Identity solution, a common sense approach to application migration has emerged. By following our four migration steps, much of the disruption can be reduced when moving your web access management (WAM) functionality away from CA Single Sign-On while immediately taking advantage of the emerging IT business models.
Before we review our four migration steps, it is important to highlight a critical migration capability of the Ping Identity solution. Ping Identity architected the Next Gen Identity solution to co-exist, side-by-side, with the existing CA Single Sign-On deployments. Through the advanced integration capabilities of PingFederate, CA Single Sign-On authentication events and web sessions can be shared across both identity security solutions. As a result, your end-users will not be aware of the underlying system changes during a migration. Additionally (and importantly), your helpdesk staff won't be flooded with questions related to changed behavior, additional sign-ons or increased friction when accessing their applications.
The four migration steps for successfully moving away from CA Single Sign-On to Next Gen Identity are:
The migration starts with planning. It is critical to survey your current infrastructure to understand how your users are authenticated, how access is managed, what policies are in place and what your web access management architecture should look like when the migration is completed. Note: our next blog post in this series will discuss some critical decisions that must be considered during the planning step.
After a solid plan has been developed, the installation and integration of the Next Gen Identity solution is performed. The integration with CA Single Sign-On is important to provide the end user with the same experience. This is also a good time to test the migration plan with an application that has low risk when migrated.
Once the initial deployment is complete and the first several applications have been successfully migrated, it is time to ramp up migration. Full application migration starts in earnest, typically working from the simplest applications to the most complex.
The last step, after the applications have been migrated, is to finalize the migration. If all the applications have been successfully migrated from CA Single Sign-On or other web access management systems, then the integrations between CA Single Sign-On and the Next Gen Identity solution need to be removed. Ultimately, the CA Single Sign-On infrastructure can be turned off and retired.
When the migration is complete, your IT group should see significant cost savings. Additionally, your group will be positioned to handle the next decade of identity trends that are critical to maintain a secure environment while also supporting your business.
Next week in this blog series, we will explain the technical strategies for authentication during a migration to a Next Gen Identity solution and the capabilities of such an identity security platform. In the meantime, here are some good related resources:
Beyond the Firewall, a white paper and webinar discussing six top IT trends and the necessity and superiority of identity-centered security to support them.