|
| |
| Sun Java System Portal Server 6 2004Q2 Deployment Planning Guide | |
Chapter 2
Portal Server Secure Remote Access ArchitectureThis chapter describes the Sun Java™ System Portal Server Secure Remote Access (SRA) (formerly Sun ONE Portal Server, Secure Remote Access) architecture.
Sun Java System Secure Remote Access (SRA) uses Identity Server software to store all its configuration information. Information about the machines (such as host name, IP address), is stored on the host where the Gateway is installed.
You administer the configuration information stored in Sun Java System Identity Server through the Identity Server administration console. This chapter describes the following SRA components:
SRA GatewayThe 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 session validity and the header information to determine the type of request. Depending on the type of request, the Gateway performs the following:
- Netlet request—Routes the request (traffic) to the server specified in the Netlet rule that the user clicked in the Portal Desktop.
- HTTP(S) traffic—Routes the request to the server as specified by the HTTP header. Upon receiving a response from the server, the Gateway translates the response so that all intranet links within the response will work on the extranet.
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).
You can also run the Gateway in chroot environments. See the Portal Server Secure Remote Access 6 Administration Guide for more information.
Multiple Gateway Instances
If desired, you can run multiple Gateway instances on a single machine—this is referred as a multihomed Gateway. 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.
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 is stored as part of the gateway profile that the Gateway uses automatically while connecting to the proxy.
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 the 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 encryption while running in HTTPS mode. You can use the Identity Server administration console to enable or disable specific encryption. The Gateway also supports Transport Layer Security (TLS).
SSL v3 has two authentication modes:
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.
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 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. If Netlet Proxy is enabled, the Gateway checks for session validity and forwards it to Netlet Proxy. The Netlet Proxy then decrypts and forwards it to the application server.
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.
Gateway Access Control
The Gateway enforces access control by using Allowed URLs and Denied URLs 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 Allowed and Denied lists. Entries in the Denied URLs list take precedence over entries in the Allowed URLs 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
You can monitor the complete user behavior by enabling logging on the Gateway. The Gateway uses the Identity Server logging API for creating logs.
Using Accelerators with the Gateway
You can configure 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.
NetletNetlet can provide secure access to fixed port applications and some dynamic port applications that are available on the intranet from outside the intranet. The client can be behind a remote firewall and SSL proxy, or directly connected to the Internet. All the secure connections made from outside the intranet to the intranet applications through the Netlet are controlled by Netlet rules.
A Netlet applet running on the browser sets up an encrypted TCP/IP tunnel between the remote client machine and intranet applications on the remote hosts. 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.
Static and Dynamic Port Applications
Static port applications run on known or static ports where they can be contacted by clients. Examples include IMAPand POP servers, Telnet daemons, and jCIFS. For static port applications, the Netlet rule includes the destination server port so that requests can be routed directly to their destinations.
Dynamic applications agree upon a port for communication as part of the handshake. 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.
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.
Split Tunneling
Split tunneling allows a VPN client to connect to both secure sites and non-secure sites, without having to connect or disconnect the VPN—in this case, the 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:
- 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.
- 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.
- 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. 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.
Netlet ProxyA Netlet Proxy helps reduce the number of open ports needed in the firewall to connect the Gateway 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 Gateway is in a DMZ. If it routes the traffic to all the destination servers, a large number of ports would need to be open in the second firewall. To alleviate this problem, you can use a Netlet Proxy behind the second firewall and configure the Gateway 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.
You could also use a third-party proxy to use only one port in the second firewall.
Note
Installing the Netlet Proxy on a separate node can help with Portal Server response time by offloading Netlet traffic to a separate node.
NetFileNetFile enables remote access and operation of file systems that reside within the corporate intranet in a secure manner.
NetFile uses standard protocols such as NFS, jCIFS, 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 Portal Server Secure Remote Access 6 Administration Guide for more information.
Components
To provide access to various file systems, NetFile has three 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 plug-ins.
- NetFile servlet(s)—There are two NetFile servlets present in the web container, 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.
Initialization
When a user selects a NetFile link in the Portal Server Desktop, the NetFile servlet checks if the user has a valid SSO token and permission to execute NetFile. If so, 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.
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 from the Identity Server to grant access to NFS file systems. For file systems that are accessed over FTP and jCIFs protocols, NetFile uses the methods provided by the protocol itself to validate the credentials.
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 Allowed URLs or Denied URLs lists to allow or deny access to servers at the organization, role, or user level. The Denied URLs list takes precedence over the Allowed URLs. The Allowed URLs and Denied URLs lists can contain the * wildcard to allow or deny access to a set of servers under a single domain or subdomain.
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 jCIFS protocol.
Note
NetFile supports deletion of directories and remote files. All the contents of remote directories are deleted recursively.
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.
RewriterRewriter is an independent component that translates all URIs (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 Portal Server Secure Remote Access 6 Administration Guide for more information.
An external ruleset identifies the URI in the content. Any request that needs to be served by SRA follows this route:
- From the request, SRA identifies the URI of the intranet page or Internet page that needs to be served.
- SRA uses the proxy settings 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 where identified URIs are translated.
- 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.
Rewriter ProxyTo minimize the number of open ports in the firewall, use the 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.
- You can use a third-party proxy to use only one port in the second firewall to read the Rewriter Proxy.
- HTTP traffic is now secure between the Gateway and the intranet even if the destination server only supports HTTP protocol (no HTTPS).
Note
You can run multiple Rewriter Proxies to avoid a single point of failure and achieve load balancing.
ProxyletProxylet is a dynamic proxy server that runs on a client machine. Proxylet redirects a URL to the Gateway. It does this by reading and modifying the proxy settings of the browser on the client machine so that they point to the local proxy server or Proxylet.
It supports both HTTP and SSL, inheriting the transport mode from the Gateway. If the Gateway is configured to run on SSL, Proxylet establishes a secure channel between the client machine and the Gateway. Proxylet uses the JSSE API if the client JVM is 1.4 or higher or if the required jar files reside on the client machine. Otherwise it uses the KSSL API.
Proxylet is enabled from the Identity Server administration console where the client IP address and port are specified.
Unlike Rewriter, Proxylet is an out-of-the-box solution with very little or no post-installation changes. Integration with third-party software such as Microsoft Exchange Server is easy. Also there is an increase in the performance of the Gateway as Proxylet does not deal with web content.