Security Patterns in Practice: Designing Secure Architectures Using Software Patterns

CHAPTER 5

Patterns for Authentication

This above all; to thine own self be true, and it must follow, as the night the day, thou canst not then be false to any man.

William Shakespeare, ‘Hamlet’

5.1 Introduction

The previous chapter discussed how users are identified in a system. Before they can perform any activities, both users and other systems must identify themselves and be authenticated – that is, prove to the system that they are who they say they are.

Identification and authentication (I&A) uses some kind of protocol to establish identity. I&A is the basis for authorization and for logging: it provides accountability. Once identity is verified, the system may provide a proof of authentication to avoid further authentications.

Figure 5.1 shows how the patterns described in this chapter are interrelated. Once a subject (a user or a system) has identified themselves to the system, we need to verify that their identity is correct. This is the function of the authentication function. AUTHENTICATOR is an abstract pattern, and we show here two concrete versions: REMOTE AUTHENTICATOR/AUTHORIZER and CREDENTIAL. CREDENTIALs may have also authorization properties, discussed later. In distributed systems where users may have access to several systems a Single Sign On service is very convenient¹. REMOTE AUTHENTICATOR/AUTHORIZER and CREDENTIAL have dual purposes; they can also be used for authorization if they include user rights. Chapter 6 describes how to let users access specific resources ...