Previous     Contents     Index     Next     
iPlanet Portal Server Administration Guide



Chapter 1   Introducing iPlanet Portal Server 3.0


iPlanetTM Portal Server 3.0 provides secure access to an intranet for remote users on UNIX-based or Windows-based personal computers.The iPlanet Portal Server software offers a customized palette of applications and information including:

  • HTTP

  • X-Windows

  • Microsoft NT

  • 3270/5250 terminal emulation

  • heterogeneous file systems, plus

  • External content from providers of your choice.


    Note The tasks and concepts in this Administration Guide assume that the default installation of iPlanet Portal Server has been completed. If installation is needed, refer to the iPlanet Portal Server Installation Guide.


This chapter introduces iPlanet Portal Server and covers the following topics:

  • What is a Portal

  • Features of iPlanet Portal Server

  • Administering iPlanet Portal Server

  • Using the iPlanet Portal Server from a Remote Client

  • iPlanet Portal Server Architecture

  • Structure of your iPlanet Portal Server installation

  • Where to go for information about iPlanet Portal Server

  • Tasks of the iPlanet Portal Server administrator



What is a Portal?

A portal is a community-based web site that securely holds a collection of data related to different topics, including such things as news and stock quotes, applications, and services.The iPlanet Portal services reflect the same concept as a portal.

The available data content may be customized by the user that has write permission to change providers, display of data, and links to other allowable web sites from those available. Services can include the use of provider applications and utilities; for example email and file management and storage facilities.

A corporate portal is a personalized web page that brings together data and productivity tools relevant to corporate users. Corporate users can include employees, vendors, marketing partners, customers, and allied business users. From a corporate portal, customers can purchase a product in a secure e-business transacting environment. Likewise, vendors can provide product to the corporation.



Features of the iPlanet Portal Server


The iPlanet Portal Server system includes the following features:

  • Cost-effective, efficient and secure access to internal corporate information, personal email, productivity applications, and internal web sites.

  • Leverage to the Internet and Internet service providers (ISPs) to reduce costs.

  • Simplification of remote access for end users.

  • Selective authentication scheme from one of six included modules

  • Customization of authentication via pluggable modules.

  • Independent software interfaces for users and administrators.

  • Local or remote administration through a web-based console from either Internet Explorer or Netscape browsers.

  • Controlled user access to corporate resources at any level of granularity.

  • Customizable desktop widgets

  • APIs to facilitate new iPlanet Portal Server applications



Administering iPlanet Portal Server

iPlanet Portal Server includes two administration interfaces; the administrator console and the command line interface. 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.

iPlanet Portal Server supports two types of system administrators, the Super Administrator and the Domain Administrator. The Super Administrator has permission to administer all aspects of the iPlanet Portal Server installation, including creating a delegated administrator known as a Domain Administrator. The Domain Administrator can only administer aspects of iPlanet Portal Server that apply to their assigned domain.


Getting Information for Administering iPlanet Portal Server

This guide contains conceptual information and describes tasks to help both the Super Administrator and the Domain Administrator configure and manage the iPlanet Portal Server. In addition, online help is available for the Administration Console by clicking the Help links on the web pages.

.


Note For instructions for administering the iPlanet Portal Server from the command line or, for creating custom applications and scripts, please refer to the iPlanet Portal Server Programmer's Reference Guide.


The installation CD-ROM for the iPlanet Portal Server software contains a documentation directory with complete documentation in HTML and PDF formats: /docs/en_US.

After installation, look for the documentation at:

http://[servername]:8080/docs/en_US/.

This documentation URL contains other links to hard copy format (PDF) and HTML format copies of the complete documentation set, as well as links to both the administrator and end user online help.



Using the iPlanet Portal Server Desktop From a Remote Client


Users access iPlanet Portal Server by logging in to the web-based iPlanet Portal Server Desktop through their assigned authentication scheme. The log in request is authenticated by the configured authentication module. Upon successful authentication, the user session is established with the iPlanet Portal Server and the assigned desktop portal page is displayed. The desktop includes a Help button that can be accessed for online help.



Where to Go Next


The remainder of this chapter provides the information needed to administer the iPlanet Portal Server.



iPlanet Portal Server Components

The iPlanet Portal Server architecture is Internet and web-based. The native communication protocols include HTTP and HTTPS. Additional applications running through iPlanet Portal Server, in particular remote windowing software and specific communication components (such as site certificate helpers), use their native TCP-based, encrypted communication protocols and pass them through the configured SSL port.

By relying on these protocols, iPlanet Portal Server supports standard web browsers for both secure end-user access to applications and secure iPlanet Portal Server administration. All remote-user traffic uses the SSL port, while administrative access uses HTTP or HTTPS, depending on the choices made during iPlanet Portal Server installation.

The iPlanet Portal Server configuration includes four major components:

  • iPlanet Portal Server

  • iPlanet Profile Server

  • iPlanet Portal Server Gateway

  • Firewall

These components can be installed on individual computers, or, if necessary, on one computer. The portal server structure utilized with the installed iPlanet Portal Server components includes the use of a role tree. Collectively, the installed iPlanet Portal Server components and structure are referred to as the iPlanet Portal Server platform.


Introducing the Server

The iPlanet Portal Server has two main functions: as a portal server and as an application server. As a portal server, iPlanet Portal Server handles all authorization, policy, and user profile access and management throughout the platform. As an application server, iPlanet Portal Server enables the included mail and file management utilities.


Introducing the Profile Server

Within the portal server function, iPlanet Portal Server includes a profile-management system called the profile server. The profile server stores the profiles associated with iPlanet Portal Server objects such as domains, roles, and users. In a basic iPlanet Portal Server configuration, the profile server is installed on the same machine as the iPlanet Portal Server server. In a multi-server platform, only one iPlanet Portal Server server is designated as profile server.


Introducing the Gateway

The iPlanet Portal Server gateway provides the interface and security barrier between the remote user sessions originating from the Internet and your corporate intranet. The iPlanet Portal Server gateway has two main functions:

  1. Providing basic authentication services to incoming user sessions, including establishing identity and allowing or denying access to the portal server.

  2. Providing mapping and rewriting services to allow users access to web-based links containing intranet content.


Choosing a Firewall

Although not required for operation of the iPlanet Portal Server, a firewall provides greater security. When utilized, the iPlanet Portal Server firewall application can be run as part of the iPlanet Portal Server software. Alternatively, the iPlanet Sunscreen 3.1 firewall product can be used, or, a third-party firewall application.

For sample configurations showing the use of a firewall with iPlanet Portal Server, refer to To Configure the iPlanet Portal Server Firewall Application. To Configure the iPlanet Portal Server Firewall ApplicationTo Configure the iPlanet Portal Server Firewall ApplicationFor more information about the iPlanet Portal Server firewall, refer to Appendix A "Administering the Firewall Application.


Basic iPlanet Portal Server Installation



Figure 1-1    Basic iPlanet Portal Server Installation

Figure 1-1 shows the basic iPlanet Portal Server platform, as introduced in the iPlanet Portal Server 3.0 Installation Guide. Here, iPlanet Portal Server is installed on two computers, one functioning as the iPlanet Portal Server gateway and firewall, and one functioning as the Portal Server including the profile server.



Figure 1-2    Typical Two-Machine Configuration with SSL Ports Noted

Figure 1-2 shows the basic configuration with the default port numbers. SSL is used to encrypt the connection between the client and the iPlanet Portal Server gateway over the Internet. SSL can also be used to encrypt the connection between the iPlanet gateway and server

Additional servers and gateways can be added for site expansion. Or, the gateway and server can be configured on the same computer. For more information on configuring SSL encryption, see Chapter 11 "Maintaining iPlanet Portal Server.



Structure of the iPlanet Portal Server Role Tree


A major part of implementing the iPlanet Portal Server platform involves organizing users and applications into a hierarchy called the role tree. Through the role tree structure, an administrator can be designated to manage gateways and servers, control access to the site's intranet, design the portal page, and determine the look and feel of users' desktops.

The iPlanet Portal Server role tree has four levels:

  • Root

  • Domain

  • Role

  • User


Root Level

The root level is the top of the role tree for the iPlanet Portal Server platform. It is where all global attributes of the platform are defined. The root level is the parent of all configured domain levels for the platform. The root level is administered only by the Super Administrator, who has read and write privileges for all attributes throughout the platform. Platform level attributes are unique and apply globally; they are not passed down to the domains.

iPlanet Portal Server supports two types of attributes: global and user-configurable. Global attributes apply to the entire platform and are configured only by the Super Administrator. Examples of global attributes include values assigned to gateways and servers.


Domain Role-User Attributes

User-configurable attributes apply to underlying levels of the role tree, as described in the following sections. A delegated Domain Administrator can configure these attributes for the domain, parent role, child role, and user levels. At the user level of the role tree, some attributes can be customized for each user, as needed.


Inheritance in the Role Tree

The role tree has the notion of parent and child levels, much in the same way as the UNIX file system. For example, a User is the child of a Role. The Role, though parent of the User, is a child of the Domain. A role can also be a child of a parent. A domain can not have a child domain, nor can a user have a child user. Depending on how the role tree is set up, child levels can inherit attributes defined at their parent level.

The goal of role tree design results in a structure that is easy to administer, using inheritance. Subordinate levels of the role tree can have policies and attributes that are more restrictive, more permissive, or both, depending on the circumstances. However, because policies and attributes must be tracked, a simple structure is easier to maintain.


Domain Level

In iPlanet Portal Server, a Domain is used to administer large amounts of resources and users for the corporate intranet. In a small organization, one domain may be sufficient to represent the entire company. However, a large company with many divisions may best be served to have multiple domains; perhaps one domain for each represented division.

To further illustrate the domain concept, consider an enterprise site where all users are part of the same company. Within one domain, multiple roles are created representing the various departments or categories of users. However, when considering an application service provider (ASP) or Internet service provider (ISP) that serves a number of client corporations, each client member would have its own domain and role tree structure completely independent and secured from each other.


Note Do not confuse the iPlanet Portal Server concept of a "domain" with a DNS, NIS, or NIS+ domain. If an iPlanet Portal Server platform has only one domain, the users in the iPlanet Portal Server domain might correspond exactly to the members of the company's DNS domain. But this direct correspondence of members has nothing to do with how iPlanet Portal Server (or DNS) functions or is administered.



Inheritance at the Domain Level

Domains are the children of the Root Level and parents of roles in the platform role tree. Additionally, either the Super Administrator or the designated Domain Administrator can define user-level attributes that apply to a particular domain. These domain-specific attributes are inherited by roles but cannot be passed upward to the root level. Therefore, for a platform with multiple domains, a unique set of attributes can be defined for each domain.

When attributes are initially defined at the domain level, they are inherited by the subordinate child role and user levels. Changes to attributes at the domain level can be propagated down to subordinate child levels using the `Apply Changes to all Subroles' attribute. Keep in mind that under such propagating circumstances, any customized role or user-defined attribute will be overwritten by the same attribute changed at the domain level, necessitating a reconfiguration of the customized role or user level attribute.

Figure 1-3 shows the top of a role tree with two domains, Example 1 and
Example 2.



Figure 1-3    Role Tree With Two Domains

In this scenario, Example 2 roles inherit attribute values from the Example 2 domain. In addition, Example 1 and Example 2 have domain level attributes defined, which are specific to each domain and not known or used by each other.


Role Level

A role defines a group of users who are members of that role. The role contains a set of attributes and policies that define a user's desktop policy. This set of attributes and policies are inherited by child roles and users. Customization of a particular attribute or policy can still occur at the child role or user level.

When iPlanet Portal Server is installed, the roles AdminRole and defaultRole are created in the selected default domain name. The default role name for the domain can be changed. The AdminRole is a special case and can not be deleted as this role is used for Super Administrator privileges. Also, any role can have child roles that can inherit attributes from the parent role when changes are applied to child roles from that parent role profile. Additionally, each child role can contain customized attributes unique to that child role and unknown to other parent and child roles in the domain.

When users attempt to log in to the iPlanet Portal Server desktop for the first time, they must be authenticated by the iPlanet Portal Server gateway. If authentication is successful, the user's desktop session assumes the characteristics of the assigned user profile. New authenticated users not assigned to a particular role are added to the defaultRole for the domain.


Inheritance at the Role Level

Figure 1-4 shows a role tree that might be set up for multiple domains, roles, and child roles.The Default Domain is the name of the domain specified during installation.



Figure 1-4    Role Tree With Parent Roles and Child Roles

The domain Example 1 has the parent roles AdminRole and DefaultRole, which in turn have the child roles Mgrs and Individuals, respectively. In this scenario;

  • AdminRole inherits all domain-level attributes and policies.

  • DefaultRole inherits all domain-level attributes and policies, but has no knowledge of, and cannot use, attributes and policies assigned to the Admin role.

  • Mgrs role inherits the attributes from DefaultRole but might also have special policies or applications available only to members of this child role.

  • Individual child role inherits the attributes from DefaultAll role and may have permission to run applications not available to the Mgrs role. Moreover, the Individuals child role has no knowledge of, and cannot use, special privileges or special applications delegated to those in the Mgrs child role.

The domain Example 2 has the roles Admin, Eng, and Acct, with no child roles assigned. Attributes can be customized at any role level if inheritance is not needed.


User Level

The User level consists of individuals permitted to use iPlanet Portal Server. Each user has a unique set of attributes inherited from higher levels of the role tree, plus unique attributes that determine how the user will run theiPlanet Portal Server desktop.

In a default installation, a user can log in, and, if the user has not been pre-assigned to a role, the user automatically becomes a member of the default Role for the domain. Each iPlanet Portal Server user can belong to only one role. Administrators are a special case, and belong to one role with special administrative privileges.


Inheritance at the User Level

Figure 1-5 shows a full role tree that might be set up for an ISP.



Figure 1-5    Role Tree for an ISP Hosting Domains Example1 and Example2

In the Example 1 domain, both Individuals and Mgrs inherit the policies and attributes of the DefaultAll role, but do not inherit the policies and attributes of the Admin role. Likewise, the Writers role, a child of the Individuals role, inherits the policies and attributes of the Individuals role, but does not inherit the policies and attributes of the Mgrs child role. Moreover, while users in the Writers and QA child roles inherit policies and attributes from Individuals, unique attributes can be defined for each child role that do not apply to the other child role.

In the Example 2 domain, due to role inheritance, all users in the Eng tree can only see certain information and access certain tools that only they need to see. Conversely, all users in the Acct tree might be able to access other tools but not necessarily development tools.


Note Users can be created as a child of any role (i.e., a parent role, a child role of a parent role)


When a role tree is established, privileges, attributes, and applications can be set to allow or deny access to such resources further down the role tree. For instance, the root user at the top of a role tree can be assumed to have blanket policies and attributes. Conversely, role members and users can have subsets of the root user policies and attributes, or, can override policy restrictions and have different characteristics entirely.

Figure 1-6 illustrates the way the value of an attribute can be inherited or changed at each level. For instance, at the Role 5 level, when `white' is overridden to `red' this attribute is denoted as customized. Similarly, when user 2 inherits `white' from Role 2, this attribute is inherited.



Figure 1-6    How Attributes Are Inherited in the Role Tree



Introducing the Administration Console


This section describes the overall structure of the iPlanet Portal Server Administration Console and explains how to use it.


Logging in to the Administration Console

  1. Do the following based on the type of administrator that you are:

For the Super Administrator:

  • Go to your preferred browser and type the URL:

    http://iPS_server:8080/console

    where iPS_server is the server name given to the iPlanet Portal Server at installation.

For a Domain Administrator:

  • Go to your preferred browser and type the URL:

    http://iPS_server:8080/console/domain_name

    where iPS_server is the server name of the iPlanet Portal Server and domain_name is the name of your assigned domain.

If your server is configured to use SSL:

  • Use the following URL to access the Administration Console (the port number is that defined for SSL at the time of installation (e.g., such as port 443):

    https://iPS_server:port/console/domain_name

The login screen appears as shown in Figure 1-7.


Note UNIX authentication is the only authentication method for iPlanet Portal Server Administration Console. Therefore, there are only two ways to access and configure the iPlanet Portal Server platform: as a superuser or as the non-root user entered as the Super Administrator at the time of installation.




Figure 1-7    Administration Console Login Screen (UNIX Authentication)


How the Administration Console is Organized

The home page of the web-based Administration Console consists of two components, as shown in Figure 1-8. The Task frame is on the left, and the Content Frame is on the right.



Figure 1-8    iPlanet Portal Server Administration Console Main Screen


Main Screen Task Frame

The task frame groups individual tasks that can be performed from the Administration Console. The tasks displayed vary depending upon how you are logged in to the system. For the Super Administrator, all tasks are displayed. For the Domain Administrator, platform-level and portal server specific tasks are not displayed.

The task frame contains five task groups, each of which has one or more activity links. Each task group is described below.


Session Management
This task group contains links to content pages that show the status of the user sessions the site's iPlanet Portal Server platform. If you are a Super Administrator, this section can show all valid sessions for your site. If you are a Domain Administrator, the valid sessions can be viewed for users in your domain.

The session management settings are controlled through attributes and privileges using the Role>Policy>Sessions links to display the Sessions page.

You can terminate an individual user session using the links available in this section.


Portal Server Services
This task group contains links to content pages that enable you to configure and manage gateways and servers in your platform. It also shows the status of the server and gateway. Portal Server Services also contains a link to the logging management screens wherein log profiles for the gateway, authentication, and other system services can be viewed and managed.

You must be Super Administrator to configure the attributes on the content pages accessed through the links in this section. The Super Administrator can allow the Domain Administrator to view the server related logs but not the gateway logs.


Portal Server Platform (Super Administrator Only)
This task group contains links to content pages that can be set up across the platform as global attributes for your installation. The link to set attributes here is Manage Platform Settings.

You will not see this section in the Administration menu if you are a Domain Administrator.


Roles and Users
This section contain links to content pages where you manage the attributes and policies for the domains, roles, and users in your iPlanet Portal Server platform. If you are Super Administrator, the profiles and policies of all domains can be accessed through the iPlanet Portal Server platform. Moreover, following the links in this section, Domain Administrators can be created to configure and manage their own domain.

The Domain Administrator can only access the domain, roles, and users profiles assigned to their domain.


Miscellaneous Section
This task group contains a link to the online help for administrators and a link to log out of the Administration Console.


Content Frame

The Content frame displays the information related to the activity selected in the task frame. The content pages might include:

  • Lists of servers and gateways in a platform

  • Session statistics for the server and gateways

  • Domains in an iPlanet Portal Server platform

  • Profiles of domains, roles, and users in an iPlanet Portal Server platform

  • Policy pages for the domains, roles, and users of the iPlanet Portal Server

The path designation at the top of the Content frame indicates where you are in the iPlanet Portal Server role tree. This becomes important when configuring attributes at a parent level (i.e, the domain) that will be inherited by its children (roles, child roles, and users if any).


Moving Through the Administration Console Content Pages


Navigating Through the Administration Console

The iPlanet Portal Server role tree is multi-layered. However, to create a user profile within a domain, select the domain of interest from the Manage Domains link to call up that domain. The domain page indicates the role link. Selecting the role link calls up the role page. The Add User link is displayed at the top of this page. This link is selected to create a user profile. The created user profile can then by accessed from the User link that is displayed at the bottom of the role page. An existing user profile can be accessed quickly using the Search link on the domain page.


Screen Shortcuts

  • All content pages showing profiles or policies have the Back To Top link that quickly moves you to the top of the page.

  • Policy pages are lengthy. Therefore, the policy page begins with an index of links, any of which can be used to jump to a particular section.

  • To go back to a previous content page, use the Back to Overview button. Alternatively, the Back button of the browser will display the previously viewed page.


Using the Search Link

The Search link can be used to search for roles and/or users. When this link is clicked, the Search for Roles and/or Users window is displayed, as shown in Role and/or User Search Window.



Figure 1-9    Role and/or User Search Window


Note The search function works from the current level of the role tree and down; in other words, when doing a search from a child level, the parent level will not be searched.




Interacting With The Administration Console



Modifying Information in the Contents Frame

An attribute setting or policy can be changed only when write permission is enabled. A Domain Administrator can view and change information related to the assigned domain. A Super Administrator can view and change information throughout the iPlanet Portal Server platform.


Read/Write Permissions
When logged in as a Domain Administrator, pages with profile or policy attributes have a show and a hide permissions button at the top of the screen, as shown in Figure 1-10. When permissions are shown, the read/write permissions attributes are displayed to the right of each attribute on the page.



Figure 1-10    Permissions Buttons


Note The Super Administrator will see permissions differently as: Admin: Read/Write on one line and User: Read/Write on a second line.


The Super Administrator has read and write permission for any attribute in the platform. As a Domain Administrator, the permissions viewed are those granted by the Super Administrator.

Hiding the read/write permissions reduces the amount of information displayed in the Contents frame. However, a Domain Administrator might want to show role and user permissions to review attribute settings for those profiles.


Processing Changes to the Profile Server

There are three buttons located at the bottom of profile and policy pages:

  • Submit

  • Reset

  • Cancel

There is also a check box with a text label indicated as `Apply changes to all subRoles.'


Submit
The Submit button processes the changes made on the page to the profile server.


Reset
The Reset button restores the values of the attributes to those found when the page was initially displayed.


Cancel
The Cancel button aborts any changes made on the page and returns the previously displayed page.


Apply Changes to All SubRoles



Figure 1-11    Graphical View of Initial Role Tree

To apply changed attributes at one particular level to lower levels of the role tree, click the "Apply changes to all subRoles" check box, and then click the Submit button. Clicking this check box causes all changed attributes to propagate down through child role levels. If the new attributes apply only to this level of the role tree, do not check "Apply changes to all subRoles."

Graphical View of Initial Role Tree graphically represents a role tree with customized attributes for Role 1 and user 3. If an attribute is changed in Domain 1 that has the same attribute with customized settings in Role 1, clicking the "Apply changes to all subRoles" box will overwrite the customized attribute in Role 1. To reinstate the customized attribute, Role 1 would be accessed to make the change directly and submit it to the Profile Server.

Further, if an attribute is changed in Domain 1 and the "Apply changes to all subRoles" box is not clicked, the corresponding customized attribute in Role 1 and user 3 is not changed but the Domain 1 attribute change is propagated through the roles Role 2, user 2, user 1, and user 4, by inheritance.


Caution

Use care when specifying Apply changes to all subRoles since any customized attributes at lower levels of the role tree will be removed.



Managing Customized Attributes

When an attribute for a given domain, parent or child role is changed, its state in the Profile Server is marked as customized. This customized notation appears to the right of the attribute in a pull down window that also includes the Make Inherited option. If the make inherited option is desired for a customized attribute, in effect, you are saying that this attribute at this level of the role tree should be returned to its default or inherited value from its parent role (e.g. a role would inherit the domain value setting for the attribute).

When using the Make Inherited state to change an attribute back to its inherited value and also checking the Apply changes to all Subroles, any customized attribute setting in child role levels will be removed.


Note Any attribute defined with a numeric datatype cannot be left blank. Also, customized attributes must be set at each level of the role tree for which they are intended. There is no way to propagate a customized value from a parent role to a child role.



Previous     Contents     Index     Next     
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated May 04, 2000