Sun ONE logo     Previous     Contents     Index     Next     
Sun One Portal Server, Secure Remote Access 6.0 Administration Guide



Chapter 1   Introduction to Sun ONE Portal Server, Secure Remote Access


This chapter describes the Sun ONE Portal Server, Secure Remote Access product, the relationship between Sun ONE Portal Server and Secure Remote Access, the components that constitute the Secure Remote Access, and provides information on administering and configuring Secure Remote Access.

This chapter has the following sections:


Secure Remote Access

The Sun ONE™ Portal Server, Secure Remote Access enables remote users to securely access their organization's network and its services over the Internet. Additionally, it gives your organization a secure Internet portal, providing access to content, applications, and data to any targeted audience—employees, business partners, or the general public.

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

The Sun ONE Portal Server, Secure Remote Access is targeted towards enterprises deploying highly secure remote access portals. These portals emphasize security, protection, and privacy of intranet resources. The Secure Remote Access architecture is well suited to these types of portals. The Gateway, NetFile, and Netlet features of the Secure Remote Access 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. All other non-Secure Remote Access 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.

The Netlet and NetFile applets are downloaded to the client machine, while the support files may reside either on the gateway or on the Sun ONE Portal Server server.

Relation Between Sun ONE Portal Server and Secure Remote Access

Sun ONE Portal Server can function in two modes - open and secure.

Open Mode

In open mode, the Sun ONE Portal Server is installed without the Secure Remote Access. Although HTTPS communication is possible in this mode, 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. A DMZ is a small protected network between the public Internet and a private intranet, usually demarcated with firewalls on both ends.

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 1-1 shows the Sun ONE Portal Server in the open mode. Here, the Sun ONE Portal Server is installed on a single server behind the firewall. Multiple clients access the Portal Server across the internet through the single firewall.

Figure 1-1    Sun ONE Portal Server in the Open Mode


This figure illustrates the Sun ONE Portal Server in the Open mode. See the description preceeding the figure for details.

Secure Mode

The secure mode provides users with secure remote access to required intranet file systems and applications.

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 Portal Server 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 HTTP over Secure Sockets Layer (SSL). Communication from the gateway to the server and intranet resources can be either HTTP or HTTPS.

Figure 1-2 shows the Sun ONE Portal Server with the Secure Remote Access. SSL is used to encrypt the connection between the client and the Sun ONE Portal Server gateway over the Internet. SSL can also be used to encrypt the connection between the gateway and the server. The presence of a gateway between the intranet and the internet extends the secure path between the client and the Portal Server.

Figure 1-2    Sun ONE Portal Server in the Secure Mode (with Secure Remote Access)


This figure illustrates the Sun ONE Portal Server in the Secure mode, that is, with Secure Remote Access installed. See the description preceeding the figure for details.

Additional servers and gateways can be added for site expansion. The components of the Secure Remote Access can be configured in various ways based on the business requirement.


Administering the Sun ONE Portal Server, Secure Remote Access

Secure Remote Access has two interfaces for administration:

  • iPlanet Directory Server Access Management Edition Administration console

  • Command-Line Utilities

Most administration tasks are performed through the web-based administration console. The administration console can be accessed locally or remotely from a web browser. However, tasks such as file modification must be administered through the UNIX command-line interface.


Components of the Secure Remote Access

Secure Remote Access has four major components:

Gateway

The Secure Remote Access gateway provides the interface and security barrier between remote user sessions originating from the Internet, and your corporate intranet. The gateway presents content securely from internal web servers and application servers through a single interface to a remote user.

See Chapter 2 "Administering the Gateway for details.

Netlet

Netlet facilitates the running of popular or company-specific applications on remote desktops in a secure manner. After you implement the Netlet at your site, users can securely run common TCP/IP services, such as Telnet and SMTP, and HTTP-based applications such as pcANYWHERE or Lotus Notes.

See Chapter 3 "Configuring the Netlet for details.

NetFile

NetFile is a file manager application that allows remote access and operation of file systems and directories. NetFile comprises NetFile Java™, a Java-based user interface. This is available for Java 1 and Java 2.

See Chapter 4 "Configuring NetFile for details.

Rewriter

The Rewriter enables end users to browse the intranet, and also makes links and other URL references on those pages operate correctly. The rewriter prepends the gateway URL in the location field of the web browser, thereby redirecting content requests through the gateway.

See Chapter 5 "Configuring the Rewriter for details.


Configuring the Secure Remote Access

You can configure attributes related to the Secure Remote Access at various levels. See the iPlanet Directory Server Access Management Edition Administrator's Guide for details.

The components of the Secure Remote Access are made available through four services:

  • Access List

    This service allows you to allow or restrict access to specific URLs, and also manage the single sign-on feature. See Configuring URL Access Control and Managing Single Sign-On for more information.

  • Gateway

    This service allows you to configure all gateway related attributes such as proxy management, cookie management, logging, rewriter management, and ciphers. See Chapter 2 "Administering the Gateway for more information.

  • NetFile

    This service allows you to configure all NetFile related attributes such as common hosts, MIME-types, and access to different types of hosts. See Chapter 4 "Configuring NetFile for more information.

  • Netlet

    This service allows you to configure all Netlet related attributes such as Netlet rules, access to required rules, organizations and hosts, and the default algorithm. See Chapter 3 "Configuring the Netlet for more information.



    Caution

    The gateway does not receive any notifications for attribute changes that are made while the gateway is running.

    Restart the gateway to ensure that updated profile attributes (belonging to the gateway or any other service) are used by the gateway. See Restarting the Gateway in Chapter 2 "Administering the Gateway.




Configuring URL Access Control

As a Secure Remote Access administrator, you can allow or deny access to the end user through the gateway for specific URLs.



Note When you install the Secure Remote Access, the Access List service is not available to all users by default. This service is enabled only to the amadmin user that is created by default during installation. Other users will not be able to access the desktop through the gateway without this service. Log in as amadmin, and assign this service to all the users.



Setting up a URL Deny List

You can specify the list of URLs that end users cannot access through the gateway using this field.

The gateway checks the URL Deny List before checking the URL Allow List.

You can configure this attribute at the organization, role and user levels.

To Set up the URL Deny List

  1. Log in to the iPlanet Directory Server Access Management Edition admin console as administrator.

  2. Select the Service Management view.

  3. Click the arrow next to Access List under SRAP Configuration.

    The Access List page appears.

  4. Specify the URL for which you want to deny access through the gateway in the URL Deny List field, and click Add. The format for entering the URL is:

    http://abc.siroe.com

    The URL is added to the URL Deny List.

    You can also use regular expressions such as http://*.siroe.com. In this case, users are denied access to all hosts in the siroe.com domain.

  5. Click Save to record the changes.

Setting up a URL Allow List

You can specify all the URLs that can be accessed by the end user through the gateway. By default, this list has a wild card entry (*), which means that all URLs can be accessed. If you want to allow access to all URLs, and restrict access only to specific URLs, add the restricted URLs to the URL Deny List. In the same way, if you want to allow access only to specific URLs, leave the URL Deny List blank, and specify the required URLs in the URL Allow List.

The gateway checks the URL Deny List before checking the URL Allow List.

You can configure this attribute at the organization, role and user levels.

To Set up the URL Allow List

  1. Log in to the iPlanet Directory Server Access Management Edition admin console as administrator.

  2. Select the Service Management view.

  3. Click the arrow next to Access List under SRAP Configuration.

    The Access List page appears.

  4. Specify the URL for which you want to allow access through the gateway in the URL Allow List field, and click Add. The format for entering the URL is:

    http://abc.siroe.com

    The URL is added to the URL Allow List.



    Note The URL Allow List has a * by default which means that all URLs can be accessed through the gateway.



  5. Click Save to record the changes.


Managing Single Sign-On

The Access List service in the Secure Remote Access allows you to control the single sign-on feature for various hosts. But for the single sign-on feature to be available, the Enable HTTP Basic Authentication option in the gateway admin console should be enabled. See Enabling HTTP Basic Authentication in Chapter 2 "Administering the Gateway.

With the Access List service, you can disable single sign-on for certain hosts. This means that an end user needs to authenticate each time to connect to the hosts that require HTTP basic authentication, unless you enable single sign-on per session.

If you have disabled single sign-on for a certain host, the user can reconnect to that host within a single Portal Server session. For example, assume that you have disabled single sign-on to abc.sesta.com. The first time the user connects to this site, authentication is required. The user may browse other pages and return to this page later, and if the page is in the same Portal Server session, authentication is not required.

You can configure these attributes at the organization, role and user levels. A user can also configure these attributes using the limited admin console.

To Disable SSO for Hosts

  1. Log in to the iPlanet Directory Server Access Management Edition admin console as administrator.

  2. Select the Service Management view.

  3. Click the arrow next to Access List under SRAP Configuration.

    The Access List page appears.

  4. Specify the hosts for which you want to disable SSO in the Hosts for which SSO is disabled field, and click Add.

    Specify the host name in the format abc.siroe.com.

    The hostname is added to the list.

  5. Click Save to record the changes.

To Enable SSO per Session

  1. Log in to the iPlanet Directory Server Access Management Edition admin console as administrator.

  2. Select the Service Management view.

  3. Click the arrow next to Access List under SRAP Configuration.

    The Access List page appears.

  4. Select the Enable SSO per session check box.

  5. Click Save to record the changes.


Customizing the Access List Interface

Edit the access list properties file to change the labels on the access list user interface in the iPlanet Directory Server Access Management Edition admin console. Edit the file:

InstallDir/SUNWam/locale/srapGatewayAccess.properties

The following sample shows the lines that can be customized:


d02=URL Allow List
d05=Policy to Enable/Disable SSO
d04=Enable SSO per Session
d03=Hosts for Which SSO is Disabled
d01= URL Deny List

You can change the label text, but not the number associated with the text.


Previous     Contents     Index     Next     
Copyright 2002 Sun Microsystems, Inc. All rights reserved.

Last Updated September 26, 2002