Designing Your Authentication and Authorization Model

By Chris Gideon

Most consumers have experienced the need for identification when making a purchase with a credit card. When it's time to pay, the cardholder is asked to provide some trusted form of identification. The consumer may have several forms of identification, such as loyalty, library, or frequent flier program cards. Though these cards do prove identity for each of those respective systems, they are typically not accepted. The reason is that the authority used to issue those alternate forms of identification is not trusted by the merchant or bank. For most banking or credit card transactions in the United States, the trusted authority is the federal or state government. A driver's license or passport issued from the government is the preferred form of identification.

This experience may vary somewhat, depending on the cardholder's nationality, or if the purchase is made in another country. A key attribute of the identification in the process is the photo of the consumer. The determination of credit availability is a separate process once identity is confirmed.

This example is analogous to the authentication process experienced by users of information systems today. The user may have many usernames and passwords for several different systems in his or her company's enterprise network. The problem expands when partnering with other companies and additional systems are brought into play.

An information technology architect ...

Get SharePoint 2010 Enterprise Architect's Guidebook now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.