Consistency In Customer Experience: Single-Sign On
As I mentioned yesterday when discussing Transaction Management, one of the key components of Commerce Modules (as offered through the IP Commerce Platform) is the ability to quickly and simply drive a consistent customer experience. Hence the statement of a “snap-in business solution”…
It is worth noting, when considering the technical side of supplementing a payment solution with a Commerce Module, that there are two audiences whose needs must be met. If the implementation experience solves for merchant customer pain, but is overwhelming for the Software Company, there will simply be no adoption. Similarly, if the implementation is simple for a Software Company, but does not solve for merchant customer needs, there may be minor adoption with little (to no) ultimate usage or adoption.
As IP Commerce is not in the business of building merchant facing applications, we had to take both sides of the equation into account when designing how Commerce Modules are developed and brought to market. I can discuss more of the marketing/business requirements and how they relate to platform implementation theory (i.e. single-sided network effects) at some point in the future…but, for this post, the focus is solely on handling credentials.
In a post entitled Federated Identity: Overlaying Integrations with Appropriate Security Controls, I spent a fair bit of time discussing the concepts behind Federated Identity. But the term, Federated Identity, is not one you will likely hear the majority of Software Companies using. It is worth noting that this differs by the vertical that the Software Company services. For example, those who know, understand, and deploy their application according to the principles of SaaS will, likely, be familiar with the conceptual implementation of Federated Identity (generally) and often well versed in specific components of implementation (such as Single-Sign On).
In general, however, we have heard the terms:
- consistent customer experience
- no repeated logins
- simple access control
or variations thereof.
These statements are usually referring to a Single-Sign On (SSO) style implementation. Leveraging the same set of credentials, seamlessly and securely across multiple applications, goes a long way towards solving the issues of customer experience.
To truly understand how we have addressed this issue, I must present a bit of back story.
Transaction Originator Authentication
As the Platform experienced growth, and we continued to supplement the available Commerce APIs and Payment Services, we recognized there was an industry-wide issue. The majority of payment services in the market do not implement any form of authentication of the “originator” when processing transactions. Instead of verifying the originating point of the transaction, they (usually) require that certain bits of data are passed within the body of the transaction. Importantly, this “identity” data (loosely using the term identity here) is rarely protected adequately. The result is, as you might expect, an available vector for the submission of fraudulent transactions.
Recognizing this, early, IP Commerce has made strong authentication of the transaction originator a requirement. As a Platform, we are able to extend this requirement to the edge (point of acceptance) and perform the authentication on behalf of the service provider. The technology that was implemented leverages the best practices of Federation in a fashion that is not onerous to the Software Company but enables the exposure of multiple services, from multiple providers seamlessly and securely.
SSO Toolkit for Commerce Modules
With this infrastructure in place, consumed by all Software Companies using IP Commerce APIs has enabled us to build an SSO Toolkit for Commerce Modules. This enables the Module developer to build to an infrastructure that has the inherent capability of ensuring their solution can be simply consumed…and will work seamlessly with other software, and services, also leveraging the Platform.
What I, personally, find exciting is the “how”.
The image above is a diagramme of the interaction when a Software Company desires to incorporate the capability of a Module within their payment application. The process is as follows:
- The merchant customer logs into the payment application by entering their user/password credentials.
- The payment application invokes the Commerce Web Services SignOnWithToken() operation to retrieve a sessionToken.
- When required the payment application initiates the module authentication process by sending a GetURL() message to the module-specific SSO URL specified by the Commerce Module provider, and passes the sessionToken and merchantProfileID for validation.
- The Commerce Module responds to the payment application with a dynamically generated, single-use URL that grants the user access to the module.
- The payment application redirects the merchant customer to the module URL (received in step 4) to access the functionality provided by the module.
As you can see it is a relatively straightforward flow.
What is even more compelling is that this same GetURL() call is used both by the Module provider and by the Module consumer. In essence one API provides for both the SSO authentication necessary for Software Companies building and using modules.
There was a term used in the process flow above, “session token”, that bears a bit more explanation.
Without getting into too great of detail*, this token is the output of a Commerce Web Services SignOnWithToken() operation. This operation is what facilitates the authentication of an identity token (a signed and encrypted authentication token) that is used for the purpose of transaction origination authentication. Upon authentication of the identity token, a session token, which is short-lived, is issued for the purpose of all future operations.
As a result of this interaction, which is the transaction originator authentication described above, the Commerce Module does not ever receive, persist, or interact with the long-life (identity) token. In addition, the URL that is returned to the application is validate for single-use only.
The result of this?
A consistent customer experience.
A simple deployment.
Most importantly, merchant customer needs are quickly met and services are consumed more quickly than before thereby satisfying all participating members of the Platform.
This is a simple example of the power of a true Federated Identity infrastructure. There are more examples to come in due course.
What’s your perspective? Agree? Disagree? Anything to add? Critiques? The comment form is below…
* Although I am happy to discuss should anyone desire.
July 28, 2010