This section will present the different steps involved in an AppGate session. It will briefly go through many aspects of how the system works.
Before a session can be initiated, the user must first launch an AppGate client. The user may then be presented with a connection dialog and asked to give the name of the AppGate Security Server he/she wishes to connect to. For the Java Web start version of the client all the configuration data is filled in automatically.
It is also possible to connect to the AppGate server using a standard SSH2 client, but the functionality available will be limited to port forwards and server commands.
The AppGate client establishes an encrypted communication channel to the AppGate server. All traffic between the client and the AppGate server is sent through this encrypted channel. The traffic may also be compressed if desired. This channel consists of a single TCP connection which normally runs on port 22 (SSH), other ports can also be used if needed.
The session establishment is done using the standard SSH2 protocol. It involves a Diffie-Hellman key exchange to negotiate session encryption keys. If the client has previously connected to the server or if it has been pre-configured with its public SSH keys it will verify that the keys match to protect against man-in-the-middle attacks. If the keys are not known to the client then the user will have to confirm that it is the first connection to the server.
The AppGate Security Sever consults its user account sources to find out whether the user has an account. The two most common account databases are LDAP (Active Directory) and the local AppGate server database. It is possible to use multiple account sources.
If an account is found, the system will proceed to authentication. As part of the connection dialog, the user chooses authentication method. The AppGate server checks with the account information whether that authentication method is available.
Several methods may be available at the same time for the same user. The user may already have given the credentials or will now be prompted to do so. The AppGate Security Server will use the credentials and consult the appropriate subsystem to authenticate the user.
When logging on, the AppGate client sets a number of attributes, for instance the IP address of the client, and which AppGate client is used. These attributes can later be used in access rules or client commands. See Section 12.3, “Attributes” for details.
If the user is authenticated, the AppGate server will now instruct the AppGate client to perform all defined Client Checks and ask whether an AppGate Device Firewall is available.
The results of all Client Checks and DFW presence checks are fed back to the AppGate server. Client Check result strings are set as attribute values. Access rules can later on use those attribute values to control which services the user should have access to during this session.
The AppGate server will now perform the authorization decision. Authorization is done by evaluating all applicable Access rules which are defined for the user.
All Access rules will evaluate to either true or false. Access rules can be attached to Roles and to references to Services and will govern whether those Roles and Services shall be allowed for this session.
If the user has access to only one role or if all the roles are combinable then, by default, the role selection will happen automatically without user intervention.
If not all of the roles the user has access to are combinable or if combinable merging has been turned off then the user must manually select which role/roles the session should use. The role selection can not be changed during a session. If no roles are available, for example due to access rule restrictions, then the session is terminated.
Along with the Role there may be an AppGate Device Firewall rule set defined. If so, that rule set is transferred to the client and activated.
As soon as the roles have been selected, the AppGate server will inform the AppGate client of all the Services which are part of the roles.
The different Services are presented to the user. Depending on which AppGate client the user is running and how it is configured, the Services will be presented in different ways. Perhaps the most common, and very user friendly, is the portal-like icon view of the AppGate Client.
When using a web browser for client-less access using SSL, web services will be immediately available and the discussion below will not be applicable.
In the icon view, the user can start a Service by double-clicking on its icon.
When a Service is started, all its Components are activated. The most common Component type is the IP access rule. An IP access rule enables access to the specified IP addresses / host names and port numbers.
When the client activates an IP access rule, it asks the AppGate server to prepare to handle traffic. The client will also make the necessary preparation on the client computer to make sure that the relevant application protocols and data traffic will flow through the AppGate system - this is called traffic capture.
There are two methods that can be used for traffic capture: Port Forward and IP tunneling.
Port Forward utilizes TCP sockets on the client computer. The AppGate client opens listening sockets on the loop-back interface and forwards all connections through the encrypted tunnel. This method is very portable and non-intrusive to the operating system.
IP tunneling routes IP packets through an encrypted tunnel with a Virtual Network adapter on the client computer. IP tunneling requires that the AppGate IP tunneling driver is installed on the client computer. IP tunneling is very versatile and handles TCP, UDP and ICMP in both directions, to whole networks, ranges of hosts and ports.
There are a number of other components that all can be combined into a Service, Client commands, Server commands, proxies etc.
When the user closes the connection to the AppGate server the session is terminated, all traffic flows are stopped and the user is logged out.
If the Roaming feature is used, the session may be temporarily Suspended but still active. Later on it may be Resumed. This is very useful for mobile applications. See Section 3.3.5, “Roaming (Suspend/Resume)” for details.