Chapter 3 Sun ONE Portal Server, Secure Remote Access Architecture

This chapter describes the Sun™ ONE Portal Server, Secure Remote Access (SRA) architecture. It describes the key components of SRA with respect to their role in providing secure remote access to corporate intranet resources from outside the intranet (for example, through the Internet).

Overview of Sun ONE Portal Server, Secure Remote Access

SRA offers browser-based secure remote access to portal content and services from any remote browser. SRA is a cost-effective, secure access solution that is accessible to users from any Java™ technology-enabled browser, eliminating the need for client software. Integration with Sun™ ONE Portal Server software ensures that users receive secure encrypted access to the content and services that they have permission to access.

SRA is targeted toward enterprises deploying highly secure remote access portals. These portals emphasize security, protection, and privacy of intranet resources. The SRA architecture is well suited to these types of portals. The gateway, NetFile, and Netlet features of SRA enable users to securely access intranet resources through the Internet without exposing these resources to the Internet.

The gateway, residing in the Demilitarized Zone (DMZ), provides a single secure access point to all intranet URLs, file systems, and applications. (A DMZ is a small protected network between the public Internet and a private intranet, usually demarcated with firewalls on both ends.) All services such as Session, Authentication, and the Desktop reside behind the DMZ in the secured intranet. Communication from the client browser to the gateway is encrypted using HTTPS. Communication from the gateway to the server and intranet resources can be either HTTP or HTTPS.

SRA also provides Netlet technology, which enables a secure connection between a client running a Java enabled browser and a TCP/IP application running on a server in the corporate intranet. For remote file access, SRA provides NetFile technology. The Netlet and NetFile applets are downloaded to the client machine.

Relationship Between Portal Server and SRA

Portal Server can function in two modes—open and secure—as explained in the following sections.

Open Mode

In open mode, you install Portal Server without SRA. The typical public portal, such as my.yahoo, runs without secure access using only the HTTP protocol. Although you can configure Portal Server to use the HTTPS protocol in open mode (either during or after installation), secure remote access is not possible. This means that users cannot access remote file systems and applications.

The main difference between an open portal and a secure portal is that the services presented by the open portal typically reside within the demilitarized zone (DMZ) and not within the secured intranet.

If the portal does not contain sensitive information (deploying public information and allowing access to free applications), then responses to access requests by a large number of users is faster as compared to the secure mode.

Figure 3-1 shows Portal Server configured for open mode. In this figure, Portal Server is installed on a single server behind the firewall. Multiple clients access the Portal Server system across the Internet through the single firewall, or from Web proxy server that itself sits behind a firewall.

Secure Mode

In secure mode, you install Portal Server with SRA. Secure mode provides users with secure remote access to required intranet file systems and applications.

The main advantage of SRA is that only the IP address of the gateway gets published to the Internet. All other services and their IP addresses are hidden and never published to a Domain Name Service (DNS) that is running on the public network (such as the Internet). The result is that your organization publishes a single IP address and provides secure access to all your web servers and applications that you integrate with Netlet, Netfile, and Rewriter.

In this case, the gateway resides in the demilitarized zone (DMZ). The gateway provides a single secure access point to all intranet URLs and applications, thus reducing the number of ports to be opened in the firewall. All other Sun ONE services such as Session, Authentication, and Portal Desktop, reside behind the DMZ in the secured intranet. Communication from the client browser to the gateway is encrypted using HTTP over Secure Sockets Layer (HTTPS). Communication from the gateway to the server and intranet resources can be either HTTP or HTTPS.

Figure 3-2 shows Portal Server installed with SRA. SSL is used to encrypt the connection between the client and the gateway over the Internet. SSL can also be used to encrypt the connection between the gateway and the Portal Server system. The presence of a gateway between the intranet and the Internet extends the secure path between the client and the Portal Server system.

You can add additional servers and gateways for site expansion. You can also configure the components of SRA in various ways based on your business requirements.

SRA Components

You can install SRA components on the Sun ONE Portal Server node, or on any other non-portal node (referred to as a separate node). Table 3-1 lists the various installable components and the nodes that they can be installed on.

Table 3-1 SRA Components and Nodes
Component	Node	Description
Gateway	Sun ONE™ Portal Server, separate Server	The gateway provides the interface and security barrier between remote user sessions originating from the Internet and your corporate intranet.
Netlet Proxy	Portal Server node, separate node	Netlet Proxy is an optional component. You can choose not to install it, or install it later. Netlet Proxy extends the secure tunnel from the client, through the gateway to the Netlet Proxy that resides in the intranet. This restricts the number of open ports in a firewall between the DMZ and the intranet. Netlet Proxy cannot be installed on a gateway node.
Rewriter Proxy	Portal Server node, separate node	Install the Rewriter Proxy to redirect HTTP requests to the Rewriter Proxy instead of directly to the destination host. The Rewriter Proxy in turn sends the request to the destination host.

SRA uses Sun™ ONE Identity Server software to store all its configuration information, except for information about the machines (such as host name, IP address), on the host where gateway is installed.

You administer the configuration information stored in Identity Server through the console modules of the respective components. These components are installed as part of the Identity Server administration console. The administration console provides a single point of administration for all SRA components.

In this figure, two client browsers are redirected by a load balancer, which sits in the DMZ, to one of two gateways, also located in the DMZ. Client 1 is performing a NetFile transaction. The NetFile traffic is routed by Gateway 1 to Portal Server 1, whose Rewriter Proxy directs the traffic to Other Host 1. Client 2 is performing both Netlet and NetFile transactions. Client 2’s Netlet and NetFile requests are handled by Gateway 2, which routes the traffic to Portal Server 2. The Rewriter Proxy on this host directs the NetFile traffic to Other Host 2. The Netlet Proxy on this host directs the Netlet request to Application Host 1.

SRA Gateway

The SRA gateway is a standalone Java process that can be considered to be stateless, since state information can be rebuilt transparently to the end user. The gateway listens on the configured ports to accept HTTP and HTTPS requests. Upon receiving a request, the gateway checks the header information to determine the type of request. The gateway consists of Eproxy (Encrypted proxy) and Rproxy (a reverse proxy) subcomponents. Eproxy is responsible for handling Netlet components. Rproxy is responsible for all non-Netlet components. Depending on the type of request, the gateway performs the following:


Note	This sample configuration illustrates the various components that you can use. There can be multiple installations and instances of the gateway and the Netlet Proxy.

Netlet request—Eproxy checks session validity and routes the request (traffic) to the requested server. The destination of the Netlet traffic is determined by the Netlet rule that the user clicked in the Portal Desktop. See "Netlet" for more information.

HTTP(S) traffic—Eproxy forwards the request to the reverse proxy. When the reverse proxy receives the request, it checks the session validity and forwards the request to the server as specified by the HTTP header. Upon receiving a response from the server, the reverse proxy translates the response so that all intranet links within the response will work on the extranet.

If you do not require Netlet functionality, you can disable Eproxy. In Figure 3-4, the requests are directly received and fetched by the reverse proxy.

All the gateway configuration information is stored in the Identity Server’s LDAP database as a profile. A gateway profile consists of all the configuration information related to the gateway except machine-specific information such as host name and IP address. All machine-specific information is stored in a configuration file in the local file system where the gateway is installed. This enables one gateway profile to be shared between gateways that are running on multiple machines.

As mentioned previously, you can configure the gateway to run in both HTTP and HTTPS modes, simultaneously. This helps both intranet and extranet users to access the same gateway: extranet users over HTTPS, and intranet users over HTTP (without the overhead of SSL).

Multiple Gateway Instances

If desired, you can run multiple gateway instances on a single machine. Each gateway instance listens on separate port(s). You can configure gateway instances to contact the same Portal Server instance, or different Portal Server instances. When running multiple instances of a gateway on the same machine, you can associate an independent certificate database with each instance of the gateway, and bind that gateway to a domain. In essence, this provides the flexibility of having a different gateway server certificate for each domain.

When you configure the gateway with multiple instances of Portal Server, the gateway automatically performs round-robin load balancing by logging in users with the different servers, alternately. The gateway also keeps a list of active servers to avoid trying to login users to an inactive server. This mechanism helps to avoid single points of failure with Portal Server.

When deploying the SRA gateway, you need to decide whether to have multiple instances on the same machine or on multiple machines.



Note	Session stickiness is not required in front of a gateway (unless you are using Netlet), although it is recommended for performance reasons. On the other hand, session stickiness to the Portal Server instances is enforced by SRA.

Proxy Configuration

The gateway uses proxies that are specified in its profile to retrieve contents from various web servers within the intranet and extranet. It is possible to dedicate proxies for hosts, and DNS subdomains and domains. Depending on the proxy configuration, the gateway uses the appropriate proxy to fetch the required contents. If the proxy requires authentication, it should be stored as part of the gateway profile that the gateway uses automatically while connecting to the proxy. The Rewriter components also use the proxy information to ensure that any URL that contains the host, or DNS subdomain or domain, specified in the proxy information, is rewritten to ensure that they are routed through the gateway.

Gateway and HTTP Basic Authentication

The gateway supports basic authentication, that is, prompting for a user ID and password but not protecting those credentials during transmission from the user’s computer to the site’s web server. Such protection usually requires the establishment of a secure HTTP connection, typically through the use of SSL.

If a web server requires basic authentication, the client prompts for user name and password and sends the information back to the requesting server. With the gateway enabled for HTTP basic authentication, it captures the user name and password information, and stores a copy in the user’s profile in Identity Server for subsequent authentications and login attempts. The original data is passed by the gateway to the destination web server for basic authentication. The web server performs the validation of the user name and password.

The gateway also enables fine control of denying and allowing this capability on an individual host basis.

Gateway and SSL Support

The gateway supports both SSL v2 and SSL v3 while running in HTTPS mode. If necessary, you can enable or disable SSL v2 support. You use the gateway service in the Identity Server administration console, to enable or disable specific ciphers. The gateway also supports Transport Layer Security (TLS).



Note	You can configure the gateway to use or not use SSL. Likewise, you can also configure the web server to use or not use SSL. See the Sun ONE Portal Server, Secure Remote Access 6.2 Administrator’s Guide for information on configuring the gateway to use SSL.

Personal Digital Certificate (PDC) authentication is a mechanism that authenticates a user through SSL client authentication. The gateway supports PDC authentication with the support of Identity Server authentication modules. With SSL client authentication, the SSL handshake ends at the gateway. This PDC-based authentication is integrated along with the Identity Server’s certificate-based authentication. Thus, the client certificate is handled by Identity Server and not by the gateway.

After the SSL session has been established, the gateway continues to receive the incoming requests, checks session validity, and then forwards the request to the destination web server.

The gateway server handles all Netlet traffic. If an incoming client request is Netlet traffic, the gateway checks for session validity, decrypts the traffic, and forwards it to the application server. In case Netlet Proxy is enabled, the gateway checks for session validity and forwards it to the Netlet Proxy. The Netlet Proxy then decrypts and forwards it to the application server.

Gateway Access Control


Note	Because 40-bit encryption is very insecure, the gateway provides an option that enables you to reject connections from a 40-bit encryption browser.

The gateway enforces access control by using URL Allow and URL Deny lists. Even when URL access is allowed, the gateway checks the validly of the session against the Identity Server session server. URLs that are designated in the Non Authenticated URL list bypass session validation, as well as the Allow and Deny lists. Entries in the URL Deny list take precedence over entries in the URL Allow list. If a particular URL is not part of any list, then access is denied to that URL. The wildcard character, *, can also be used as a part of the URL in either the Allow or Deny list.

Gateway Logging

Because the entire traffic comes through the gateway for all the services provided by Portal Desktop, Netlet, and NetFile, you can monitor the complete user behavior by enabling logging on the gateway. The gateway uses the Identity Server logging API for creating logs.

Reverse Proxy (Rproxy)

The SRA Rewriter can also be used as a reverse proxy. A proxy server serves Internet content to the intranet, while a reverse proxy serves intranet content to the Internet. Certain deployments of reverse proxy are configured to serve the Internet content, to achieve load balancing and caching. The Rewriter component of Portal Server achieves the functionality of rewriting the web content by reverse proxy.

Figure 3-4 illustrates how you can configure the SRA gateway as a reverse proxy or you can put a reverse proxy in front of the gateway to serve both Internet and intranet content to authorized users. Whenever SRA serves web content, it needs to ensure that all subsequent browser requests based on this content are routed through SRA. This is achieved by identifying all URLs in this content and rewriting as appropriate.

The Rewriter component of SRA performs this rewriting. An external ruleset identifies the URI in the content.

From the request, SRA identifies the URI of the intranet page or Internet page that needs to be served.

SRA uses the proxy settings in the administration console to connect to the identified URL.

The domain of the URI is used to identify the ruleset to be used to rewrite this content.

After fetching the content and ruleset, SRA inputs these to the Rewriter. All the identified URIs are sent through the URI Translator, a subcomponent of the Rewriter.

The original URI is replaced with the rewritten URI.

This process is repeated until the end of the document is reached.

The resultant Rewriter output is routed to the browser.

The following example shows how a simple URI is rewritten. Here the identified URI is a fully qualified URI (absolute URI):

Rewriter Rulesets

A ruleset is an XML file that contains rules for all types of web content, such as HTML rules to identify URIs in HTML content, JavaScript rules to identify URIs in JavaScript, and XML rules to identify URIs in XML content.

SRA defines four types of HTML rules (Attribute, JSToken, Applet, and Form), two types of JavaScript rules (Variable and Function), and two types of XML rules (Attribute and TagText), for a total of eight types of rules to identify URIs in any web content.



Note	The number of rules has been reduced considerably in Sun ONE™ Portal Server 6.2 from iPlanet™ Portal Server 3.0. You can also use the regular expression (*) in all rules, as opposed to limited support for certain rules in previous releases.

You can assign different rulesets for pages belonging to different domains. This helps to better manage rulesets as opposed to putting all rules for all domain pages in a single ruleset. Additionally, this domain-based assignment of rules increases portal performance, as specific rulesets are smaller in size.

You manage rulesets either through the Identity Server administration console or by using the rwadmin command-line interface.

For more information on managing rulesets, see the Sun ONE Portal Server 6.2 Administrator’s Guide and the Sun ONE Portal Server, Secure Remote Access 6.2 Administrator’s Guide.

default_ruleset: Used by the URLScraper provider to convert all URIs to absolute. SRA does not use this ruleset.

default_gateway_ruleset: Contains rules required to handle the Portal Desktop and gateway modules in the Identity Server administration console.

generic_ruleset: This is the most generalized ruleset and can handle web pages of simple and medium complexity. Complexity here is defined in terms the amount of JavaScript code present in a web page.



Note	Start by adding rules to the generic ruleset. Even if an application has a complex use of JavaScript code, the generic ruleset is sufficient to handle all the rewriting in most cases.

Rewriter and MIME Types

The Rewriter is rule-based and also decides on which content to rewrite based on the MIME type for the content. Out of the box, the Rewriter is configured to rewrite text/html, text/htm, application/javascript, and text/xml. You can modify this to handle different MIME types.

Using Accelerators with the Gateway

You can configure Crypto Accelerators, which are dedicated hardware co-processors, to off-load the SSL functions from a server's CPU. Using accelerators frees the CPU to perform other tasks and increases the processing speed for SSL transactions.

You can also configure an external SSL device to run in front of Secure Remote Access in open mode. It provides the SSL link between the client and Secure Remote Access. For information on accelerators, see the Sun ONE Portal Server, Secure Remote Access 6.2 Administrator’s Guide.

Netlet

Netlet enables a secure connection between an arbitrary client on a system that is running a Java-enabled browser, and a network resource behind a corporate firewall. The client can be behind a remote firewall and SSL proxy, or directly connected to the Internet. Netlet can provide secure access to fixed port applications and some dynamic port applications that are available on the intranet from outside the intranet. All the secure connections made from outside the intranet to the intranet applications through the Netlet are controlled by Netlet rules.

Netlet is an applet that runs on the browser. Netlet listens to and accepts connections on preconfigured ports, and routes both incoming and outgoing traffic between the client and the destination server. Both incoming and outgoing traffic is encrypted using an encryption algorithm selected by the user, or configured by the administrator. The Netlet rule contains the details of all servers, ports, and encryption algorithms used in a connection. Administrators create Netlet rules by using the Identity Server administration console.

Figure 3-6 shows how Netlet fits into the SRA platform. In this figure, each Netlet connection that is made to the destination host is described by a rule. The rule also describes the encryption algorithm to be used for that particular connection. The Listen Port on the localhost is the client machine port on which the Netlet applet listens. The Netlet applet sets up an encrypted TCP/IP tunnel between the remote client machine and intranet applications on the remote hosts. The applet encrypts the packets and sends them to the gateway, and decrypts the response packets from the gateway and sends them to the local application. All client requests are routed through the EProxy. EProxy handles only Netlet requests and passes any other request to the RProxy. EProxy parses the Netlet requests and passes them to the Netlet Proxy (if it is enabled) or directly to the destination host.

How Netlet Works

The Netlet contains two server-side components and one client-side component. The server side components are:

Users invoke Netlet through the Netlet channel on the Portal Desktop. When a user clicks the appropriate link in a Netlet channel, Portal Server receives a request to download the Netlet applet. The Netlet applet is downloaded along with a preconfigured rule, which consists of the following information:

After obtaining the appropriate permissions from the user, the Netlet applet starts listening for connections on the preconfigured ports. Next, it accepts the incoming connections, and routes the traffic through the Eproxy to the destination server after encryption. Upon receiving Netlet traffic, the Eproxy decrypts and routes the traffic to the appropriate destination server. Instead of the Eproxy decrypting and routing the traffic to the appropriate destination server, you can designate a Netlet Proxy between the Eproxy and the destination server. In this scenario, the Eproxy simply forwards the traffic to the Netlet Proxy, which decrypts and routes the traffic to the destination servers.

Figure 3-7 illustrates using a third party proxy to limit the number of ports in the second firewall to one. You can configure the Gateway to use a third party proxy to reach the Rewriter and the Netlet Proxies.

Netlet and Authentication

Though Netlet does not authenticate users, it needs a valid SSO token for carrying out its operations. Netlet passes the SSO token with every request that is sent from the client to the Eproxy. Upon successful validation of the SSO token, the traffic is routed to the destination server. The Netlet applet also displays a warning message before accepting any new connections (on the machine where the applet is running). The user must acknowledge this message and type the Netlet password before accepting new connections. You can configure this message to be a check box, or you can force the user to type a password before the connection is allowed.

Static and Dynamic Port Applications

Static port applications run on known or static ports at which they can be contacted by clients. Examples include IMAP and POP servers, and Telnet daemons. In the case of static port applications, the Netlet rule includes the destination server port so that requests can be routed directly to their destinations.

Dynamic port applications agree upon a port for communication as part of the handshake. For dynamic applications, you can include the destination server port as part of the Netlet rule. The Netlet needs to understand the protocol and examine the data to find the port being used between the client and the server. FTP is a dynamic port application. In FTP, the port for actual data transfer between the client and server is specified through the PORT command. In this case, the Netlet parses the traffic to obtain the data channel port dynamically.

Currently, FTP and Microsoft Exchange are the only dynamic port applications that Portal Server supports.



Note	Although Exchange 2000 is supported with Netlet, the following constraints apply: You must configure Exchange to use STATIC ports. Netlet does not work with Windows 2000 and XP because Windows 2000 and XP clients reserve the Exchange port (port 135) for the RPC Portmapper, which Active Directory uses. Previous versions of Windows did not reserve this port. Because the port is reserved, you cannot assign Netlet to it, and thus the port cannot provide the necessary tunneling. The Outlook 2000 client has the limitation that it does not enable you to change the port on which you want to connect to the Exchange server.

Encryption Algorithms

An encryption algorithm is used to encrypt/decrpt the traffic that is routed by the Netlet. These algorithms are selected by the user or administrator from the list of available algorithms. Netlet uses standard SSL algorithms for encrypting traffic. Netlet currently uses two different types of SSL implementations based on their availability of JSSE at the client side (browser).

The Netlet algorithms to be used for encryption and decryption are specified on a per rule basis. This increases the flexibility and security for all the Netlet connections between the client and the destination server.

The Netlet Applet automatically detects the capability of the client side JVM and downloads appropriate jar files for its functioning. For example if the Netlet detects a Java 2 VM with JSSE capability, only SSL algorithms are downloaded, not KSSL algorithms, hence reducing download time.

Further if the gateway is running in HTTP then the Netlet does not use any encryption-- it is considered to be plain and none of the encryption libraries will be downloaded with the Netlet applet.

At the server side, both Eproxy and Netlet Proxy use the standard JSS/NSS SSL library.

Note : For these algorithms to be successful as the part of SSL handshake, the corresponding gateway instance must have these algorithms enabled in its profile.

Algorithms Used When JSSE is Available

If the Netlet Applet is running on a browser that has Java 2 VM installed and if that version of JVM supports JSSE, then the Netlet Applet uses JSSE as its SSL implementation taking advantage of the SSL implementation that's available at the client side.

In this case, the Netlet Applet uses the following algorithms to connect to the gateway:

Algorithms Used When JSSE is not Available

If the Netlet Applet is running on a browser that has Java 1 or Java 2 VM where JSSE is not available, the Netlet Applet defaults to its own custom SSL implementation called KSSL.

In this case, the Netlet Applet uses the following algorithms to connect to the gateway:

Netlet Rules

A Netlet rule contains all the information that is needed for a Netlet connection between the client and the destination server. A Netlet rule consists of the following fields:

Netlet rules are based on how you specify the destination host. The two types of Netlet rules are:

Static rule—Specifies the destination host as part of the rule. In a static rule, the user cannot specify or change the destination host. For example, you could have an IMAP rule that enables connecting to a particular IMAP server, but the user could not change the IMAP server name.

Dynamic rule—The destination host is not specified as part of the rule. The user can specify the destination host in the Netlet provider. For example, an administrator defines a Telnet rule in which the user can specify the particular host for Telnet connection.

Netlet Provider

The Netlet provider is a Portal Server Portal Desktop provider that supplies a channel with links for initiating Netlet connections as defined by the rules. The channel displays one link for every Netlet connection that can be initiated by a user. The Netlet provider also supplies the user with an interface to edit dynamic rules. Using dynamic rules, users can add or remove destination hosts as required. Users can also set the password for validating themselves at the time of invoking a new Netlet connection.

Netlet and Application Integration

Netlet works with many third parties such as Graphon, Citrix, and pcAnywhere. Each of these products provides secure access to the user’s Portal Desktop from a remote machine using Netlet.

Netlet and Split Tunneling

Split tunneling is when a VPN client can connect secure sites (for example, by using Netlet) and non-secure sites, without having to connect or disconnect the VPN—in this case, Netlet—connection. The client determines whether to send the information over the encrypted path, or to send it by using the non-encrypted path. The concern over split tunneling is that you could have a direct connection from the non-secure Internet to your VPN-secured network, via the client. Turning off split tunneling (not allowing both connections simultaneously) reduces the vulnerability of the VPN (or in the case of Netlet) connection to Internet intrusion.

Though Portal Server does not prohibit nor shut down multiple network connections while attached to the portal site, it does prevent unauthorized users from “piggybacking” on other users’s sessions in the following ways:

Only an authenticated portal user can run the Netlet. No portal application can be run until the user has been successfully authenticated, and no new connections can be made if an authenticated session does not exist.

Netlet is an application specific VPN and not a general purpose IP router. Netlet only forwards packets that have been defined by a Netlet rule. This differs from the standard VPN approach that gives you complete LAN access once you’ve connected to the network.

All access controls in place on the application side are still in effect so that an attacker would also have to break in to the back-end application.

Every Netlet connection results in a dialog box posted by the Netlet (running in the authenticated user’s JVM™) to the authenticated user’s display. The dialog box asks for verification and acknowledgement to permit the new connection. In the current release, this can be a simple check box or can require the user to enter a password. For attackers to be able to utilize a Netlet connection, they would need to know that the Netlet was running, the port number it was listening on, how to break the back-end application, and convince the user to approve the connection.

Rewriter Proxy

When you install the Rewriter Proxy, HTTP requests are redirected to the Rewriter Proxy instead of directly to the destination host. The Rewriter Proxy in turn sends the request to the destination server.

Using the Rewriter Proxy enables secure HTTP traffic between the gateway and intranet computers and offers two advantages:

If there is a firewall between the gateway and server, the firewall needs to open only two ports—one between the gateway and the Rewriter Proxy, and another between the gateway and the Portal Server.

HTTP traffic is now secure between the gateway and the intranet even if the destination server only supports HTTP protocol (no HTTPS).

In case of intense traffic, the server that is running Sun ONE Portal Server software may become overloaded and the response time may be slow. To counter this, the Rewriter Proxy can be configured on a separate node.

Figure 3-8 and Figure 3-9 show typical deployments that include the Rewriter Proxy. In Figure 3-10, the Rewriter Proxy is installed on the same machine that is running Sun ONE™ Portal Server. In Figure 3-11, the Rewriter Proxy is installed on a separate node.



Note	You can run multiple Rewriter Proxies to avoid a single point of failure and achieve load balancing. When the Gateway is configured with multiple instances of the Rewriter Proxy, the Gateway automatically load balances across different Rewriter Proxies. The Gateway keeps a list of active Rewriter Proxies to avoid routing a user request to an inactive Rewriter Proxy. This mechanism also avoids the single point of failure in the system. Also the Gateway maintains user request stickiness to a particular Rewriter Proxy. This improves SSL performance and a fail over occurs only when a particular Rewriter Proxy instance goes down.

Netlet Proxy

Much like the Rewriter Proxy, Netlet Proxy also helps reduce the number of ports that you need to open in your firewall for connecting the Eproxy and the destination hosts.

For example, consider a configuration where users need Netlet to connect with a large number of Telnet, FTP, and Microsoft Exchange servers within the intranet. Assume that the Eproxy is in a DMZ. If Eproxy routes the traffic to all the destination servers, you would need to open a large number of ports in the second firewall. To alleviate this problem, you can use a Netlet Proxy behind the second firewall and configure Eproxy to forward the traffic to the Netlet Proxy. The Netlet Proxy then routes all the traffic to the destination servers in the intranet and you reduce the number of open ports required in the second firewall. You can also deploy multiple Netlet proxies behind the second firewall to avoid a single point of failure.

Figure 3-10 and Figure 3-11 show typical deployments that include the Netlet Proxy. In Figure 3-10, the Netlet Proxy is installed on the same machine that is running Sun ONE™ Portal Server. In Figure 3-11, the Netlet Proxy is installed on a separate node.

In both figures, the gateway ensures a secure tunnel between the remote client machine and the gateway. Netlet packets are decrypted at the gateway and sent to the destination servers. However, the gateway needs to access all the Netlet target hosts through the firewall between the demilitarized zone (DMZ) and the intranet. Conceptually, this requires opening a large number of ports in the firewall. However, the Netlet Proxy enhances security between the gateway and the intranet by extending the secure tunnel from the client, through the gateway to the Netlet Proxy that resides in the intranet. With the proxy, the Netlet packets are decrypted by the proxy and then sent to the destination server. This reduces the number of ports required to be opened in the firewall. Thus, in both figures, only one port is opened in the firewall for Netlet traffic. (Another port is opened for Portal Server traffic.)


Note	Installing the Netlet Proxy on a separate node can help with Portal Server response time by offloading Netlet traffic to a separate node.



Note	You can run multiple Netlet Proxies to avoid a single point of failure and achieve load balancing. When the Gateway is configured with multiple instances of the Netlet Proxy, the Gateway automatically load balances across different Netlet Proxies. The Gateway keeps a list of active Netlet Proxies to avoid routing a user request to an inactive Netlet Proxy. This mechanism also avoids the single point of failure in the system. Also the Gateway maintains user request stickiness to a particular Netlet Proxy. This improves SSL performance and a fail over occurs only when a particular Netlet Proxy instance goes down.

NetFile

NetFile enables remote access and operation of file systems that reside within the corporate intranet in a secure manner, when accessed through the gateway. NetFile includes NetFile Java 1, an AWT-based user interface, and NetFile Java 2, a Swing-based user interface.

NetFile uses standard protocols such as NFS, SMB, and FTP to connect to any of the UNIX® or Windows file systems that are permissible for the user to access. NetFile enables most file operations that are typical to file manager applications. See the Sun ONE Portal Server, Secure Remote Access 6.2 Administrator’s Guide for more information.

NetFile Components

NetFile Java 1 Applet—Has an AWT-based user interface. For use with older browsers that cannot support Java 2.

NetFile Java 2 Applet—Has a Swing-based user interface. For use with browsers that support Java plugins.

NetFile servlet(s)—There are two NetFile servlets present in the web container (of the server of your deployment), one for each kind of NetFile applet. The servlets are responsible for connecting to different types of file systems, carrying out the operations that NetFile is configured to handle, and sending the information back to the applets for display.

NetFile is internationalized and provides access to file systems irrespective of their locale (character encodings).

NetFile uses Identity Server to store its own profile, as well as user settings and preferences. You administer NetFile through the Identity Server administration console.

NetFile Initialization

When a user selects a NetFile link in the Portal Desktop, the NetFile servlet checks if the user has a valid Identity Server single sign-on (SSO) token (available only on successful authentication with the Identity Server), and permission to execute NetFile. If the user has a valid SSO token and permission to execute NetFile, the applet is rendered to the browser. The NetFile applet connects back to the servlet to get its own configuration such as size, locale, resource bundle, as well as user settings and preferences. NetFile obtains the locale information and other user information (such as user name, mail ID, and mail server) using the user’s SSO token. The user settings include any settings that the user has inherited from an organization or role, settings that are customized by the user, and settings that the user has stored upon exit from a previous NetFile session.

Server and Shares

NetFile uses the underlying Network File System (NFS) and File Transport Protocol (FTP) to access file systems on UNIX platforms, Server Message Block (SMB) protocol to access file systems on Windows, and FTP to access file systems on Novell platforms.

All three platforms provide share-based access to their file systems. A share is a directory tree that you can configure for access from remote systems. On some platforms, you can associate a password with the share. You can have multiple shares on a single server, each with a distinct name associated with it. Users can connect to these systems using a specified protocol, and gain access to files under these shares after validating their credentials.

Using NetFile, users enter the name of the server and share along with their credentials. NetFile stores the credentials and reuses them for authentication, if the user saves the NetFile settings. You can configure the shares (known as common hosts) that users can access at a organization or role level. Users do not need to enter their credentials to access these shares (but a valid SSO token from Identity Server is necessary at all times). You can also deny access to common hosts for a set of users by not inheriting this attribute from an organizational or role level.

If a particular share is part of the common hosts, and also part of the denied list, users are denied access to the share.

NetFile supports access to shares from UNIX (as long as there is NFS support), Windows, Windows 95, Windows 98, Windows 2000, Windows XP, X86 and FTP over NetWare servers.

Validating Credentials

NetFile uses the credentials supplied by users to authenticate users before granting access to the file systems.

The credentials include a user name, password, and Windows or Novell domain (wherever applicable). Because it is possible to have an independent password for each share, users need to enter their credentials for every share (except for common hosts) that you add.

NetFile uses UNIX Authentication of the Identity Server to grant access to NFS file systems. For file systems that are accessed over FTP and SMB protocols, NetFile uses the methods provided by the protocol itself to validate the credentials.

NetFile Access Control

NetFile provides various means of file system access control. You can deny access to users to a particular file system based on the protocol. For example, you can deny a particular user, role, or organization access to file systems that are accessible only over NFS.

You can configure NetFile to allow or deny access to file systems at any level, from organization, to suborganization, to user. You can also allow or deny access to specific servers. Access can be allowed or denied to file systems for users depending on the type of host, including Windows, FTP, NFS, and FTP over NetWare. For example, you can deny access for Windows hosts to all users of an organization. You can also specify a set of common hosts at an organization or role level, so that all users in that organization or role can access those hosts without having to add them for each and every member of the organization or role.

As part of the NetFile service, you can configure the Allow or Deny lists to allow or deny access to servers at the organization, role, or user level. The Deny list takes precedence over the Allow list. The Allow and Deny lists can contain the * wildcard to allow or deny access to a set of servers under a single domain or subdomain.

NetFile Security

When you use NetFile with SRA configured for SSL, all connections made from NetFile applets to the underlying file system happen over the SSL connection established between the gateway and the browser. Because you typically install the gateway in a DMZ, and open a limited number of ports (usually only one) in the second firewall, you do not compromise security while providing access to the file systems.

Special Operations

NetFile is much like a typical file manager application with a set of features that are appropriate for a remote file manager application. NetFile enables users to upload and download files between the local and remote file systems (shares). You can limit the size of the upload file (from the local to the remote file system) through the Identity Server administration console.

NetFile also enables users to select multiple files and compress them by using GZIP and ZIP compression. Users can select multiple files and send them in a single email as multiple attachments. NetFile also uses the SSO token of Identity Server to access the user’s email settings (such as IMAP server, user name, password, and reply-to address) for sending email.

Double-clicking a file in the NetFile window launches the application corresponding to the MIME type and opens the file. NetFile provides a default MIME types configuration file that has mappings for most popular file types (extensions) and MIME-types that you can edit for adding new mappings.

You can search for files and display the list in a separate window using NetFile. The results of each search are displayed in a new window while maintaining the previous search result windows. The type of character encoding to be used for a particular share is user configurable, and is part of the share’s setting. If no character encoding is specified, NetFile uses ISO-8859-1 while working with the shares. The ISO-8859-1 encoding is capable of handling most common languages. ISO-8859-1 encoding gives NetFile the capability to list files in any language and to transferring files in any language without damaging the file contents.

NetFile creates temporary files only when mailing files (in both NetFile Java 1 and Java 2). Temporary files are not created during uploading and downloading files between Windows file systems and the local file systems over the SMB protocol.These problems are removed by using Jcifs for accessing Windows hosts.

NetFile and Multithreading

NetFile uses multithreading to provide the flexibility of running multiple operations simultaneously. For example, users can launch a search operation, start uploading files, then send files by using email. NetFile will perform all three operations simultaneously and still permit the user to browse through the file listing.

Rewriter


Note	NetFile supports deletion of directories and remote files. All the contents of remote directories are deleted recursively.

The Rewriter is an independent component that translates all URLs (in both HTML and JavaScript code) to ensure that the intranet content is always fetched through the gateway. You define a ruleset (a collection of rules) that identifies all URLs that need to be rewritten in a page. The ruleset is an XML fragment that is written according to a Document Type Definition (DTD). Using the generic ruleset that ships with the Rewriter, you can rewrite most URLs (but not all) without any additional rules. You can also associate rulesets with domains for domain-based translations. See the Sun ONE Portal Server, Secure Remote Access 6.2 Administrator’s Guide for more information.

In a typical scenario, you install the gateway in a DMZ, with firewalls on either side (extranet and intranet). For the gateway to access machines on the intranet, you need to open extra ports in the firewall between the gateway and the intranet. T o minimize the number of open ports in the firewall, you use the Rewriter Proxy. You install the Rewriter Proxy within the intranet and you configure the gateway to use the Rewriter Proxy. Instead of trying to retrieve the contents directly, the gateway simply forwards all requests to the Rewriter Proxy, which fetches and returns the contents to the gateway.

SRA Authentication

SRA uses the authentication features of Identity Server to authenticate users. Even session validation happens through Identity Server’s single sign-on (SSO) API. In fact, the gateway component treats the login pages just like any other content page and passes them to the browser. For Personal Digital Certificate (PDC) authentication, the gateway obtains the client certificate and passes it to the Identity Server host for authentication.

If the session information is not found as part of the HTTP or HTTPS request, the gateway directly takes the user to the authentication page by obtaining the login URL from Identity Server. Similarly, if the gateway finds that the session is not valid as part of a request, it takes the user to the login URL and at successful login, takes the user to the requested destination.

After the user has successfully authenticated, the gateway simply presents (after rewriting) the page returned by Identity Server to the user. In Portal Server, by default, this is the Portal Desktop page.

SRA Configuration Files and Directory Structure

This section describes the SRA directory structure and configuration files used to store configuration and operational data.

SRA Directories

Table 3-2 shows the platform-specific directory structures that are installed for SRA.

Table 3-2 Portal Server, SRA Directories
Description	Location
Default installation directory	portal-server-install-root/
Default installation directory for Identity Server executables, the web server, and the deployed applications	portal-server-install-root/SUNWam
Default installation directory for configuration information	/etc/portal-server-install-root/SUNWps
Log files	/var/portal-server-install-root/SUNWam/logs
Debug log files	/var/portal-server-install-root/SUNWps/debug

SRA Configuration Files

All SRA configuration data is stored using the Identity Server Services Management function. Identity Server provides the bootstrap configuration file that is needed to find the directory server.

The platform.conf file contains the details that the Gateway needs. By default, the platform.conf file is located at: