Checkpoint - Process Of Session Authentication has been explained here :
1. A user on the client attempts to make a connection through the enforcement
module to the server. The enforcement module matches the
traffic to a rule that specifies session authentication.
2. The enforcement module establishes a session authentication connection
back to the client host (the enforcement module knows the IP
address of the host, as this is indicated in the source IP address of the
original packet seen by the enforcement module). Because the session
authentication agent is running and listening on TCP port 261, the
connection from the enforcement module is successful.
3. The enforcement module challenges the session authentication agent
for authentication. The agent pops up a dialog box to the user, requiring
a username and password to authenticate access for the connection.
The user enters the appropriate username and password, which are
collected by the session authentication agent and then passed back to
the enforcement module over the session authentication connection
established in Step 2.
4. The enforcement module receives the authentication information and
authenticates it against a local or remote authentication database.
5. Assuming authentication is successful, the connection is added to the
connection table, and the original packet sent by the client in Step 1 is
forwarded on to the destination server.
6. Subsequent traffic generated between the client and server for the
connection initiated in Step 1 is permitted by the enforcement module.
It is important to note that the client must separately authenticate any
new connections through the enforcement module to the same destination
server or other destinations, which is unlike client authentication,
where the client could establish any number of new connections after
authentication.
Checkpoint - User Authentication
User authentication provides native, in-band authentication of
HTTP, FTP, TELNET, and RLOGIN connections. The VPN-1/FireWall-1
enforcement module provides security servers for each of these protocols,
which are application-layer daemons that can both emulate server-side
connections from a client (for the purposes of challenging the client for
authentication information) and spawn client-side connections to a server,
on behalf of other clients (after successful authentication). When user
authentication is configured for a rule, connection requests that match the
rule are intercepted and forwarded to the appropriate security server. For
example, when an HTTP request is sent from a client to a destination web
server, the enforcement module intercepts the request and passes it to the
HTTP security server, which establishes an HTTP connection with the client
(the client thinks that it has established a connection with the destination
web server). The HTTP security server then challenges the client for authentication
details. The client returns authentication information, which is
authenticated by the authentication scheme defined for the user object that
matches the username supplied by the client. Once authentication is successful,
the security server establishes a new connection to the destination web
server, and passes back to the source any HTTP traffic from the destination.
All subsequent traffic is passed over two connections-one from the web client
to the security server and the second from the security server to the web server.
1. A user on the client attempts to make a connection through the enforcement
module to the server. The enforcement module matches the
traffic to a rule that specifies session authentication.
2. The enforcement module establishes a session authentication connection
back to the client host (the enforcement module knows the IP
address of the host, as this is indicated in the source IP address of the
original packet seen by the enforcement module). Because the session
authentication agent is running and listening on TCP port 261, the
connection from the enforcement module is successful.
3. The enforcement module challenges the session authentication agent
for authentication. The agent pops up a dialog box to the user, requiring
a username and password to authenticate access for the connection.
The user enters the appropriate username and password, which are
collected by the session authentication agent and then passed back to
the enforcement module over the session authentication connection
established in Step 2.
4. The enforcement module receives the authentication information and
authenticates it against a local or remote authentication database.
5. Assuming authentication is successful, the connection is added to the
connection table, and the original packet sent by the client in Step 1 is
forwarded on to the destination server.
6. Subsequent traffic generated between the client and server for the
connection initiated in Step 1 is permitted by the enforcement module.
It is important to note that the client must separately authenticate any
new connections through the enforcement module to the same destination
server or other destinations, which is unlike client authentication,
where the client could establish any number of new connections after
authentication.
Checkpoint - User Authentication
User authentication provides native, in-band authentication of
HTTP, FTP, TELNET, and RLOGIN connections. The VPN-1/FireWall-1
enforcement module provides security servers for each of these protocols,
which are application-layer daemons that can both emulate server-side
connections from a client (for the purposes of challenging the client for
authentication information) and spawn client-side connections to a server,
on behalf of other clients (after successful authentication). When user
authentication is configured for a rule, connection requests that match the
rule are intercepted and forwarded to the appropriate security server. For
example, when an HTTP request is sent from a client to a destination web
server, the enforcement module intercepts the request and passes it to the
HTTP security server, which establishes an HTTP connection with the client
(the client thinks that it has established a connection with the destination
web server). The HTTP security server then challenges the client for authentication
details. The client returns authentication information, which is
authenticated by the authentication scheme defined for the user object that
matches the username supplied by the client. Once authentication is successful,
the security server establishes a new connection to the destination web
server, and passes back to the source any HTTP traffic from the destination.
All subsequent traffic is passed over two connections-one from the web client
to the security server and the second from the security server to the web server.
