Continuing . . .
The problem with this Authenticated Identity Nirvana is that each of the places accepting such an Authenticated Identity would have to “trust” that all of the authentication policy issues are common among them all. That would mean that Amazon.com would have to agree that the Novell authentication I perform in the morning satisfies their authentication policy and that the UserID passed to Amazon.com by Novell could be used to access the Amazon.com databases without question. Not only is that being overly trusting, it would be bad business practice. Each enterprise has an obligation to their investors to be prudent in their business practices to ensure success; and putting that kind of trust in another company would be very imprudent.
The answer must lay in a middle ground. Enter stage left: efforts such as Liberty Alliance and SAML 2.0. The Liberty Alliance is formed by the participation of concerned enterprises to allow for the Federation of Identities.
Federated Identity: The association of disparate Identifiers between disparate parties via commonly agreed upon Authentication Policy and Attribute naming schemes.
In the case of Federated Identity, it is not the Identity that is used, rather it is the Identifier provided by the federation process and the agreement on specific Authentication Policies that used. This Identifier and Authentication Policy assertion are trusted because the information is provided in a digitally signed assertion (e.g., SAML). Also, the Identity Provider (IDP in Liberty terms) may be associated with the recipient of the Identifier via a legal contract spelling out the Authentication Policies to be used in each circumstance; the contract may provide remedies for breach of contract.
So, now we have something that represents an Authenticated Identity that survives process boundaries and can exist as an object in its own right (in the case of Liberty Alliance, it is a SAML assertion), however, we want more-much more . . .
More later . . .
posted by src at 10:35 AM
3 Comments:
In your example, the real problem isn't that it's bad business practice to trust another organization but in which organizations you trust. Real world stores trust mastercard, visa, amex, state issued id's, etc. for authentication and authorization decisions all the time.
Liberty and SAML are certainly interesting, well thought out and provide the user with new capabilities. I'm curious to see what you think of SXIP
Good to hear from you, Howard. Your comment plays to the opposite end of business trust than the one I was referring to. The two ends (IMHO) is "operational" and "business to business." The case you are citing is the "B2B" case. Here, indeed, trust is placed in another business--but only under the stipulations of a business contract. The "operational" case I was refering to is usually completely internal and based on operational structure and internal operational policy.
thanks for the comment. -src
Hmm, I'm not quite following what you mean by operational. In your example amazon trusting novell isn't "completely internal". I was really trying to distinguish between scale. I took your example to mean that n x m companies can be a very large number. In contrast, in the real world, inter-company trust is limited to small numbers. Either a number of partners a company is willing to deal with, or in a b2c case a small number of trust authorities (IDPs I guess) such as gov't IDs or credit card companies. In further reflection, I'm not sure the canonical Liberty example of book a flight, rent a car, book a hotel scales well enough, unless I as a consumer am limited to hotel and rental companies the airliine I choose has a relationship with. I'm not sure how many companies amazon would need to trust :)
I'm enjoying the blog, I'll keep reading :)
Post a Comment
<< Home