1.2 Architecture and High-Level Flow of Events

Before delving into the details of the various operation modes, one must look into the flow of events required to get an SSLVPN workstation connected to the server. This connection should be done in such a way that it can transmit data to the non HTTP application it is protecting. The diagram below shows a basic SSLVPN architecture where the SSLVPN server is running on its own hardware platform, with a non HTTP based application sitting behind it. In order to access this non- HTTP application from the SSLVPN client, the following steps need to take place.

Figure 1-1 Accessing a non- HTTP application from the SSLVPN client

  1. The SSLVPN client workstation will hit the SSLVPN server protected resource on the Access Gateway. The Access Gateway must have a proxy service defined for the SSLVPN server so that all initial requests from a browser to the SSLVPN server (for path /sslvpn/login) will go to the Access Gateway.

  2. If the user is not already authenticated for that protected resources, the user will be redirected to the Novell Identity Server (IDP) to login. The user will be presented with a login page where the credentials are entered and submitted. The credentials will then be validated against a back-end user store (eDirectory in the above example). Assuming the user's credentials are validated, an artifact gets sent from the Identity server to the browser.

  3. The browser redirects the artifact to the Access Gateway. The Access Gateway sends the artifact back to the Identity server over the SOAP backchannel (direct communication between Access Gateway and IDP), and the IDP server responds with an assertion, including user specific details. After the Access Gateway consumes this assertion it sends another HTTP redirect back to the browser. A session cookie is sent back for use with subsequent requests for this SSLVPN resource, telling the browser to send the request to the SSLVPN server (/sslvpn/login).

  4. The browser sends the request to the SSLVPN /sslvpn/login via the Access Gateway. The Access Gateway, with the SSLVPN Identity Injection enabled for this resource, adds the required headers (user information, sessionID and roles) to the HTTP headers of the outgoing request. For the header details, see http://www.novell.com/documentation/novellaccessmanager/adminguide/index.html. The SSLVPN server receives this request from the Access Gateway, identifies the user/role and locates the policy information for the role. This user policy information, as well as the SSLVPN client binaries (including the stunnel client) is sent back to the browser via the Access Gateway.

  5. The SSLVPN client software is initialized on the client, and a connection to the SSLVPN server is made. This connection is direct from the SSLVPN client to the server, and not via the Access Gateway. (The only SSLVPN specific traffic that continues through the Access Gateway are regular keep-alives to make sure the SSLVPN server and browser client are still active). When an application on the client tries to access a protected resource behind the SSLVPN server, the application data is tunneled to the server. It is then proxied or forwarded to the client, depending on the mode of operation. More details are discussed below.

Before looking at the flow in more detail, let's look at the two SSLVPN modes of operation and the components associated with each.