How Does SAA Work

Check Point clients are located between the computer's network adapter and TCP/IP stack. This lets the client intercept all packets entering or leaving the computer and to encrypt or decrypt them as necessary.

Important - In this version of Remote Access Clients the SAA DLL cannot determine which site a user is authenticating to. Therefore the client might give the authentication credentials supplied by the Authentication Agent to the wrong site. The authentication will probably fail, but the wrong site will have the user's credentials.

When you create the DLL file, try to prevent the wrong site from accidentally receiving private information. For example, the Authentication Agent can display the site name, as provided by the username function, to let users and Authentication Agent distinguish between different sites.

Scenario with a non-SAA Authentication Method

This scenario describes an example of what happens when a user, Hugo, connects to a site on the London gateway with a non-SAA authentication method.

  1. Hugo initiates a connection to a host in the London gateway's encryption domain.

  2. The Check Point client sends Hugo's username to the Security Management Server that also manages the Check Point clients.

  3. The Security Management Server challenges Hugo to authenticate himself according to the authentication scheme configured for that site.

  4. Hugo enters the response to the challenge (usually a password).

  5. If the response was correct, the Check Point client and the Security Management Server exchange a session key. This key is used to encrypt the data connection.

Scenario with SAA

This scenario describes an example of what happens when a user, Hugo, connects to a site on the London gateway with SAA Authentication. The Check Point client acts as a proxy for a third party Authentication Agent.

  1. The Authentication Agent exports a small number of functions in an Authentication DLL file (located on the user's machine).

  2. These functions let the client forward the Security Management server's challenges to the Authentication Agent on Hugo's machine.

  3. The client forwards the responses from the Authentication Agent back to the Security Management Server.

  4. When Hugo initiates a connection to a host in the London gateway's encryption domain the Check Point client calls the appropriate functions in the Authentication DLL rather than displaying the standard login windows.

  5. When the Security Management Server decides to accept or deny the connection, a status indicator is sent to the Authentication Agent.

  6. The Check Point client and the Security Management Server exchange a session key. This key is used to encrypt the data connection.

Note - The SAA DLL is only responsible for providing the username and the correct responses to the Security Management server's challenges. The actual key exchange is still done by the Check Point client.