Federated Identity: Overlaying Integrations With Appropriate Security Controls
In yesterday’s post, I concluded by mentioning the concept of “governance.” Governance, as defined by Wikipedia, is:
“Governance relates to decisions that define expectations, grant power, or verify performance.”
In all software workflows, there is an element of governance. In the payments industry, this governance is required to ensure a truly holistic software solution is implemented in market. The IP Commerce Platform enables this governance, in part, through its implementation of Federated Identity capabilities.
Whenever I am called upon to discuss Federated Identity, I use a fairly common real-world example, the driver’s license. Consider, if you will, the purchase of alcohol at a restaurant. When you initiate the purchase (“I’d like a gin & tonic, please.”). The restaurant has to ensure you are of age…they do this by asking for your license.
How is this Federated Identity?
The restaurant does not “trust” you to provide them with your age. However, they do trust the entity that issued you a driver’s license. Your driver’s license is the credential, your age is a claim on that credential, and the DMV is the Identity Provider. The restaurant trusts the DMV and looks at your credentialed claim of age and, at that point, brings the gin & tonic to your table.
The process is not that dissimilar in software. There are a series of claims that are associated with your identity that drive workflow, or perhaps behavior, of the software application.
The Platform enables these Federated Identity implementations through several discrete toolkits (which are components to simplify the usage of an API). The toolkits, themselves, are designed for scenario-based implementations.
It is important to note that Federation through the Platform is both standards-based and “modality agnostic.” The latter of those two is wildly important. There exists a wide range of Federated Identity implementations in the market. You have, likely, heard of things such as OpenId, OAuth, SAML, etc. The power, and beauty, of the IP Commerce approach is that we enable the deployment of complex federated workflows regardless of which modality is employed on the front-end.
Let’s discuss some of the technology implementations of Federated Identity, as well as a Use Case associated with each.
Single-Sign On (SSO)
SSO is what was mentioned yesterday regarding leveraging the same credentials for multiple applications and is an extraordinarily important component for ensuring customer success. Leveraging the same credentials, in more than once place or in more than one application, represents a substantive timesaving measure. SSO capabilities are extended through the Platform from a Service Provider to eliminate the need for redundant user administration in the Software Companies application. This is valuable to the end-user and a sticky way to cement a customer relationship.
For example, while developing a Commerce Module that provides online transaction management. The team from aurionPro used the SSO Toolkit to build an integration between their workflow and that of any other Software Company who leverages the Platform and desires to use the Transaction Management Module. The same sets of credentials that are used for processing transactions are leveraged to authenticate for transaction management…the customers identity permeates the entirety of the workflow.
Claims Based Authentication
Remember the “claim” of age on a driver’s license? Claims extend not only to access control but also to supporting business workflow requirements. For example, a Service provider who has enabled the usage of corporate purchase cards can allow the definition of pre-set spending limits at the time of authentication. This is a “claim” on the identity of not only the merchant…but the consumer. And this claim propagates throughout the Platform enabling all to be aware, and drive their solution workflow, based on the claim.
The Platform delivers comprehensive federation capabilities. These capabilities enable all participants in the Platform to seamlessly interact and ensure their business requirements are met while, simultaneously, delivering a seamless customer experience.
This is governance.
But, this is also only a component of the governance capabilities provided via the Platform and a requisite for open APIs.
Tomorrow, we discuss Commerce Business Rules.
What’s your perspective? Agree? Disagree? Anything to add? Critiques? The comment form is below…
June 8, 2010