Digital Identity Management

This section explores the most important building blocks of digital identity management, including authorization and authentication.

AuthorizationDefining Who Can Do What

Like many elements of security, there are static and dynamic aspects to authorization. The static aspect deals with defining which entities get rights to perform an operation, access part of the system, or access part of the database. The most common approach is to have a trusted user, such as the system administrator, define user rights by individual or by class. For example, if you're designing a medical records system, you might permit a patient to access all of his own history but not any data about anyone else.

The dynamic aspect of authorization concerns checks made to ensure that a given user or entity has the necessary rights to perform the operation or to access a certain part of the system or database. In sophisticated systems these checks need to happen at runtime because the authorization rules may be based on a variety of runtime parameters, including the role the user has assumed while accessing the system, her prior behavior, the state of the system, or even the behavior of others using the system at the same time.

There are a number of technologies and rights management systems that you can use, or tie in to, to provide authorization and access control. Lightweight Directory Access Protocol (LDAP) is a common one. Another is role based access control (RBAC), a generic name for technologies that provide authorization based upon user role. If you need to provide file system authorization, ACLs (access control lists) may be all you need. It's a good idea to isolate the systems you use for authorization by wrapping them with your own authorization layer. This way you can swap out one type for another as the requirements of the system change over time.

AuthenticationProof of Identity

Authentication is the process a system uses to ensure that an entity is who or what it claims to be. This can be important as the precursor to authorization, or it may be required to simply engage in a trusted transaction. The most appropriate authentication technology depends on whether you have a closed or an open system and whether or not you require third-party certification of identity.

Closed Systems

In closed systems, there is little or no need for an independent third party to certify an identity. The system itself, by its structure and/or operation, provides for acceptable levels of authentication. Many enterprise applications that grant specific rights to authenticated users are closed. Once the system administrator has registered a user ID with the system (either directly or through a directory) and provided it with the necessary system access (e.g., a password and a token), that user is now recognized as an authenticated, certified user whenever she successfully logs in to the system.

Authentication in closed systems is usually based on one or more of the following:

• Something you know for example, a password

• Something you have for example, a smart card or a computer that has been uniquely identified, either through a machine fingerprint or an actual unique identifier stored in the processor or the motherboard

• Something you are (biometric) for example, a thumb print or a voice print

A combination of any two is normally considered strong authentication. Extremely secure environments may require all three, or multiple applications of each.

Of course, the most common, and certainly most insecure , authentication mechanism by far is a simple password, which is usually easily guessed. When system administrators mandate secure passwords, users often make the system even less secure by writing theirs down on a scrap of paper or allowing their favorite Web browser to save them for easy reference. Don't be lulled into a false sense of security because your system requires a password!

From a tarchitecture perspective, we recommend abstracting the approach you use for authentication. Many systems start with a simple password system and evolve through use or customer demand to require something stronger.

Open Systems

Unlike closed systems, open systems require an independent third party to authenticate a user. Examples of open systems include a secure e-mail between two parties, and secure communication links between applications on the Web. In this case we need some kind of certification by a third party that the communicating entities are who they claim to be.

We've faced the problems of open systems before, and we've solved them in similar ways. In the 18th century, a gentleman scientist who wanted to visit a member of the Royal Society he hadn't met, to study in his library, for example, brought a letter of introduction from a colleague known to both to show that he could be trusted. If the host wanted to be extra sure that his visitor was who he claimed to be, he would compare the signature of the letter with the signature on correspondence from the mutual colleague, in order to make sure that the letter hadn't been forged. We do the same thing today, except that we now use certificate authorities and digital certificates instead of venerable gentlemen and parchment and ink. These certificates and the trusted third party provide the necessary levels of authentication for open transactions.

The idea is that you prove who you are to a trusted third party, who gives you a digital certificate signed with their private key. Anyone can use the trusted third party's public key to verify the certificate, and since they trust the signer and the signer is saying that you are who you claim to be, they can trust you. This hierarchy of trust can extend in a certificate chaineach certificate signed by an agency that vouches for it, until it reaches the top; the certificate authority.

Certificate authorities support certificate revocation, which means that if you lose your private key or someone up the certificate chain has their security compromised, the certificate corresponding to the lost key can be revoked. Then you get another certificate, and everything continues as usualexcept that anyone presenting the revoked certificate will not be authenticated.

The problem with certificate revocation is that sometimes you have to be able to talk to the certificate authority in real time to make sure that a certificate you want to authenticate has not been revoked, and for isolated subnets or disconnected applications this isn't possible. Also, if you run your own certificate authority, you must ensure that your system will work 24 hours a day, 7 days a week.

For this reason, you should carefully consider whether your system needs revocable authentication. If you combine certificate-based authentication with other information, it may not be necessary. For example, in one system we know of, the server checked the IP address of the caller as well as the caller's certificate. Even if the client's certificate and private key were stolen, the server would log and disallow the transaction if the originating IP address was incorrect.

There are several challenges associated with certificate-based authentication. Let's start with the first step, proving who you are to the trusted third party. Some certificate authorities have a very poor record of verifying these claims, and several multi-million dollar lawsuits have been filed over inappropriate verification procedures. In addition, some certificate authorities have hurt themselves through deceptive marketing practices. Simply put, how can you trust a certificate authority who deceives customers? There is no undisputed world-wide leader in certificate management. There are several for-profit, not-for-profit, quasi-governmental, and governmental certificate authorities, all of which hinder the search for global solutions.

In addition to these technical and operational challenges is the challenge of complexity exposed to average users who may wish to use, or who are forced to use, digital certificates. The usability associated with acquiring, managing, and using certificates is abysmal. Until it improves , the use of certificates will continue to remain relatively low.

Hybrid Systems

Your application may have aspects of both an open and a closed system. Consider corporate e-mail. It is closed, in that a user can probably be acceptably authenticated with the same user ID and password that gave him access to the corporate network when he first logged in. When receiving an e-mail from another internal user, he can be fairly confident that the person who purportedly sent the mail did send it.

The system is open, in that this user may need to send and receive secure e- mails to and from external entities. Suppose this same user receives a distressing e-mail from his outside attorney. It would be good if there was a way to certify the identity of the sender. Hybrid systems will increase as we find ways to use Web services and open our business processes to trusted and semitrusted partners .