iPlanet Portal Server Service Pack 2 |
Release Notes for iPlanet Portal Server 3.0
Updated February 12, 2001
These release notes contain important information available at the time of the release of iPlanet Portal Server 3.0TM Service Pack 2. Installing this product will update the iPlanet Portal Server 3.0 software to include both Service Pack 1 and Service Pack 2. New features and enhancements, installation notes, known problems, and other late-breaking issues are addressed here. Read this document before you begin using iPlanet Portal Server 3.0 with Service Pack 2.An electronic version of these release notes can be found at the iPlanet documentation web site: http://docs.iplanet.com/docs/manuals/. Check the web site prior to installing and setting up the software and then periodically thereafter to view the most up-to-date release notes and manuals.
These release notes contain the following sections:
Understanding the Typographic Conventions
What's New in iPlanet Portal Server 3.0, Service Pack 1 and Service Pack 2
Software and Hardware Requirements
Service Pack 2 Installation Notes
Understanding the Typographic Conventions
The following tables describes the typographic conventions used in this release note.
Shell Prompts in Command Line Interface Examples
The following table shows the default system prompt and superuser prompt for the C shell, Bourne shell, and Korn shell.
What's New in iPlanet Portal Server 3.0, Service Pack 1 and Service Pack 2
The following product enhancements to iPlanet Portal Server 3.0 are included in the Service Pack 2 software release:
Open Portal Mode
Configuring Multiple Instances of iPlanet Portal Server
Installing and Enabling Multiple Locale for a Domain
Supporting SSL for Authentication in an Open Portal
Redirecting the User Using the goto Parameter
Getting and Setting User Properties
Using E-mail Address As User's Profile ID
Changing Membership Login Password
Reloading Templates with No Restart
URL Scraping with No Gateway Installed
Configuring Restart of the HTTP Proxy
Open Portal Mode
If the portal does not contain sensitive information (deploying public information and allowing access to free applications), then by using the Open Portal mode (without a gateway), the portal server can respond faster to access requests by a large number of users than if a gateway is installed (Secure Portal mode).The gateway, which provides encryption services and URL rewriting, is not required when the iPlanet Portal Server is operating in Open Portal mode.
Running iPlanet Portal Server without the gateway is referred to as Open Portal mode. The main difference between an open portal and a secure portal are the services presented by the open portal typically reside within the DMZ and not within the secured intranet.
Note Using the iPlanet Portal Server without the gateway (Open Portal mode) may improve the individual response of the portal for a large number of simultaneous users.
The Secure Portal
The iPlanet Portal Server 3.0 product was targeted towards customers deploying highly secure portals or remote access portals. These types of portals have a major emphasis on security and protection and privacy of intranet resources. The iPlanet Portal Server architecture is well suited to this type of portal. The URL Rewriting, URL Access Policy, and Netlet features of the gateway, allow users to securely access intranet resources from the Internet without exposing these resources to the public Internet. The gateway, residing in the DMZ, provides a single secure access point to all intranet URLs and applications. All other iPlanet Portal Server services such as Session, Authentication, Desktop, Channels, and Profile database reside behind the DMZ in the secured intranet. Communication from the client browser to the gateway is encrypted using HTTP over SSL. Communication from the gateway to the server and intranet resources may be either http or https.
The Open Portal
The release of iPlanet Portal Server 3.0 Service Pack 1 enables the features necessary for iPlanet Portal Server to be deployed without the services of the gateway.
Configuring iPlanet Portal Server 3.0 to Run SSL in Open Portal Mode
The typical public portal runs in the clear or using http. It may however be desirable to deploy a portal using HTTP over SSL (https). The Portal server may be configured to run https services during installation or manually changed from http to https after installation.See the iPlanet Portal Server 3.0 Administration Guide for more information on using SSL.
Note This type of open portal does not require the services of the gateway.
Users access the server directly as if the server was configured for http, but use https://server.domain instead of http://server.domain.
The following features are not available when running without the gateway or in Open Portal mode:
One iPlanet Portal Server installation may be configured to support both open and secure portal.
For example, a company may want to create a portal which resides within the intranet:
When users access the portal from the intranet, log in to the server directly using http
When accessing the portal from the internet use https through the gateway
Install iPlanet Portal Server 3.0 software on the portal server.
Note In the following instructions and examples, /opt is a default installation directory.
Apply iPlanet Portal Server 3.0 Service Pack 2 on the portal server.
- When prompted for Gateway Name, use the name of the portal server.
Note iPlanet Portal Server 3.0 Gateway software is not installed for Open Portal mode.
Stop and restart the portal Server:
# /opt/SUNWips/bin/ipsserver start
Updating an Existing Gateway/Server Installation to Open Portal Mode
Install iPlanet Portal Server 3.0 Service Pack 2 on the portal server, then do the following:
To completely remove the gateway on a different computer from the portal server, remove the SUNWwtgwd and SUNWwtsd packages.
To completely remove the gateway, and the gateway and portal server are on the same machine, only remove the SUNWwtgwd package.
To shut down the gateway only, run the ipsgateway stop script:
# /opt/SUNWips/bin/ipsgateway stop
Logging Into the Open Portal
To log in to the Open Portal use the following rules:
Note Users should always use the fully qualified name of the server.
If the server name is my.sun.com and the server is running http use the following URL:
or
- http://my.sun.com:port
- http://my.sun.com if port 80 is configured.
If the server name is my.sun.com and the server is running https use the following URL:
or
- https://my.sun.com:port
- https://my.sun.com if port 443 is used.
Multi-hosting in Open Portal Mode
Service Pack 2 adds functionality which allows the server to access multiple DNS and IP addresses from a single server installation.Access to the iPlanet Portal Server is through either:
http://server:port
To log in to a different domain on the Portal, use the following URL:https://server:port (if the server was configured to HTTPS)
- Where server is the Portal server name, and port is the Portal server port.
- http://server:port/login/domain_name
- Where domain_name is a Portal domain name.
URL to Domain Mapping
If the existing installation of portal server contains multiple servers and multiple domains, a URL to domain mapping allows the portal server to find the domain automatically without the need to provide the domain name in the URL.The following example describes how to map a URL to a specific domain:
If the iPlanet Portal Server installation has one server (server1), and two domains (domain1 and domain2), the following URL to domain mapping is needed:
To map a URL to a domain, do the following in the Administration console:
Logon as Super Administrator.
Repeat these steps for the second domain.Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
Select one of the domains.
In the Domain, Role and Users page:
Domain URL Mapping List
The domain URL list for domain1 must contain the following URLs:
Add the following two lines to obj.conf (as shown in bold text in the following example).
The obj.conf is located at:
The following is another example:
- /opt/netscape/server4/https-server1/config/obj.conf
- Where domain 1 and domain 2 are the iPlanet Portal Server domain names.
If there are three servers (server1, server2, and server3) and two domains (domain1 and domain2), the following are the URL to domain mappings:
To map a URL to a domain, do the following in the Administration console:
- http://server1:port ---> go to domain 1
- http://server2:port ---> go to domain 2
- http://server3:port ---> go to domain 2
Logon as Super Administrator.
Repeat these steps for the second domain.Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
Select one of the domains.
In the Domain, Role and Users page:
Domain URL Mapping List
The domain URL list for domain1 must contain the following URLs:
The domain URL list for domain2 must contain the following URLs:
Configuring Multiple Instances of iPlanet Portal Server
This configuration supports running multiple instances of the iPlanet Portal Server 3.0 on different ports, giving the user just one virtual server to interact with.Running multiple instances of iPlanet Portal Server 3.0 servers, each with its own copy of iPlanet Web Server on the same physical machine, changes the context of iPlanet Portal Server 3.0 to have multiple web servers and JVMs on the same machine.
It is possible to configure the various instances to implement SSL, giving a user the flexibility of switching to SSL mode for security on any of the iPlanet Portal Server instances. So when running in open portal mode, iPlanet Portal Server instances can talk over SSL.
Note Using the create command will only configure new iPlanet Portal Server instances using the http protocol.
Installing Multiple Server Instances
To create multiple instances of the iPlanet Portal Server installation on different ports, do the following:
Install iPlanet Portal Server 3.0 Service Pack 2 on the Portal server, then do the following steps.
This is an interactive option where the administrator can continue to enter unique port numbers, not already in use, where the multiple instances are to be created. Enter a blank line (Return) when finished.
As root, in a terminal window enter the following commands:
- See the Service Pack 2 Installation Notes in this document.
Note In the following instructions and examples, /opt is a default installation directory.
# cd /opt/SUNWips/bin
# ./ipsserver create
Tip From the command line, type: This will print out all ports currently assigned and in use.
This process takes approximately 5 minutes depending on the machine architecture. The script output looks like the following example. (Where the bold text is user input).
If any of the above instances already exist then the following message will be displayed before being prompted to overwrite:
Warning:: server instance already exists:smyrna.red.iplanet.com-8081
Select Return when menu is completed.
This will start all the portal server instances, including the original installation.Stop and restart all the Portal Servers:
# /opt/SUNWips/bin/ipsserver startall
In the iPlanet Portal Server Administration Console, do the following:
- To start the different server instances separately, use the individual ipsserver scripts in the /opt/SUNWips/bin directory.
- To start the server instance running on 8081, for example:
- /opt/SUNWips/bin/ipsserver.smyrna.red.iplanet.com@8081 start
- The original server can still be started by:
- /opt/SUNWips/bin/ipsserver start
Logon as Super Administrator.
Stop and restart all the Portal Servers:Select the Server Management link from the left frame.
Select the Manage Server Profile link in the right frame.
Change the Server List attribute.
Select the Submit button, at the bottom of the page, and save the changes.
- Add the new server instances to the Server List:
- http://ipsserver.smyrna.red.iplanet.com@8081
- http://ipsserver.smyrna.red.iplanet.com@8082
Select the Continue button on the Profile Successfully Updated page.
# /opt/SUNWips/bin/ipsserver startall
These instances can be directly accessed through the web browser, as follows:
If the machine name is smyrna.red.iplanet.com, and two port numbers 8081 and 8082 were configured as shown in the Step 2 example, and the install directory was /opt, the following files will be listed:
- http://servername:port1
- http://servername:port2
- /opt/SUNWips/bin/ipsserver.smyrna.red.iplanet.com
- /opt/SUNWips/bin/ipsserver.smyrna.red.iplanet.com@8081
- /opt/SUNWips/bin/ipsserver.smyrna.red.iplanet.com@8082
Updated Command Options
The following command options have been updated, and new commands added:
Changing the Profile Server to SSL in an Open Portal Environment
This section discuses how to change the profile server's protocol to HTTPS. This is also the server which has the profile service running on it. See the following instructions.
Note In the following instructions and examples, /opt is a default installation directory.
In a terminal window, become root, and type the following command:
# /opt/SUNWips/bin/ipsserver start In the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
From the admin console, select Server Management.Select the Server Management link from the left frame.
Select the Manage Server Profile link in the right frame.
Change the Platform Server List attribute.
Select the Submit button, at the bottom of the page, and save the changes.
- Change the protocol of the URL for the original server to be https.
- https://ipsserver.smyrna.red.iplanet.com@8080
Select the Continue button on the Profile Successfully Updated page.
Select Manage Naming profile.
In a terminal window, open the /etc/opt/SUNWips directory.In the Profile URL, change the protocol to https.
- https://ipsserver.smyrna.red.iplanet.com@8080/profileservice
In the Logging URL, change the protocol to https.
- The profile URL would be changed to https if the original server is running the profile service as well. If the profile service is running on a different machine, the protocol should be the same as the server running the profile service.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
- https://ipsserver.smyrna.red.iplanet.com@8080/loggingservice
Select the Continue button on the Profile Successfully Updated page.
Make the following changes to the platform.conf file of the server that will be configured for SSL, The file maybe any of the files listed above.
- The directory will contain platform.conf files of the type:
- /etc/opt/SUNWips/platform.conf.smyrna.red.iplanet.com
- /etc/opt/SUNWips/platform.conf.smyrna.red.iplanet.com@8081
- /etc/opt/SUNWips/platform.conf.smyrna.red.iplanet.com@8082
- In this example the original server will be configured for SSL,
- From a terminal window, use a text editor to edit the platform.conf file:
- /etc/opt/SUNWips/platform.conf
- Edit the following entries as shown in bold text in the following example:
ips.server.protocol=https
From a terminal window, use a text editor to edit the magnus.conf file:
- /opt/netscape/server4/https-servername/config/magnus.conf
Stop and restart all the Portal Servers:
- The Security option must be turned on, for the server to talk over SSL.
- Edit the entry as shown in bold text:
# /opt/SUNWips/bin/ipsserver startall
Changing the Created Multiple Instance Servers to SSL in an Open Portal Environment
The section discuses how to change the protocol to HTTPS of any of the other created multiple instances. Make these changes for the server where SSL is required. Make sure that the key pair file password and the trust database password entered for any of the certificate installation is the same between all the iPlanet Portal Server created multiple servers which are being configured to talk over SSL and that password must be the SSL passphrase entered during the iPlanet Portal Server server installation.
Note In the following instructions and examples, /opt is a default installation directory.
If the instance running on port 8081 is to be secure, for example, do the following:
Stop and restart all the Portal Servers:
# /opt/SUNWips/bin/ipsserver startall In the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
In a terminal window, open the /etc/opt/SUNWips directory.Select the Server Management link from the left frame.
Select the Manage Server Profile link in the right frame.
Change the Platform Server List attribute.
Select the Submit button, at the bottom of the page, and save the changes.
- Change the protocol of the URL for the instance server to be https.
- https://ipsserver.smyrna.red.iplanet.com@8081
Select the Continue button on the Profile Successfully Updated page.
Make the following changes to the platform.conf file of the server that will be configured for SSL,
- The directory will contain platform.conf files of the type:
- /etc/opt/SUNWips/platform.conf.smyrna.red.iplanet.com
- /etc/opt/SUNWips/platform.conf.smyrna.red.iplanet.com@8081
- /etc/opt/SUNWips/platform.conf.smyrna.red.iplanet.com@8082
Note If the original server running the profile server has been changed to talk over SSL, then the protocol in ips.naming.url also needs to be changed to https.
- From a terminal window, use a text editor to edit the platform.conf file for the instance server:
- /etc/opt/SUNWips/platform.conf.smyrna.red.iplanet.com@8081
- Edit the following entries, as shown in bold text, in the following example:
ips.server.protocol=https
The Security option must be turned on, for the server to talk over SSL.
Stop and restart all the Portal Servers:
- From a terminal window, use a text editor to edit the magnus.conf file:
- /opt/netscape/server4/https-servername@port/config/magnus.conf
- Edit the following entries, as shown in bold text, in the following example:
# /opt/SUNWips/bin/ipsserver startall To confirm that the configured server is talking SSL protocol, directly access it at:
- https://smyrna.red.iplanet.com:8081
Configuring User Non-Root
This procedure configures User Non-Root on an iPlanet Portal Server 3.0 server. For the examples shown, the server and gateway are installed on the same system. If installing the gateway on a separate system, perform the same steps on the gateway computer, where appropriate.
Note A root-started gateway can run with a non-root user started server.
Installation Examples
When installing the iPlanet Portal Server 3.0 server, select a non-default install. If specifying a non-root userid, enter an unused port number above 1024 for the directory server (default is 389); these examples use port 8389, as all the other iPlanet Portal Server ports are in the 8000's. If a root password is not being implemented, change the super administrator's userid from the default root. If converting the gateway specify a different port, these examples use port 8443, instead of the default 443. Select a non-default install for the gateway to do this. A sample server and gateway install sessions appears below.
Note In the following instructions and examples, /opt is a default installation directory.
Installing iPlanet Portal Server Server
See the iPlanet Portal Server 3.0 Installation Guide for more information on installing the iPlanet Portal Server server software.
Tip Non-default entries are shown in bold text.
Installing iPlanet Portal Server Gateway
See the iPlanet Portal Server 3.0 Installation Guide for more information on installing the iPlanet Portal Server gateway software.
Tip Non-default entries are shown in bold text.
Configuring User Non-Root on the Server
Perform all steps as root, except as noted.
See the Installation Instructions for more information on installing Service Pack 2.
After installing the iPlanet Portal Server software do the following:
As root, in a terminal window:
Configuring User Non-Root on the Gateway
Note In the following examples for non-root user, substitute userid for the qualified name of a user.
- /opt/netscape/server4/http-Servername/config/magnus.conf.
As root, in a terminal window, do the following:
- Change the user root to the name of the user login name (Userid), as shown in bold text.
Edit the following file, to change the localuser to user login name (Userid), as shown in bold text:
- The userid is the name of the user, and MyGroupid is the name of the group the user belongs to. If the user, Jim, belongs to the staff group, then it would be written as:
Edit the following file, to change the User to user login name (Userid), as shown in bold text:
- /opt/netscape/directory4/slapd-Servername/config/slapd.conf
If the LDAP Directory Server process is also to run as a user other than root, edit the following file, to change the configuration.nsSuiteSpotUser to user login name (Userid), as shown in bold text:
- /opt/netscape/server4/https-servername/config/magnus.conf
As root, in a terminal window, do the following:
- /opt/netscape/directory4/admin-serv/config/local.conf (partial example)
# chown -R Userid:MyGroupid /etc/opt/SUNWips
# chown -R Userid:MyGroupid /var/opt/SUNWipsEdit the following file, to comment out line 559, check_root_user, as shown in bold text:
Rename the following files to prevent the iPlanet Portal Server server from automatically being started by root upon reboot:
- /opt/SUNWips/bin/ipsserver (lines 557 through 573)
# mv /etc/rc3.d/S42ipsserver /etc/rc3.d/XS42ipsserver
# mv /etc/rc3.d/K42ipsserver /etc/rc3.d/XK42ipsserverStart the iPlanet Portal Server server. From a terminal window, as the non-root user, do the following:
% /opt/SUNWips/bin/ipsserver start
Edit the following file, to comment out lines 174 through 178, as shown in bold text:
Edit the following file, to add ips.gateway.user=Userid, as shown in bold text:
- /opt/SUNWips/bin/ipsgateway (lines 173 through 184)
Rename the following files to prevent the iPlanet Portal Server gateway from automatically being started by root upon reboot:
- /etc/opt/SUNWips/platform.conf
Note Must be a valid userid on the iPlanet Portal Server gateway. If ips.gateway.user does not match the userid for which the procedure has been applied, permission problems will result.
# mv /etc/rc3.d/S90ipsgateway /etc/rc3.d/XS90ipsgateway
# mv /etc/rc3.d/K90ipsgateway /etc/rc3.d/XK90ipsgatewayStart the iPlanet Portal Server server and gateway. From a terminal window, as the non-root user, do the following:
% /opt/SUNWips/bin/ipsserver start
% /opt/SUNWips/bin/ipsgateway start
Non-Root Error Messages
Running as a non-root user, there will be error messages on the server and gateway. These messages are expected, and workarounds are offered when appropriate.
Server Error Messages
Because a non-root user may not set the maximum file descriptors to a value larger than 1024. The ipsserver script attempts to set it to 10240.
/opt/SUNWips/bin/ipsserver: ulimit: exceeds allowable limit Failure to start the doSKey. This error is not common.
starting auth helpers ... ld.so.1: /opt/SUNWips/bin/doSKey: fatal: libskey.so: open failed: No such file or directory
When running as a non-root user, if locally-administered UNIX userid is to be authenticated, then:
# chown root:sys /opt/SUNWips/bin/doUnix
# chmod 4555 /opt/SUNWips/bin/doUnix
Gateway Error Messages
Non-root users appear to be able to only set ulimit -n 1024 as a maximum number. Running as a non-root user will restrict how much load the gateway can simultaneously handle.
/dev/fd/some_number: ulimit: bad ulimit The /opt/SUNWips/bin/ipshttpd and /opt/SUNWips/bin/ipsnetletd scripts should have ulimit commands in them to increase the number of file descriptors the Netlet Proxy and HTTP Proxy, respectively, so that they may support more users. Running as non-root users, they are restricted to the 1024 limit, as well as the >1024 port number restriction.
Configuring User Nobody
To configure user Nobody on an iPlanet Portal Server 3.0 server, in the following examples, the server and gateway are installed on the same system. If installing the gateway on a separate system, perform the same steps on that system.Specifying nobody as the owner of the iPlanet Portal Server files is a special case, as nobody has an impossible resultant (encrypted) password. The user must be root to manipulate and execute files nobody owns.
When the iPlanet Portal Server server is to run as nobody, the server can be configured to listen on port 80, the default web server port. The LDAP server can also run on the default port 389, and the gateway on the default SSL port 443.
Installation Examples
When installing the iPlanet Portal Server 3.0 server, select a non-default install. The following procedures are install examples for both the server and the gateway.
Installing iPlanet Portal Server Server
See the iPlanet Portal Server 3.0 Installation Guide for more information on installing the iPlanet Portal Server server.
Tip Non-default entries are shown in bold text.
Installing iPlanet Portal Server Gateway
See the iPlanet Portal Server 3.0 Installation Guide for more information on installing the iPlanet Portal Server gateway.
Tip Non-default entries are shown in bold text.
Configuring User Nobody on the Server
Perform all steps as root, except as noted.
See the Installation Instructions for more information on installing Service Pack 2.
After installing the iPlanet Portal Server software do the following:
As root, in a terminal window, do the following:
As root, in a terminal window, do the following:
- Change the user root to the name of the user nobody, as shown in bold text.
# chown -R nobody:nobody /opt/netscape
# chown -R nobody:nobody /opt/SUNWipsEdit the following file, to change the localuser to nobody, as shown in bold text:
Edit the following file, to change the User to nobody, as shown in bold text:
- /opt/netscape/directory4/slapd-servername/config/slapd.conf
If the LDAP Directory Server process is also to run as a user other than root, edit the following file, to change the configuration.nsSuiteSpotUser to nobody, as shown in bold text:
- /opt/netscape/server4/https-servername/config/magnus.conf
As root, in a terminal window:
- /opt/netscape/directory4/admin-serv/config/local.conf
# chown -R nobody:nobody /etc/opt/SUNWips
# chown -R nobody:nobody /var/opt/SUNWipsTo set the http and netlet proxies on the server to run as nobody, edit the /etc/opt/SUNWips/platform.conf file, as shown in bold text:
ips.httpproxy.user=nobody
Start the iPlanet Portal Proxy server. From a terminal window, as root, do the following:
# /opt/SUNWips/bin/ipshttpd stop
# /opt/SUNWips/bin/ipsnetletd stop
# /opt/SUNWips/bin/ipshttpd start
# /opt/SUNWips/bin/ipsnetletd start
Configuring User Nobody on the Gateway
The following steps are for configuring user nobody on the gateway, when the gateway is not installed on the same system as the server.
See the Installation Instructions for more information on installing Service Pack 2.
After installing the iPlanet Portal Server software do the following on the gateway:
As root, in a terminal window, do the following:
When the gateway is configured as user nobody, do the following to workaround an invalid session condition when the gateway does a restart:
# chmod 666 /dev/random
# chown -R nobody:nobody /etc/opt/SUNWips
# chown -R nobody:nobody /var/opt/SUNWips
# chown -R nobody:nobody /opt/SUNWipsEdit the /etc/opt/SUNWips/platform.conf file, as shown in bold text:
ips.gateway.user=nobody
# chmod 4555 /etc/init.d/ipsgateway
Special Case Configurations
When the iPlanet Portal Server server and gateway are installed on the same system, and the server has been configured to run as user nobody or non-root, BUT the gateway was configured to run on a different Userid, do the following:
Note In the following instructions, /opt is a default installation directory.
Installing and Enabling Multiple Locale for a Domain
This feature provides support for multiple locales per installation. That is, the administrator can specify the locale for domains, roles, and users. For example, one iPS installation with three locale packages installed allows the admin to set up three domains, one for each locale. User's registering in domain1 will use locale 1, users registering in domain2 will use locale2 and so on.Every time you install a new locale, you must run the ipsadmin command to update the iwtPlatform attribute. The iwtPlatform attribute lists all the locales available for the user. For instance:
Attribute for available locale: <iwt:Att name="iwtPlatform-availableLocales"
Although the value for this attribute may look like en_US or ja_JA, users only see the common name, for instance, English (United States), of the available locale.
To specify the locale for domains:
Login in to the administration console and select Manage Domains.
Select the domain which you are administering.
Select Platform and Show Advanced Options.
Specify the languages you wish to make available for this domain.
Supporting SSL for Authentication in an Open Portal
In a portal setup without the gateway, this feature provides support for SSL (HTTPS) server for user registration although the sites run without SSL (HTTP). That is, a portal configured to return all content on the desktop using http can still support user registration or login through https.The iPlanet Portal Server will support this configuration by running two instances of iPlanet Portal Server; one instance running http and the other instance running https.
See Configuring Multiple Instances of iPlanet Portal Server for detailed information on setting up two instances of iPlanet Portal Server.
After setting up the server instances, convert the second instance of the server to SSL. See Configuring Multiple Instances of iPlanet Portal Server. After configuring the second instance, update the user profiles to redirect to the non-SSL server (instance) after initial authentication. To do this:
To ensure that all unauthenticated sessions on the non-SSL server (instance) are redirected to the SSL server (instance), edit the platform.conf file in /etc/opt/SUNWips/ directory:
Here servername refers to the host name of the SSL server instance and port refers to the port where the server instance is running.
All registrations and login will be directed to the https server, and all desktop redirects will be sent to the http server.
Edit /etc/opt/SUNWips/desktop/default/iwtLoginProvider/display.html as shown in bold text:
In the administration console set the user profile to point to the non-SSL port on the open portal. Do the following instructions:
- <FORM ACTION="https:smyrna.red.iplanet.com:444/login/Membership" onSubmit="return checkBlank()" MET
HOD=GET NAME="userid_form" ENCTYPE="application/x-www-form-urlencoded">
- and
- <FONT FACE="[tag:iwtDesktop-fontFace1]" SIZE="-1"><A HREF="https://smyrna.red.iplanet.com:444/login/Membership?arg
=newsession&page=1&Submit=New%20User">Sign Me Up</A></FONT>
Log in to the administration console and select Manage Domains.
Select your domain and select User (under Profiles).
Change User's Default URL from /DesktopServlet to:
Select the Submit button, at the bottom of the page, and save the changes.
- http://servername:port/DesktopServlet
Select the Continue button on the Profile Successfully Updated page.
Anonymous Authentication
For iPlanet Portal Server 3.0 Service Pack 2, an anonymous authentication module has been added.This zero-page auth module is specifically intended for supporting open portal installations, where just the iPlanet Portal Server server is installed without a gateway, although anonymous authentication may be used with a secure portal.
In a typical anonymous installation, the anonymous authentication module would be the only authentication type enabled. When the URL http://server:port/login/mydomain is specified, the user's browser displays the anonymous user desktop. No other user input is required, other than specifying the URL.
There is also a feature where a list of userid's that may login to the anonymous user's desktop can be specified. The list may be entered or modified through the administration console:
Managing Anonymous Username
If userid is in the List of Anonymous Usernames, then access to the anonymous user's desktop is granted, with the session assigned to the specified userid. If the userid is not in the List of Anonymous Usernames, then the anonymous desktop is still displayed, but the session is assigned to the userid specified in the Default Anonymous Username.
Modifying Default Anonymous Usernames
Logon as Super Administrator.
Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
In the Domain, Role and Users page:In the Authentication Menu:
Select Show Advanced Options at the bottom of the page.
In the List Anonymous User Names, add a userid in following form:
Select the Continue button on the Profile Successfully Updated page.http://server:port/login/mydomain?username=userid
Select the Submit button at the bottom of the page to commit these changes to the profile server.
Adding Userid to Default Anonymous Usernames
Logon as Super Administrator.
Select the Manage Domains link from the left frame.
In the Domain, Role and Users page:
In the Authentication Menu:
Select Show Advanced Options at the bottom of the page.
In the Default Anonymous User Names, add a userid.
Select the Continue button on the Profile Successfully Updated page.Select the Submit button at the bottom of the page to commit these changes to the profile server.
Redirecting the User Using the goto Parameter
The goto parameter enables applications to instruct auth to redirect the user to a URL other than the default URL stored in the user's profile upon login or logout.When a user authenticates, the application will prompt the user to specify the URL to which the user will be redirected to instead of sending the user to the default desktop URL stored in the user's profile.
The goto parameter allows the calling application to specify where the user will be redirected upon successful login. For example, if an application wanted the user to be redirected to my.yahoo.com after successful authentication, the login link will be the following:
http://server.domain:port/login?goto=http://my.netscape.com
An api developer can include the goto parameter used in conjunction with the logout URL to specify where the user should be redirected upon logout. If the application wanted to redirect the user to nasdaq.com after logging out, the logout link will be the following:
http://server.domain:port/logout?goto=http://nasdaq.com
To demonstrate the goto parameter, open a browser and in the Location field, enter:
http://<server.domain>:<port>/login?goto=<URL>
The goto parameter is valid for this auth session only and it will not change the default URL stored in the user's profile.
Setting Persistent Cookies
This enhancement enables setting persistent cookies. That is, when a user closes the browser or when the user's session expires, the user will not be required to re-authenticate.Persistent Cookie Mode is set by the user by selecting the Remember My Username and Password checkbox using the Login Channel. If the Persistent Cookie Mode is enabled:
However, if the user explicitly logs out, login is required on the next visit.
To set persistent cookie for a domain:
Log in to the administration console and select Manage Domains.
To demonstrate the persistent cookie mode, open a browser and in the Location field, enter:Select your domain and select Profiles and Authentication.
Select Show Advanced Options in the Profile:Auth page.
Specify the maximum age of the cookie in the Persistent Cookie MaxAge Value text box.
Select the Enable Persistent Cookie Mode check box.
http://server.domain:port/login/domain?iPSPCookie=yes
If the value for the parameter iPSPCookie is yes, then the persistent cookie mode is enabled.
Extending Authentication
No authentication is required if a valid session is present. That is, if a user wanted to switch from anonymous user to a registered user, it was impossible to authenticate the user using another authentication module such as the Membership module since an anonymous user has a valid session. In Service Pack 2 this has been corrected.When a registered user authenticates from the anonymous desktop, the application will get the information about the user and present the user's desktop from the user's profile. When a new user registers from the anonymous desktop, the user's current session (from the anonymous desktop) is destroyed before calling the auth module in the URL for the user's default desktop. This allows a user with a valid iPlanet Portal Server session to directly go to a login module without sending a logout URL. For example, a login channel will send the following URL to allow an anonymous user to register with the membership module:
http://server.domain:port/login/Membership?arg=newsession
Here, the arg=newsession parameter instructs the authentication module to destroy the current session before calling the authentication module in the URL.
Setting the Default URL
This feature allows setting up the user's default URL in the pluggable interface in addition to the user's profile. This method doesn't change the default URL in the user's profile. When the user authenticates successfully, the user will be redirected to this URL. A new method called setDefaultURL in the pluggable authentication API allows the authentication modules to set the user's default redirect URL on successful authentication. This method does not change the user's attribute in the user profile. This method will override the goto parameter. See Redirecting the User Using the goto Parameter, in the initial auth URL.
public void setDefaultURL(java.lang.String url)
Getting and Setting User Properties
This feature allows the authentication module to set and get user properties from the user session. Two new methods called setUserSessionProperty and getUserSessionProperty in the pluggable auth API enables authentication modules to get and set properties in the user session. This allows authentication modules to communicate with channels, applications, or other authentication modules by setting session properties. For example, a custom authentication module may add the user password to the session, so that an application may retrieve this property, for single sign on at a later time.
public void setUserSessionProperty(java.lang.String name,
Using E-mail Address As User's Profile ID
This feature provides the ability to use an E-mail address on the certificate as the user's profile ID.To use the E-mail address as profile ID:
Log in to the administration console and select Manage Domains.
Select your domain and select Profiles and Authentication.
Select email address from what field in cert to use to access user info in profile.
Select the Submit button.
- This allows the administrator to specify what to use to access the user's profile id. If email address is selected, the cert auth module will search for the field emailAddr in the certificate's user subject dn field for the attribute tag emailaddr and use its value to access the user's profile id.
- The tag emailAddr is stored in the iwtAuthCert.properties file and it can be replaced with a different value depending on the site and/or certificate issuer.
Login Channel
The Portal Server 3.0 currently contains a membership authentication module which is useful for open portal installations. Combined with an anonymous user, unregistered users can view static content in a portal, and registered users can log in and view personalized content. The addition of a login channel on the desktop provides a simple way for registered users to access the portal while allowing non-registered users to still view static content and provides a simple mechanism to register with the portal and receive personalized pages.The login channel also provides an option to the user to enable persistent cookies. Persistent cookie support is a feature of the authentication system which puts the user's login information into a cookie so that the user can be automatically logged in for subsequent sessions. The channel provides a check box that allows the user to enable persistent cookie support for their login, based on whether or not this domain allows for this option.
The user interface for the login channel does not have an edit page, as there are no user editable preferences.
JavaServer Page Provider
The JavaServerTM Page Provider (JSPProvider) feature allows providers for desktop channels to be written using JavaServer Pages (JSP).Support for JSP-based channels is provided through a class called JSPProvider. A JSP Provider-based channel has, in addition to the regular attributes that other channels have, the following configured attributes:
contentPage - the JSP that is used to generate the channel content using the getContent method
There are several options for handling the processing of an edit form for a JSP-based provider. Typically, processing of the edit form consists of Java code that checks validity of the form entry and updates user preferences for the channel. The result is either a display of the desktop (in the case of success) or a display of the edit page, possibly with some error information for the user (in the case of a failure). To handle the processing of an edit form, the JSP-based provider has the following options:editPage - the JSP that is used to generate the edit page content using the getEdit method
processPage - the JSP that is used to process the results of an edit page using the processEdit method
The contentPage JSP generates the HTML content for the channel. The generated HTML must contain only those tags that are appropriate for display within a channel.
The editPage JSP generates the internal content for the edit form that is displayed when the user clicks the Edit button for the channel. This page is optional, and if not specified, the isEditable method for the provider returns false. As with the contentPage JSP, the JSP has access to iPlanet Portal Server platform services.
The contentPage and editPage JSPs can be used in various combinations. For example, a JSP can be used to generate the content while the edit page can be generated using Java code in the provider class.
Define a processPage JSP. If defined, this JSP is invoked via a POST request and the JSP can process the results, either using a script or a bean or other Java class. The JSP must produce a redirect in the response. This redirect then becomes the return value for the provider's processEdit method.
The JSPProvider extends the ProfileProviderAdapter class to support other attributes for the channel by using the profile service.Extend the JSPProvider class and implement the processEdit method. The processPage attribute is left blank.
When specifying a JSP in one of the JSP attributes, the path name is interpreted relative to the desktop template directory for the user using the same algorithm as for other desktop templates including the locale setting.
The system searches for the following JSP files:
For more information on implementing JSP-based channels, see the javadocs that are shipped with Service Pack 2.
- /etc/opt/SUNWips/desktop/SunBlue_de_DE/myChan/chan.jsp
- /etc/opt/SUNWips/desktop/SunBlue/myChan/chan.jsp
- /etc/opt/SUNWips/desktop/SunBlue_de_DE/chanadd.jsp
- /etc/opt/SUNWips/desktop/SunBlue/chan.jsp
- /etc/opt/SUNWips/desktop/default_de_DE/myChan/chan.jsp
- /etc/opt/SUNWips/desktop/default/myChan/chan.jsp
- /etc/opt/SUNWips/desktop/default_de_DE/chan.jsp
- /etc/opt/SUNWips/desktop/default/chan.jsp
Tabbed Desktop
Service Pack 2 offers tab functionality to the user desktop. The desktop can use the tabs feature to organize content. Tabs are not active by default, and must be turned on for any given domain. The Tab Provider is enabled by the super administrator through the Administrator's console, and tabs are then configured, or removed in a chosen domain. Tabbed desktop pages can be individually modified to configure the desktop in a personalized way, as shown in the following procedures.
Configuring the Tab Desktop in the Administration Console
This procedure presumes that Tab Desktop is not configured in a particular domain. To enable the Tab Desktop, do the following in the iPlanet Portal Server Administration Console:
Log on as Super Administrator.
Select the Manage Domains link from the left frame.
Select a domain in the right frame, to configure the Tab Desktop.
Expand the Applications link in the right frame.
Select Show Advanced Options at the bottom of the Profile: Desktop page.
In the Profile: Desktop page, scroll down to the Channels Field.
If the iwtTabProvider is shown in the Available Channels window then do the following:
Highlight iwtTabProvider in the Available Channels window.
If the iwtTabProvider is not shown in the Available Channels window then do the following:Select the arrow, and the iwtTabProvider should then appear in the Selected Channels field.
In the New Channel Name window, enter a new channel name, iwtTabProvider.
Scroll down the page and confirm that the Active Channel List Module contains a Tab Channel List entry. The Tab Channel List Module must be selected. See the following example:In the Provider Class Name window, enter a new provider class:
Select Add.
- com.iplanet.portalserver.providers.tab.TabProvider
iwtTabProvider will now be shown in the Available Channels window.
Highlight iwtTabProvider in the Available Channels window.
Select the arrow, and the iwtTabProvider should then appear in the Selected Channels field.
In the Start Tab field, enter a tab name. The first tab default name is My Front Page.
- com.iplanet.portalserver.desktop.util.channellist.TabChannelList
In the Available Tabs field, edit the default tab conditions that the tab will contain. The following string is an example. Change the name, providers, and description to create a custom tab:
- This Tab will always be present on every desktop in the domain, and is not user configured.
In the Tab Pattern field, enter in a string, the name of a tab content template, and the providers to be included. See Step 12.
- name=new tab|channels=iwtTabProvider;iwtUserInfoProvider;
iwtIPInfoProvider;iwtSampleRss|desc=new tab description|
removable=true|renamable=true
In the Make From Scratch Tab field, enter a suitable heading title, and all the content providers that will appear on the Edit Tab Provider page. See the following string as an example:
In the Maximum Number of Tabs field, enter a number.
- name=Make From Scratch ...|channels=iwtTabProvider;iwtUserInfoProvider;
iwtBookmarkProvider;iwtIPInfoProvider|desc=Design a tab from the ground up|
removable=true|renamable=true
Select the Submit button, at the bottom of the page, and save the changes.
- This will be the total number of tabs that may be on the desktop. 4 is a default value.
Select the Continue button on the Profile Successfully Updated page.
Configuring the Tab Desktop on the Desktop
Any user can configure the tabs on the desktop. The tab's channel edit page allows a user to create, rename, or remove tabs from their desktop. Additionally a user can select which tab should be present on the initial desktop page.
As a user, log in to the iPlanet Portal Server desktop.
In the Edit Tab Provider page, the user can use a pre-defined tab content template by topic, or by choosing each channel for the new tab manually.In the desktop, select the Edit button, on the right of the tab banner.
Creating Customized Tabs
In the Edit Tab Provider page, do the following:
In the Tab Name field, enter the name of the tab being created.
In the Channels page, do the following:In the Tab Topics field, select the radio button for Make From Scratch.
Select Finished at the bottom of the page.
Select the desired channels, to customize the desktop page.
The desktop screen will return back to the User Desktop Page.
Select Finished at the bottom of the page.
- Thin and thick channels are determined by the administrator, when configuring Desktop Pages and layout in the administration console.
Creating Default Content Tabs
In the Edit Tab Provider page, do the following:
In the Tab Name field, enter the name of the tab being created.
The desktop screen will return back to the User Desktop Page.In the Tab Topics field, select the radio button of a pre-made Tab Content Provider.
Select Finished at the bottom of the page.
Changing Membership Login Password
To change the membership login password, the user must choose the Edit icon from the User Information channel menubar.In the Membership Password area are fields for:
The user enters the original password, and the new and confirm passwords must match for the change to be successful. Password checking is subject to the same rules as the membership authentication module.
The user must have authenticated via Membership for changes to the Membership password.
Reloading Templates with No Restart
When the desktop accesses templates to generate content, it reads them from disk and caches them. All subsequent requests for the template are served from the cache.The desktop periodically checks to see if the disk files have been updated. If the disk file is newer than the cache, the template is re-cached based on the updated disk file.
The length of time between checking to see if the disk files have been updated is the template scan interval. This interval may be changed in the iPlanet Portal Server Administration Console. Changing the template scan interval causes the desktop to immediately check for changes to the disk files and then wait for the new interval value before re-checking again.
To change the template scan interval, do the following in the iPlanet Portal Server Administration Console:
Log on as Super Administrator.
Select the Management Platform Settings link from the left frame.
Expand the Applications link in the right frame.
In the Component Profile: Desktop page, scroll down to the Template Scan Interval Field.
Select the Submit button, at the bottom of the page, and save the changes.
- This field can be edited. The default value for the template scan interval is 900 seconds, or 15 minutes.
Select the Continue button on the Profile Successfully Updated page.
Enabling Anonymous Desktop
The following is the recommended procedure for enabling an anonymous desktop using the new Anonymous Authentication Module and Login Channel delivered with Service Pack 2.
Configuring Anonymous Authentication
To enable the Anonymous Desktop, in the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
In the Domain, Role and Users page:In the Authentication Menu:
Select Anonymous and de-select all other authentication modules
Select the Continue button on the Profile Successfully Updated page.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
- The portal server is now defaulted to the Anonymous authentication module in all cases and will display the anonymous desktop by default.
Select Show Advanced Options at the bottom of the page.
In the Non Interactive Modules, add Membership.
Select the Continue button on the Profile Successfully Updated page.
Select Enable Persistent Cookie Mode.
- This will enable users to use the login channel to use Membership authentication instead of having to use the built-in membership login page.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
Customizing Templates for Anonymous Desktop
To customize a user logout from the desktop redirect to the anonymous user desktop, do the following:
Edit the /etc/opt/SUNWips/desktop/default/iwtDesktop/menubar.html as shown in the code example, in bold text.
To customize the Help page for the anonymous desktop, do the following:
- Change the HREF for the Log Out link to:
- This will set the logout from the desktop to be redirected to the anonymous desktop in all cases.
Logon as Super Administrator.
Select the Anonymous User Desktop.
Select the Manage Domains link from the left frame.
Select the domain.
Select the Continue button on the Profile Successfully Updated page.Scroll down to, and select Show Advanced Options.
Modify the value for Front Page Help.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
- The value in Front Page Help is assumed to be relative from the directory:
- /opt/SUNWips/public_html/docs/en_US/online_help
Enabling Anonymous Desktop for Other Domains
To create an anonymous user for any other domain, do the following steps:
Copy /var/opt/SUNWips/iwtAnonymousUser.xml-orig file to a temporary location (/tmp)
# cp /var/opt/SUNWips/iwtAnonymousUser.xml-orig /tmp/iwtAnonymousUser.xml-orig Edit the /tmp/iwtAnonymousUser.xml-orig file as shown in the example, in bold text.
Use the ./ipsadmin command to load the new anonymous user profile to the profile service. Type the following commands in a terminal window:
- Change the string INST_DEFAULT_DOMAIN to the name of the other domain.
userConfigurable="true" > <Val>/INST_DEFAULT_DOMAIN/defaultRole</Val> </iwt:Att> <iwt:Att name="iwtDesktop-layout" userConfigurable="true" > <Val>thin-thick</Val> </iwt:Att>
# cd /opt/SUNWips/bin
# ipsadmin create user /other_domain/anonymous /tmp/iwtAnonymousUser.xml-origTo access the authentication menu for the new domain in the browser location, type:
http://your_server/login?domain=/other_domain
Disabling the Anonymous Desktop
To disable the Anonymous Desktop, in the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
Select the domain.
In the Domain, Role and Users page:
In the Authentication Menu:
De-select the Anonymous auth module.
Select the Continue button on the Profile Successfully Updated page.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
- There must be at least one other auth module entry remaining in the field when de-selecting any module.
Modifying the Login Channel
The login channel can be modified to work with other authentication modules, other than the default login channel shipped with Service Pack 2. A sample template is available to illustrate how the login channel can be changed to work with the Unix authentication module, rather than the Membership authentication module.To enable Unix authentication for the login channel, do the following:
Note When replacing files to modify the operation of the desktop, make copies of the files being replaced, first, so that they can be re-instated at any later date.
As root, in a terminal window, make a copy of the following file:
The login channel will now use Unix authentication.
# cd /etc/opt/SUNWips/desktop/default/iwtLoginProvider
# cp display.html display_iwtAuthMembership.htmlReplace the display.html file with the following file:
Logon as Super Administrator.
Select the Manage Domains link from the left frame.
In the Portal Server Domains page, do the following:
Select the domain to add the unix authentication.
In the Domain, Role and Users page:
In the Non Interactive Modules field:
Select the Continue button on the Profile Successfully Updated page.
Viewing the contents of the template file, display_iwtAuthUnix.html, will give the user an example of how other templates could be created to enable other authentication modules for the login channel. View the contents of the built-in login page for a given authentication method to get an example of the correct parameters to include in the display.html template.
Using Form Control
A method has been added to the provider API which allows a channel to return either a complete HTML edit form, or a subset of a complete HTML page in response to a request for the edit page.
Provider API
Several changes are required in the provider API to support form control.There are integer constants to define the form types, which are return type from the .getEditType() method:
New methods are added to query and set the form type.
- public static final int provider.EDIT_SUBSET ;
- public static final int provider.EDIT_COMPLETE ;
The desktop uses the .getEditType() method so it can expect either a complete or subset HTML form to be returned when calling channel.getEdit().
- public int getEditType();
The desktop servlet is expecting some particularities as edit forms are posted, there are some restrictions on what can be returned from .getEdit() when the edit type is equal to EDIT_COMPLETE:
This method returns a complete, valid, HTML form
The following parameters must be present in the submitted form:The form is an encoding type of application/x-www-form-urlencoded
The form must contain the correct parameters for instructing the desktop to process the page, as defined in editTemplate.html.
The form action must be /DesktopServlet, if the form should be submitted to the desktop servlet. When returning a complete HTML form, a channel must submit valid actions to the desktop as defined in the Desktop URL javadocs.
Provider Attributes
For channels that extend the ProfileProviderAdapter class, a new attribute can be defined in the profile component:
The default value will be different for each provider. Variations to this might include turning off write permission for OWNER, if one or the other edit type was not implemented.
The iPlanet Portal Server default channels all return EDIT_SUBSET. Modifying the -editType attribute will cause a malfunction. A new channel must return EDIT_SUBSET, OR edit_COMPLETE depending on how the .getEdit() method is implemented.
Locking a Channel's Position
This feature enables an administrator to lock a channel's position. When a channel's position is locked, the user cannot move the channel from its position on the desktop. The purpose of locking a channel is to force the user to see particular content.With this enhancement, a channel can be locked, which means the user will not be able to change the position on the desktop.
The Layout page that allows the user to arrange channels on the desktop will not list a locked channel.
Log in to the administration console and select Manage Domain.
To unlock a channels position, do the following:Select the domain and select Profiles and Policy.
Deselect the Movable check box for the channel to lock the channel's position.
Deselect the Removable check box, so the channel may not be removed from the desktop.
- If you select the Movable check box, the channels can be moved around in the desktop.
Select the Submit button.
- Selecting the Removable check box will allow the user to remove the channel from the desktop.
Log in to the administration console and select Manage Domain.
Select the domain and select Profiles and Policy.
Select the Movable check box for the channel to unlock the channel's position.
Select the Submit button.
- If you select the Movable check box, the channels can be moved around in the desktop.
Setting Up Full-width Channel
Full-width channels have content that spans the full-width of the desktop, either at the top or bottom. A full-width channel can be simple static images or forms that need to be submitted.To configure full width channels:
Log in to the administration console and select Manage Domains.
Select your domain and select Applications and Desktop.
Select the channel you wish to modify and select the Edit Channel button.
Select the Show Advanced Options button.
Setting Up Frameless Channels
This feature enables setting up unframed channels in the desktop. The standard channel is displayed with a title, some set of controls, and inside a frame that appears similar to a window. The controls consist of icons linking to functions such as remove, edit, minimize etc. With this enhancement, you can set up a channel without a frame (that is, without the title and the controls).To configure frame-less channels:
Log in to the administration console and select Manage Domains.
Select your domain and select Applications and Desktop.
Select the channel you want to present without a border from the list of available channels.
Select the Edit Channel button and select Show Advanced Options.
Deselect the Framed? check box (if it is selected) to make the channel frame-less.
Select the Submit button.
- If the Framed? check box is selected, the channel will be displayed with a title and controls.
Note The channel will be displayed with a border. If you wish to modify the border of the channel, edit the hasBorder attribute in the Policy page.
Selecting the Locale
This feature allows users to choose their locale from a list of available locales on the platform. The provider displays a list of languages to the user, allows them to select one, and then stores the selection in the user profile. The user can refresh the desktop or re-login and get the new locale.
Log in to the desktop and select Edit to proceed to the Edit User Information screen.
Select the language from the list of available languages pull-down menu.
URL Scraping with No Gateway Installed
Some rewriting facilities from the Gateway Component Profile are used when configuring parameters for URL scraping. These parameters include:
Rewrite HTML attributes
In the Administration console, do the following to access the Gateway Component Profile page:Rewrite HTML attributes containing JavaScript
Rewrite JavaScript function parameters
Rewrite JavaScript variables in URLs
Rewrite JavaScript variables functions
Rewrite JavaScript function parameters in HTML
Logon as Super Administrator.
Select the Gateway Management link from the left frame.
Select the Manage Gateway Profile link in the right frame.
Select the Gateway Component Profile page.
- When the Open Portal mode is installed the selections on this page are not greyed out even though most selections are disabled because there is no Gateway running.
Forwarding Cookies
This feature allows the URL scraper to forward cookies which were passed in the HTTP request to the desktop. That is, the URL scraper will send cookies when it makes a connection to the target site to retrieve the content it is scraping. The URL scraper will also send set-cookie requests to the browser. That is, it will get all cookies from set-cookie headers and add them to the HTTP response to the client browser.By default, no cookies are forwarded. For the affected domain, role, or user, the list of cookies to forward must be set from the administration console. To forward cookies:
Log in to the administration console and select Manage Domains.
Select your domain and select Profiles and Policy.
Change the entries in the allow and deny lists for the Cookies To Forward privilege for the channel.
- A "*" entry allows or denies all cookies. Other entries are compared using a prefix match.
Configuring Restart of the HTTP Proxy
To automatically configure a restart of the http proxy whenever rebooting the system server, use the command line interface on the iPlanet Portal Server server to do the following:
Note If using more than one server, repeat these steps for each server.
As root edit the following file, as shown in bold text:
This will autostart the http proxy when the machine is rebooted.In a terminal window, do the following:
# cd /opt/SUNWips/bin
# cp ipshttpd /etc/rc3.d/K55ipshttpd
# cp ipshttpd /etc/rc3.d/S55ipshttpd
# chmod 500 /etc/rc3.d/K55ipshttpd
# chmod 500 /etc/rc3.d/S55ipshttpd
This will not autostart the http proxy when iPlanet Portal Server 3.0 is restarted using ipsserver start.
Enabling Access to HTTP Requests and Responses
This feature allows a provider to get access to the HTTP request and response. This is desirable for single sign-on, setting cookies, getting parameters for the HTTP headers, and for inserting data into the headers.The following are three new methods in the Content Provider interface:
These methods in the ProviderAdapter and ProfileProviderAdapter will call the old versions of the getContent, getEdit, and processEdit methods. The HttpServletRequest and Responses objects passed to the new methods have the following indicated behaviors:
Table 1 HttpServletRequest and Responses
Gateway Logging
When gateway logging is enabled, logging traffic between the gateway and the portal server can impact portal performance. In Service Pack 2, gateway default logging is disabled. To enable gateway logging do the following:
Note In the following instructions and examples, /opt is a default installation directory.
Logon as Super Administrator.
Select the Gateway Management link from the left frame.
Select the Manage Gateway Profile link in the right frame.
In the Component Profile: Gateway page, do the following:
Scroll to the end of the page and select the Show Advanced Options button.
Select the Continue button on the Profile Successfully Updated page.Scroll to near the bottom of the page to the Logging Enabled check box, and select the box to enable the gateway logging.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
# /opt/SUNWips/bin/ipsgateway start
Running Applications on a Non-iPlanet Portal Server
This section explains how to run applications written using the iPlanet Portal Server APIs on a non-iPlanet Portal Server server. The application may be either a standalone java application (with some limitations) or a servlet application running on the iPlanet Web Server server.
Note iPlanet Portal Server 3.0 public APIs are supported only on Solaris operating systems.
Setting Up a Non-iPlanet Portal Server 3.0 Server
Note In the following instructions and examples, /opt is a default installation directory.
Create the following directories on the non-iPlanet Portal Server server host.
Copy /etc/opt/SUNWips/platform.conf to the same location on the non-iPlanet Portal Server server.
- /opt/SUNWips
- /opt/SUNWips/lib
- /opt/SUNWips/locale
- /etc/opt/SUNWips
In order to receive notifications, the application's run time environment must support servlets.
Copy from /opt/SUNWips/lib the following files:
- Modify the ips.notification.url parameter in the platform.conf to be the fully qualified domain name of the server the application will be running on. See the example (in bold text):
Copy from /opt/SUNWips/locale the following files:
- to the same location on the non-iPlanet Portal Server server.
iwtPll.properties
If the client application will be running under iPlanet Web Server, update the classpath on the iPlanet Web Server:
- to the same location on the non-iPlanet Portal Server server.
- iws_server_root/https-your_server/config/jvm12.conf
Update the following iPlanet Web Server file:
- In the classpath, include:
- iws_server_root/https-your_server/config/rules.properites
Update the following iPlanet Web Server file:
- by adding the following line:
- /notificationservice=notificationservice
- iws_server_root/https-your_server/config/servlets.properties
Restart the iPlanet Web Server server after updating these files.
- by adding the following line:
- servlet.notificationservice.code=com.iplanet.portalserver.pll.client.PLLNotificationServlet
Applications Not Running Under iPlanet Web Server
The iPlanet Portal Server session and profile APIs have a notification feature which allows the application to listen for profile and session state changes. If the application is running as a standalone application the following conditions are in effect:
Cannot receive session or profile notifications
The client side cache will not be updated when attributes change in the profile. Only after the user logs out and logs back in will the application see the changes.
After the user session times out on the iPlanet Portal Server session server, the user will still have a valid session until the cache refresh timer is reached.
Tip Reduce the cache seconds attribute in the session profile in the iPlanet Portal Server 3.0 Administration Console.
Running Client Applications Using SSL
If the iPlanet Portal Server 3.0 server is configured to use SSL, then the iPlanet Portal Server APIs will also be using SSL. The application must also use SSL to communicate with the iPlanet Portal Server services.The iPlanet Web Server, when installed, is not properly configured to support outgoing SSL connections by servlets.
Note In the following instructions and examples, /opt is a default installation directory.
In order to enable SSL connections by servlets, do the following:
Copy from /opt/SUNWips/lib the following files:
Update the classpath on the iPlanet Web Server:
- to the same location on the non-iPlanet Portal Server server.
- iws_server_root/https-your_server/config/jvm12.conf
Copy the following file to the iws_server_root/bin/https/lib directory:
- In the classpath, include:
Restart the iPlanet Web Server after updating these files.
- /opt/SUNWips/lib/solaris/sparc/libjssl.so
Running Applications Through the iPlanet Portal Server Gateway (Secure Portal)
When using the iPlanet Portal Server gateway, the gateway must be configured to forward the iPlanet Portal Server cookies to the application host. If the URL of the server the application is running on is not added to this attribute, the iPlanet Portal Server cookie will not be forwarded, and the application will have an invalid user session. By default the gateway will only forward the cookie to the iPlanet Portal Server server.
Note In the following instructions and examples, /opt is a default installation directory.
In the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
Restart the gateway:Select the Gateway Management link from the left frame.
Select the Manage Gateway Profile link in the right frame.
Scroll down to the Forward Cookie URL List attribute.
Enter the URL of the server the application is running on in this field, for example:
Select the Submit button at the bottom of the page to commit these changes to the profile server.
- http://auth.red.iplanet.com:8080
Select the Continue button on the Profile Successfully Updated page.
# /opt/SUNWips/bin/ipsgateway start
Running Applications Without the iPlanet Portal Server Gateway (Open Portal)
When running the application without the gateway, access the application using a fully qualified domain name (FQDN). If a fully qualified domain name is not used, the iPlanet Portal Server cookie will not be forwarded to the application, and the user session will be invalid.
Software and Hardware Requirements
This section describes the system requirements for Service Pack 2 software. The system requirements depend on how the iPlanet Portal Server 3.0 product is used.
Table 2 describes the system requirements for developing a portal.
Table 3 describes the system requirements for deploying a portal.
Service Pack 2 Installation Notes
The iPlanet Portal Server 3.0 Service Pack 2 is a cumulative patch. It includes all Service Pack 1 and Service Pack 2 bug fixes and it can be used to upgrade the following:
Contents of iPS3.0SP2-01.tar
The iPlanet Portal Server 3.0 Service Pack 2 (iPS3.0SP2-01) software is downloaded from the iPlanet web page and is a tar file. The following directories and files are included in iPS3.0SP2-01.tar:
directory-4.12-domestic-us.sparc-sun-solaris2.6.tar (iPlanet Directory Server software upgrade required for Service Pack 2)
dsupgrade (upgrade script for the iPlanet Directory Server)
rn3sp2 (Release Note 2 document directory)
Patch 110169-01
Installation Instructions
iPlanet Portal Server 3.0 Service Pack 2 software package is available from the iPlanet.com web page:
The iPlanet Portal Server 3.0 Service Pack 2 software package includes iPlanet Directory Server 4.12 software. Upgrading to the iPlanet Directory Server 4.12 is required before installing Service Pack 2. See Upgrading iPlanet Directory Server to extract and upgrade the iPlanet Directory Server software.
Note In the following instructions and examples, /opt is a default installation directory.
Upgrading iPlanet Directory Server
Backup the iPlanet Portal Server 3.0 machine.
Change directories to /opt and create a directory for the Service Pack 2 iPS3.0SP2-01.tar
Download the Service Pack 2 package to /opt/sp2.
In a terminal window, become root.
In /opt/sp2, run the tar command to extract the package contents.
Change directories, and create a directory for the iPlanet Directory Server 4.12 tarfile, directory-4.12-domestic-us.sparc-sun-solaris2.6.tar.
# cd /opt
# mkdir ids_4.12_directoryChange directories to the sp2 directory and move directory-4.12-domestic-us.sparc-sun-solaris2.6.tar to the directory created in Step 6.
# cd /opt/sp2
# mv directory-4.12-domestic-us.sparc-sun-solaris2.6.tar ids_4.12_directory_pathChange directories and extract the files from directory-4.12-domestic-us.sparc-sun-solaris2.6.tar.
# cd ids_4.12_directory_path
# tar xf directory-4.12-domestic-us.sparc-sun-solaris2.6.tarChange directories to /opt/sp2 and run the dsupgrade command on the iPlanet Directory Server 4.12 directory.
# cd /opt/sp2
# ./dsupgrade ids_4.12_directory
Tip /opt/netscape/directory4/setup/setup.log contains information on any installation errors that might have occured during the iPlanet Directory Server upgrade.
Installing Service Pack 2
This procedure assumes that iPS3.0SP2.tar has already been downloaded and extracted from the tarfile in /opt/sp2.Before restarting the gateway and server check to see that the processes for the directory server and web server are running. See the following example:
As root, in a terminal window:
# ps -ef | grep ns-slapd
root 25936 1 0 Nov 28 ? 1:56 ./ns-slapd -f /opt/netscape/directory4/slapd-smyrna/config/slapd.conf -i /opt/n
root 298 293 0 14:36:44 pts/11 0:00 grep ns-slapdIssue a kill -TERM process for each directory server process that is running under iPlanet Portal Server. For example:
Verify that all directory server processes for iPlanet Portal Server are stopped:
# /etc/init.d/ipsserver start
# /etc/init.d/ipsgateway startAs root, change directories and run the installpatch command (shown in bold text), to install the software on the system.
# cd /opt/sp2/110169-10
# ./installpatch .
Tip /var/sadm/patch/110169-01/log contains information on any installation errors that might have occurred during the iPlanet Portal Server 3.0 Service Pack 2 installation.
Set the environment variable IPS_ROOT to the iPlanet Portal Server 3.0 installation directory.
Note In the following instructions and examples, /opt is a default installation directory.
Tip
- See ldapUdate Command Options for information about the command line arguments for this script.
# ./ldapUpdate -b root_dn -w password
# /opt/SUNWips/bin/ipsserver start
# /opt/SUNWips/bin/ipsgateway start
ldapUdate Command Options
The following script has been added to the Service Pack 2 package. The following describes the different command arguments for this script:
- ./ldapUpdate -b root_dn -w password [-p port] [-r] [-h]
Downgrading iPlanet Directory Server
The iPlanet Directory Server 4.11 software package is available from the iPlanet.com website:
To downgrade from iPlanet Directory Server 4.12 to iPlanet Directory Server 4.11:
- http://www.iplanet.com/downloads/download/index.html.
Note In the following instructions and examples, /opt is a default installation directory.
As root, restart the servers:
# /opt/SUNWips/bin/ipsserver start
# /opt/SUNWips/bin/ipsgateway start
# /opt/netscape/directory4/slapd-servername/db2ldif backup_file
Change directories and create a new directory for the iPlanet Directory Server 4.11 package:
- This command saves the directory data in a the backup file using ldif format. The backup file can be used to restore the directory data later.
# cd /opt
# mkdir ids_4.11_directoryDownload the iPlanet Directory Server 4.11 software package from the iPlanet web site to the ids_4.11_directory created in Step 3.
Un-compress and extract the files from the iPlanet Directory Server 4.11 media file:
# gunzip directory-4.11-export-us.sparc-sun-solaris2.5.1.tar.gz
# tar xf directory-4.11-export-us.sparc-sun-solaris2.5.1.tarChange directories to the directory that contains the dsupgrade script and run the dsupgrade script on the ids_4.11_directory.
# ./dsupgrade ids-4.11_directory
Backing Out the Service Pack 2 Software
This procedure assumes that the Service Pack 2 patch is in /opt/sp2.
Backup the iPlanet Portal Server 3.0 machine.
Run the ldapUpdate script to remove the changes to the ldap server.
Tip
- See ldapUdate Command Options for information about the command line arguments for this script.
# ldapUpdate -b root_dn -w password -r Change directories to the Service Pack 2 patch directory and run the backoutpatch script.
backoutpatch Command Options
The following describes the different command arguments for this script:
- .backoutpatch [-f] [-V] [-B backout_dir] [-R root_path | -S service] patch
Known Problems and Limitations
Here are known problems with the iPlanet Portal Server 3.0 software that have not been fixed in Service Pack 2, with workarounds where appropriate.
4381586
- A document can have a BASE attribute, which may be a different path than the URL which the document was fetched from. If there is a base URL, then all relative URLs within the document are considered to be relative to the base URL. If there is no base URL, then relative URLs are considered to be relative to the document's URL.
- But, when the Gateway encounters relative URLs, the Gateway always uses the document's URL for expanding the relative paths instead of using the base URL. The Gateway expands them to full paths starting with https://gateway/http://hostname:port/.
4383120
- The number of valid sessions (as indicated by the Valid Session number in the Manage User Session page) is inaccurate.
- For instance, when you log in to the administration console (either as super user or any user) and select Manage User Session, the Valid Session number is shown as 1. When you log in again from another browser, the Valid Session number does not increment to 2 to show that two valid sessions are in progress.
- The LDAP authentication module does not allow the admin to specify a search filter when configuring the server for user lookup in the directory. The text field, search filter for userId, refers to the attribute (by default, the uid attribute) to use in searching the directory. Then the attribute specified in the search filter for userId is used to create the search filter used in the lookup.
- For example, if you did not specify an attribute in the search filter for userId text field and left it blank, the default is uid. So, the search filter becomes (uid=jim), where jim is the username entered by the user. If the search filter for userId contained the value surname or sn, then the search filter would become (surname=jim).
4378030
- Desktop comes up blank if no channels are selected in the Administration Console and in the Desktop.
- Workaround:
- None.
4376634
- The setDomain method should attempt to retrieve a domain profile before setting the domain.
- Workaround:
- None
4379326
- The Administration console allows duplicate tab names if one attribute is different.
- Workaround:
- Verify that tab names are not duplicated.
4352059
- Contents of profilestyle.css can become visible in the Administration Console when adding a new user to a newly created domain.
- Workaround:
- None.
- The profile isAllowed method does not do wildcard matching, therefore, wildcard characters can not be used in domain names or URLs when configuring Netlet access to specific domains or when setting up access to specific URLs respectively.
- Workaround:
- None.
4397140
- The link on the Desktop logout page points to the server where the session was created. This implementation breaks load-balancing transparency.
- White space is not allowed in text fields for authentication methods in the administration console.
- Workaround:
- Verify that there is no white space in the authentication entry string.
4319604
- Detached providers are not being handled properly by operations in the Content link.
- Workaround:
- None
4355280
- Disabling the Netlet provider in the Administration console for a user causes error message: "Document contained no data".
- Workaround:
- Remove the provider from the channel list in the Administration console.
- When using Internet Explorer 5x on Windows 98, closing the Netlet window crashes the web browser.
- Workaround:
- None.
- External bookmark URLs are not redirected.
- Prevention:
- Remove open URL from the Gateway profile "rewrite JavaScript function parameters".
- Workaround:
- Create a second bookmark channel to handle external sites.
- The bookmark provider can not be used for URLs which reference Internet URLs that the Gateway cannot or should not fetch.
- The command ipsadmin does not check for the syntax of boolean flags.
- Workaround:
- When creating an XML file, if the attribute type is boolean, add a true or false statement, as shown in bold in the following example:
desc="Trust Proxy Feature" type="boolean" idx="X-x1" userConfigurable="TRUE"> <Val>false</Val> <Rperm>ADMIN</Rperm><Rperm>OWNER</Rperm> <Wperm>ADMIN</Wperm> </iwt:Att>
- The ipsserver start command requires additional arguments if the server is running multiple instances. For more information see Configuring Multiple Instances of iPlanet Portal Server
- Log records should be written using iwtPlatform-locale not iwtUser-locale.
- Workaround:
- None.
- The hour glass occasionally keeps running after attempting to add a share in Netfile Java.
- Workaround:
- Select some other part of NetFile to clear up the hour glass.
4307367
- A race condition occurs if when replying to a message, selecting send and then immediately deleting the message.
- Workaround:
- Wait for the reply flag to be set (slow down) or delete the message again.
- IMAP password is displayed in clear text in source of edit.
- Workaround:
- None
- The editType attribute is missing in the following xml files:
- Workaround:
- Add the following code inside the component tags of iwtHelloWorld3Provider.xml:
- Add the following code inside the component tags of iwtQuotationProvider.xml:
Bugs Fixed in Service Pack 1 and Service Pack 2
The following bugs have been fixed in iPlanet Portal Server 3.0 Service Pack 1 and Service Pack 2:
Where to Go for More Information
For document information about the iPlanet Portal Server 3.0, visit:
- http://docs.iplanet.com/docs/manuals/portal.html
Setting Session Time-out to the Maximum Value
As Super Administrator, access Session Profile.
Make value of Inactivity to the maximum value of: 15372286720912930.
Make value of Maximum to the maximum value of: 15372286720912930.
Using the Netlet Proxy
The Netlet proxy is used for the following reasons:
To minimize the use of extra IP addresses and ports from the Gateway through an internal firewall in a significantly sized deployment environment.
To provide encryption for each transaction through the Netlet to the iPlanet Portal Server server. This application of the Netlet proxy offers improved security benefits through data encryption but may increase the use of system resources.
Note If configuring the iPlanet Portal Server 3.0 to run as nobody, including netlet, see Configuring User Nobody on the Gateway, before reading these instructions.
Figure 1 Netlet Proxy Implementation
Configuring the Netlet Proxy
In the iPlanet Portal Server Administration Console, do the following:
Logon as Super Administrator.
Select the Gateway Management link from the left frame.
Select the Manage Gateway Profile link in the right frame.
In the Component Profile: Gateway page, do the following:
Scroll to the end of the page and select the Show Advanced Options button.
Select the Continue button on the Profile Successfully Updated page.Scroll to near the bottom of the page to the Netlet Proxy Enabled check box, and select the box to enable the netlet proxy.
In the Netlet Proxy Port, type in the desired (unused) port number to be used (for example: 8048).
Tip From the command line, type: This will print out all ports currently assigned and in use.
Select the Submit button at the bottom of the page to commit these changes to the profile server.
Configuring Restart of the Netlet Proxy
To automatically configure a restart of the Netlet proxy whenever rebooting the system server, use the command line interface on the iPlanet Portal Server server to do the following:
Note If using more than one server, repeat these steps for each server.
Note Configure the Netlet Proxy in the iPlanet Portal Server Administration Console before starting the services. See Configuring the Netlet Proxy" for instructions.
As root edit the following file, as shown in bold text:
This will autostart the netlet proxy when the machine is rebooted.In a terminal window, do the following:
# cd /opt/SUNWips/bin
# cp ipsnetletd /etc/rc3.d/K55ipsnetletd
# cp ipsnetletd /etc/rc3.d/S55ipsnetletd
# chmod 500 /etc/rc3.d/K55ipsnetletd
# chmod 500 /etc/rc3.d/S55ipsnetletd
This will not autostart the netlet proxy when iPlanet Portal Server 3.0 is restarted using ipsserver start.
How to Report Problems
If you have problems with iPlanet Portal Server 3.0 Service Pack 2, contact iPlanet customer support using one of the following mechanisms:
iPlanet online support web site at http://www.iplanet.com/support/online/
So that we can best assist you in resolving problems, please have the following information available when contacting iPlanet support:
The telephone dispatch number associated with your maintenance contract
- From this location, the CaseTracker and CaseView tools are available for logging problems.
Description of the problem, including the situation where the problem occurs and its impact on the operation
Machine type, operating system version, and product version, including any patches and other software that might be affecting the problem
For More Information
Useful iPlanet information can be found at the following Internet locations:
iPlanet release notes and other documentation --- http://docs.iplanet.com/docs/manuals/
iPlanet product status --- http://www.iplanet.com/support/technical_resources/
iPlanet Professional Services information --- http://www.iplanet.com/services/pro_serv/index.html
iPlanet developer information --- http://developer.iplanet.com/
iPlanet learning solutions --- http://www.iplanet.com/learning/index.html
iPlanet product data sheets --- http://www.iplanet.com/products/index.html
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.
Last Updated February 12, 2001