Chapter 5. Authentication

Table of Contents

1. Security
2. NarutoCredentials
Step 1: Enter Credentials
Step 2: Start Transport
Step 3: End Transport
Final Step: Validate User

The user authentication state machine.

1. Security

This API uses safe methods to ensure privacy and prevent abuse. However, good security must include all aspects of the environment. An employee, phisher, or professional hacker could find away to access the computer or somehow abuse the service. There is no true security: there is only levels of difficulty. In this case we simply avoid transmitting sensitive data over the network in the first place. It would be wise to ensure that the computer systems and applications are also secure. In addition, as with all web services, restricting access to only the expected network addresses and using a VPN are the status quo for providing security. These measures can be completely accomplished outside the application using Apache and ssh.

2. NarutoCredentials

The NarutoCredentials implementation defines how the calling users will be verified by the message board and how that sensitive information is protected.

Figure 5.1. NarutoCredentials State Machine

NarutoCredentials State Machine

Step 1: Enter Credentials

At this step, the originating user enters their credentials for the remote message board. The data is stored in memory for further use. The password remains in memory and will never be passed on to any other point.

  // user calls:
  $wpc = new NarutoCredentials;

Step 2: Start Transport

At this step, the originating user passes their credentials to a local Naruto implementation (client) for transport over the network. The client then creates a salt key that is unique to the user's request would only be known by the client and the server that will receive it. Often the salt is constructed from the request parameters. This is important so that the salt cannot be hijacked for any other action. Finally the client the client will get export a token from the credentials which contains the current user name and signature (no password). The signature is constructed from the password and salt together using strong 1-way encryption that cannot be reversed.

  // client calls:
  $token = $wpc->exportAuthToken($salt);

Step 3: End Transport

At this step, the server application receives the information from the client. The server then recreates the salt just as the client did and imports the token recreating the credentials At this point the credentials will store the salt value in memory for later use in validating the user.

  // server calls:
  $wpc = new NarutoCredentials;

Final Step: Validate User

This step is completed by the message board that has implemented the Naruto interface. If the user invoked this from step 1, the user will be validated by directly comparing the passwords. If the server invoked this from step 3, a signature will be constructed from the salt and message board's password as in step 2; then the signatures will be compared.

  // message board calls:
  $username = $wpc->getUserName();

  // Next the message board looks up the password by its own means.
  // $password = lookupUserPassword($username);

  if (!$wpc->validateUser($password))
      throw new NarutoException('User Not Authorized',NarutoConstants::E_AUTH);