Application Security 2: The CheckPoint Protocol

Introduction

As commented in my previous post, CheckPoint is a security pattern to avoid unauthorized access to a system.

The nice idea of the design pattern is to delegate complex validation behavior into specific classes which can manage events, response actions and statistics, completely transparent to your application. CheckPoints could be used to bypass validations for specific cases too. For example if you are debugging or testing your application, you don't want to be constantly bothered by timeouts and logins, you don't want to bias security statistics, and certainly you don't want to debug into someone's new bug merged in your repository, in the middle of your workflow.

The following sections describe how to use core classes for a typical application scenario.

Basic workflow

Let's assume an application is globally represented by a Singleton class, and it has different states. An state could be "in deployment mode" or "in testing mode". Each of these "modes" contain behaviors, implemented in specific CheckPoint subclasess. This simply means, you can use a Global Application class to answer a default CheckPoint class for your needs.

An example: Our Singleton manages application's state, and so it could be asked which CheckPoint should be assigned to each user, at a specific scenario he is in. This is, CheckPoint instances are associated to user sessions. Initially all newly created users will have a "invalid" or "unregistered" state. When the user begins the registration process, its session is given a CheckPoint instance to behave accordingly.

From here two different security scenarios are possible, depending on the registration state. Each scenario is represented by a CheckPoint subclass:

ASRegisterCheckPoint : Should be assigned while the (candidate) user is not confirmed as user. Maintains a registration object (ASUserRegistration), responsible to hold an unique link identifier, the registration time, and the corresponding candidate instance (ASCandidateUser). To optimize resources, a candidate user manages expiration (#hasExpiredRegistration) and that's a reason why is important to keep a #registrationDate.

ASDeployCheckPoint: This is a "common" CheckPoint which should be used for production systems, and when a registered user signs-in a system. It checks against typical login conditions, which we will se below in the Using the CheckPoint section.

Registering Users

Before anything else, create a repository and mock user to play with:

| cp newRegId |
cp := ASRegisterCheckPoint new.
newRegId := cp registrationId.
cp addNewUser: (ASCandidateUser new
    entityName: 'alphabetic name';
    username: 'alpha3';
    password: 'alphanumeric123';
    registrationId: newRegId;
    yourself).

Trying to add another candidate with the same username will raise an ASUserExists exception. Ideally you should catch and handle it appropiately in the context of your application. You can now query if you can register this candidate:

cp isValidPendingRegistrationId: newRegId.

and register as valid user in your system:

cp registerCandidateAsUser: newRegId.

Using the CheckPoint

Continuing with the Session-based example, login code which uses the CheckPoint could ask for the current user CheckPoint, and perform a global validate and retrieve:

user := self checkPoint 
  loginUserNamed: 'myuser'
  password: 'anypassword'
  machine: '0.0.0.0'.

The message send performs three major steps:

• Validate authentication settings for the provided parameters
• Validate if passwords match.
• Answer the user from the repository

You can also chain exceptions to manage fail conditions, logging messages or block an user:

loginExceptions
 ^ ASEmptyError , ASInvalidUsername , ASEntityNotFound , ASPasswordError , ASMaxUserFailCountError
  , ASMaxMachineFailCountError , ASMaxGlobalFailCountError , ASDenegatedAccess

and manage the exception properly:

[ cpUser := self checkPoint loginUserNamed: usernameString password: passwordString machine: '0.0.0.0' ]
 on: self loginExceptions
 do: [ :ex | ^ self handleFailedLogin: ex ].

CheckPoint verifications

Login an user should perform a number of checks which, many times, are application security specific. The default implementation is naive, but useful for many cases. For specific security requirements, validation settings are customizable by subclassing ASDeployCheckPoint and specializing the method #validateAuthSettingsLogin:password:machine:. This is how looks like as in the current release:

 (userString isEmpty or: [ userString isNil ])
  ifTrue: [ ^ ASEmptyError signal: 'Username' ].
  
 (passwordString isEmpty or: [ passwordString isNil ])
  ifTrue: [ ^ ASEmptyError signal: 'Password' ].
  
 (self isValidIpAddress: ipAddressString)
  ifFalse: [ ^ ASDenegatedAccess signal ].
  
 (self validationSettings allowedUsernameCharacters includesAllOf: userString)
  ifFalse: [ ^ ASInvalidUsername signal: 'Invalid characters ' , userString ].
  
 (self validationSettings allowedPasswordCharacters includesAllOf: passwordString)
  ifFalse: [ ^ ASPasswordError signal: userString ].

(Remember, this is not code checking on User-Agent side, this is Application Security so your application's security can be guarantee independently of UI code).

A first look at Validation Settings

If you have ever worked with an Expert System, you already know what a Rule-Base is, and probably have figured out that all verifications could be easily written using rules. Although currently Application Security does not use rules, it seems a good point to note the direction where our model should be going to (if you want to read a really cool chapter about Rules-Based Expert Systems, try the one from Robbie T. Nakatsu in Diagrammatic Reasoning in AI)

Validation setting objects are maintained by CheckPoints and useful during registration time. They notify authorization/authentication exceptions and answer limit settings like:

• Maximum size for characters allowed for a user name.
• Maximim size for characters allowed for a password.
• Characters allowed by a password.
• characters allowed by an user name.
• Expiration days for a password.
• Valid IP addresses

As they are CheckPoint specific, they could be changed at run-time for an user or a group of users, which is very handy for debugging purposes. And that's all for today, in the following post I will post how to set up password rules to customize validation settings. See you soon.