Design Patterns for Identity Systems

These are design patterns in the Christopher Alexander sense rather than the object oriented design sense: they address the physical and network environment rather than focusing on software abstractions. The patterns were introduced in my book Authentication.

There are four patterns: local, direct, indirect, and off-line.

Here is a brief description of each authentication pattern:

  • Local: All checking takes place within the physical confines of the device. For example, a password-protected home computer follows this pattern because it typically stores the user name and password inside the physical confines of the computer. A door lock with a key pad usually follows this pattern since the unlock code is stored inside the lock.
  • Direct: A pattern used in remote access: the client contacts a server, and the server performs the checking itself based on information it maintains itself. Blogging software typically does this, since each blog maintains its own database of user names and corresponding passwords.
  • Indirect: Another remote access pattern: the client contacts the server, but the server relies on a separate authentication server to verify the client user’s identity. There are many examples of this: OpenID, RADIUS, Kerberos, TACACS, Microsoft domains, etc.
  • Off-line: Another remote access pattern: the client contacts the server, and the server relies on cryptographic information to authenticate the client’s user without contacting a third party. Browsers use this pattern to validate a server’s certificate: they rely on the built-in list of certificate authorities.

These patterns are useful because they capture key distinctions between different authentication systems:

  • Local versus the others: Local systems rely on physical security to protect the integrity of the authentication operation. The other patterns involve remote access and must be designed to deal with sniffing, replay, and other network-based risks.
  • Local/Direct versus Indirect/Off-line: This reflects the trade-off of relying on third parties to manage authentication. In the Indirect pattern we rely on a central authentication server; in the off-line pattern we rely on a third party to issue cryptographic certificates.
  • Direct versus indirect: This reflects the server trade-off between local and third-party management of authentication. Neither is ideal for all cases.
  • Off-line versus the other remote patterns: This reflects the benefits of generally autonomous operation versus the problems of autonomy, in particular, revocation.