test

Sun Java System Portal Server 7.2 Administration Guide

Part I Managing Sun Java System Portal Server

Chapter 1 Understanding Portal Server Management

Portal Server administrators manage a variety of functions, including tasks for the following:

This chapter provides information about Portal Server components and the ways for managing a portal:

Understanding Portal Server Components

A Portal Server deployment has a number of components that affect portal administration. These components include the following:

For more information about Portal Server components, see the Sun JavaTM System Portal Server 7.2 Deployment Planning Guide.

Using the Portal Server Management Console

The Portal Server management console, which simplifies a variety of portal administration tasks, is a Java 2 Platform, Enterprise Edition (J2EETM) application that:

The management console enables portal administrators to perform the following activities:

About the Browser Interface

The management console's user interface arranges administration functions into pages. Across the top of each page is a tab strip. The tabs present pages that group management functions in an organized manner. To navigate from page to page, administrators click a tab. The tabs provided are the following:

Portal Server administrators can provide and limit access to content on a portal through the definitions of the identities of specific end users. You can set up portal pages, attributes and access policies so that portal content is available to specific entities. These entities include the following:

ProcedureTo Login to the Management Console

Only administrators with SuperAdmin permission and delegated administrators can access the Portal Server management console. Users access the Portal Server management console using a browser client from a distinct uniform resource identifier (URI).

  1. Type this URL in your browser: http://hostname:port/psconsole

    hostname

    The name of the system that the management console is running on.

    port

    The management console's port number assigned during installation.

  2. In the text boxes, type the Admin User Name and Password.

    The admin user should be a top-level administrator. A typical Admin User Name is amadmin.

  3. Click the Log In button.

    The management console's Common Tasks page is displayed.

Using the Portal Server Administration Tag Library and Portlets

Portal Server provides an administration tag library for developing administration portlets that enable a portal to be managed from the Desktop instead of from the management console. Administrators can use this tag library to do the following:

Administrators can use administration portlets to grant delegated administration status to other users, called delegated administrators. Portal Server provides a sample set of administration portlets that can be used to design a basic Desktop for delegated administrators.

For more information, see Sun Java System Portal Server 7.1 Developer Sample Guide and Tag Library for Delegated Administration.

Using the psadmin Command-line Interface

Portal Server software provides a command-line interface (CLI). The CLI allows portal administrators to do the following:

The CLI offers a number of psadmin subcommands for managing portal tasks. These include subcommands for:

Most subcommands commands are written specifically to mimic functions in the browser interface. For management functions that have no special commands, administrators use standard UNIX commands.

Caution – Caution –

If you installed Portal Server on Sun Java System Application Server 9.1 or GlassFish V2 web containers, you must start either of these web container administration servers and cacao before you invoke psadmin commands.

For information about all psadmin subcommands, see the Sun Java System Portal Server 7.2 Command-Line Reference.

Chapter 2 Managing Portals and Portal Server Instances

This chapter explains multiple portals and how to manage a portal and Portal Server instances. The topics provided include the following:

Understanding Multiple Portals

Multiple portals share the same user set. The features of multiple portals include the following:

All portals share these components:

The following components have a one-to-one relationship with portals:

Search can have a many-to-many relationship with portals:

End users see different content for different portals and can customize the each portal's Desktop. Single sign-on between portals is possible. An end user who has access to two portals at a corporation would typically experience the following sequence:

Portals that use different Access Managers are not multiple portals. They are independent and unrelated portals, each with its own set of users.

Access Manger can be a collection of its own instances, all using the same set of Directory Server instances. Different Access Managers are two unrelated Access Managers, not different instances of the same Access Manager.

Setting Up Portals

A portal consists of one or more portal server instances that deliver the same content and are mapped to a single Uniform Resource Locator (URL). The content and services delivered by a portal are common to all its instances.

Multiple portals share the same user set. These portals can be deployed on one or more hosts, but they all share the same user repository — the same Access Manager and the Directory server.

Note –

Portals that use different Access Managers are not multiple portals. They are independent and unrelated portals, each with its own set of users.

Access Manger can be a collection of its own instances, all using the same set of Directory Server instances. Different Access Managers are two unrelated Access Managers, and not different instances of the same Access Manager.

This section explains how to complete the following tasks:

ProcedureTo List Portals

You can view a list of Portal Servers that are already set up.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

Equivalent psadmin Command

psadmin list-portals

ProcedureTo Create a Portal

During Portal Server installation, a default portal named portal1 is created. You can also create a new portal server using the Create Portal wizard.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Click the New Portal button to launch the wizard.

  4. Provide a unique name for the Portal Server, for example, portal5.

  5. Type a URI that enables end users to access the Portal Server, for example, /portal.

  6. Enter Web Container Information.

    The available types are the following:

    • Sun JavaTM System Web Server 6.0

    • Sun Java System Web Server 7.x

    • Sun Java System Application Server 8.x

    • BEA WebLogic 8.1SP4/SP5

    • IBM WebSphere 5.1.1.6

  7. (Optional) Change the default web container instance properties.

    For information, see Creating a New Portal in Sun Java System Portal Server 7.1 Configuration Guide.

  8. Verify the information you supplied.

  9. Click Finish to create the new portal.

  10. (Optional) View the log file to monitor the process.

    1. Log in to the machine where portal is to be created.

    2. Run the psdadmin set-logger command.

      ./psadmin set-logger -u uid -f password -m component-type -O logger-name

Equivalent psadmin Command

psadmin create-portal

Templates for webcontainer.properties for supported web containers are in the portal-install-dir/template directory.

ProcedureTo Delete a Portal

You can delete all existing instances of a portal on all hosts and clean up the portal's data in the Access Manager LDAP directory.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. From the list of portals, select the portal you want to remove, and click the Delete Portal button.

Equivalent psadmin Command

psadmin delete-portal

ProcedureTo Export Portal Data

You can archive the following portal data in a par file:

After you archive data, you can import the data to the same portal or to a different portal. To export a portal from psconsole:

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal from the table.

  4. Click the Export button.

  5. Specify the par file location on the Portal Server machine and what you want to export:

    • All Desktop data — the exported par includes file system data and display profile data

    • File system data only — the exported par file includes only the desktop file system data, which is data deployed into the portal desktop and portal web-src

    • Display profile data only — the exported par includes only display profile data

Equivalent psadmin Command

psadmin export

Note –

This command does not support user data in the Directory Server.

ProcedureTo Import Portal Data to a Portal

You can import into any portal any portal data that you previously exported.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal from the table.

    The Import Desktop Data page appears.

  4. Click the Import button and specify the following:

    • The par file path for the imported data. The par file must be located on the Portal Server system.

    • Whether to continue if the storage structure of the portal does not match the archived file you want to import.

  5. Redeploy the portal web applications.

    1. Schedule a time to run the psadmin redeploy command.

      Plan to do this step off hours or in system maintenance mode, when your system is not in production. This action redeploys the portal war file, and it logs out users who are running a Desktop, causing them to lose their work.

    2. Run the psadmin redeploy command.

      psadmin redeploy -u amadmin -f passwordfile -p portalID --allwebapps

Equivalent psadmin Command

psadmin import

Note –

This command does not support user data in the Directory Server.

Setting Up Portal Server Instances

A Portal Server instance is a web application deployed to a web container. An instance uses a particular Portal Server context URI to serve requests on a specific network port. Each Portal Server instance is associated with a single Portal.

A server instance listens on a particular port, bound to either one IP address or any IP address of the host. For the Portal Server, a server instance corresponds to a deployment container process listening on a port and running a single Java™ Virtual Machine (JVM™ software).

Note –

Sun Java™ System Web Server and Sun Java™ System Application Server support multiple instances.

This section explains how to complete the following tasks:

ProcedureTo List Portal Server Instances

You can view a list of Portal Server instances that are already set up.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Click the name of Portal Server from the table.

  4. Select the Server Instances tab.

    The table displays all the instances of the Portal Server you selected.

Equivalent psadmin Command

psadmin list-portals

ProcedureTo Create a Portal Server Instance

Before You Begin

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select the name of a Portal Server.

  4. Select the Server Instances tab.

  5. Click on the New Instance button to launch the wizard.

  6. Provide the name of the portal identifier.

  7. Enter Web Container Information.

  8. (Optional) Change the default web container instance properties.

    For information, see Creating a Portal on the Same Node in Sun Java System Portal Server 7.1 Configuration Guide.

  9. Verify the information you supplied, and click Finish to create the new portal instance.

    A progress bar displays the status of this procedure. When the procedure is complete, a results page is provided.

  10. Click Finish to create your new portal instance.

Equivalent psadmin Command

psadmin create-instance

ProcedureTo Delete a Portal Server Instance

You can delete an instance of a Portal Server.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select the name of a Portal Server.

  4. Select the Server Instances tab.

  5. From the table, select the instance you want to remove.

  6. Click Delete Instance button.

Equivalent psadmin Command

psadmin delete-instance

Chapter 3 Managing Organizations, Roles, and Users

Portal Server administrators can provide and limit access to content on a portal through the definitions of the identities of specific end users. You can set up portal pages, attributes and access policies so that portal content is available to specific entities. These entities include the following:

To manage organizations, roles, and end-users, Portal Server administrators must use both the Portal Server management console and the Sun JavaTM System Access Manager console. This chapter explains how Portal Server administrators can do this using the Access Manager. This chapter provides the following topics:

Note –

This chapter explains how to use Access Manager that is installed and configured to support Legacy Mode. For information about Legacy Mode and Realm Mode, see the Sun Java System Access Manager Administration Guide

Understanding How to Use Access Manager With Portal Server

Portal Server uses Sun Java System Access Manager services to manage attributes that are specific to Portal Server end users and applications. You must use the Access Manager console to manage tasks related to identity.

To control who has access to a portal site, Portal Server administrators must use the following tools:

Portal Server administrators must use Access Manager to perform the following tasks:

Access Manager uses the lightweight directory access protocol (LDAP).

For information about Access Manager administration, see the Sun Java System Access Manager 7.1 Administration Guide.

Creating New Organizations for Portal Server

New organizations inherit services that are registered at the top-level Access Manager organization. Typical services that new organizations inherit include the following:

New organizations use LDAP authentication, and LDAP service settings are inherited from the corresponding global service.

For information about Access Manager administration, see the Sun Java System Access Manager 7.1 Administration Guide.

ProcedureTo Create a New Organization to Use with Portal Server

  1. Log in to the Access Manager console.

    For information about Access Manager administration, see the Sun Java System Access Manager Administration Guide.

  2. Under Identity Management, select Organizations from the View menu.

  3. Click New to create a new organization.

  4. Specify the organization attributes.

    For example:

    Name

    TestOrganization

    Organization Aliases

    TestOrganization

  5. Click OK.

ProcedureTo Access a New Organization

  1. Type this URL in your browser:

    http://host:port/amserver/UI/Login?org=organizationalias

    host

    The name of the system that the console is running on.

    port

    The console's port number assigned during installation.

    organizationalias

    The value assigned to the Organization Alias attribute field.

Adding Portal Services to Organizations

Before the Portal is accessible, you must add several services to an organization. The services that you must add to the organization include the following:

Optional services that you can add include the following:

Procedure To Add Portal Services to an Organization

Portal requires several services to be added to an organization before the Portal Server is accessible to the organization. After you add Portal services to the organization, use the Portal Server management console to administer Portal Server settings. [When a PortalID Desktop service is added to an organization or a role, it specifies default settings. It do not inherit the PortalID Desktop service settings from an organization or a role above it. You need to use the Portal Service management console to manage these service settings as per your need.]

  1. Log in to the Access Manager console.

    For information about Access Manager administration, see the Sun Java System Access Manager 7.1 Administration Guide.

  2. Under Identity Management, select Organizations from the View menu.

  3. Click your organization.

    For example: TestOrganization

  4. In the View menu for the organization, select Services.

  5. Click Add.

  6. Select the following services, if they are available in your deployment:

    • Mobile Application Configuration

      • Mobile Address Book

      • Mobile Calendar

      • Mobile Mail

    • Portal Server Configuration

      • portalID Desktop

      • portalID Subscriptions

      • SSO Adapter

    • Remote Portlets (WSRP)

      • portalID WSRP Consumer

    • Secure Remote Access Configuration

      • Access List

      • NetFile

      • Netlet

      • Proxylet

  7. Click OK.

ProcedureTo Specify Required Portal Services for New Users

After you add all of the Portal services to an organization, you must use the Access Manager console to add the services to newly created end-users so that they can access the Portal Desktop and whatever Portal services they need.

The Access Manager Administration service allows you to specify which services are dynamically added to end-user entries when they are created. If your Portal deployment allows users to be created, such as a "Sign-Me Up" feature, specify the Required Services setting in the Access Manager console for your organization.

Before You Begin

Add Portal services to the organization. See Adding Portal Services to Organizations.

  1. Log in to the Access Manager console.

    For information about Access Manager administration, see the Sun Java System Access Manager 7.1 Administration Guide.

  2. Add the Administration Service.

    1. Under Identity Management, select Organizations from the View menu.

    2. Click your organization.

      For example: TestOrganization

    3. In the View menu for the organization, select Services.

    4. Click Add.

    5. Select the Administration service and Click OK.

  3. Specify the setting for Administration Service Required Services.

    This setting specifies whether to assign all services in the required services list to a new end user.

    1. Select the Administration service setting.

    2. For the Required Services setting, specify the following services:

      • SunPortalportalIDDesktopService

      • SunPortalportalIDSubscriptionsService

      • SunMobileAppABService

      • SunMobileAppCalendarService

      • SunMobileAppMailService

      • SunSSOAdapterService

    3. Click Save.

  4. Log out of the Access Manager console.

Navigating to Specific Nodes

Portal Server uses Access Manager services to store application and user-specific attributes. To enable you to administer portal-related functions for an LDAP directory node (DN), the Portal Server management console provides details about the DN in a location bar, a horizontal strip below the row of tabs.

The location bar enables you to do the following:

A directory name can be a organization, role, or user name.

Understanding the Location Bar

The location bar provides the following functions:

ProcedureTo Set a New Directory Node

You can select a new DN without adding it to the location bar.

  1. Log in to the Portal Server management console.

  2. Select the Add button next to the location bar.

  3. Select the name of the DN using one of the following methods:

    • Select a DN listed in the window.

    • Use the Search utility:

      1. Type the search string.

        You can use wildcard characters.

        Search results are displayed by short name and corresponding directory node.

      2. Click the Search button.

  4. Click the Set Current DN button.

    The window closes, and the Selected DN field displays the new directory node. The directory node is not added to the location bar selections.

ProcedureTo Add a Directory Node to Location Bar Selections

When you add a directory node to the location bar menu, it is stored as a cookie so that the directory node is available in the same browser across sessions.

  1. Log in to the Portal Server management console.

  2. Select the name of the DN using one of the following methods:

    • Using the Add button:

      1. Click the Add button next to the Select DN menu.

        The Add to DNs List pop-up window opens and displays a list of available directory nodes.

      2. Select the desired DN.

    • Using the Search utility:

      1. Use the Search menu to select the object type.

      2. Type the Search string.

        You can use wildcard characters.

        Search results are displayed by short name and corresponding DN.

      3. Select the desired DN.

  3. Select the name of the directory node.

  4. (Optional) Edit the short name field to change the name that the directory node in the drop-down menu displays.

  5. Click the Add button.

    The directory node is added to the Select DN menu.

ProcedureTo Remove a Directory Node From Location Bar Selections

You can delete a directory node from the drop-down list displayed in the location bar. The directory node itself is not removed. To remove a directory name from the LDAP database, you must use Access Manager.

You cannot remove default organizations that were defined during installation.

  1. Log in to the Portal Server management console.

  2. From the Select DN drop-down menu, select the DN that you want to delete.

  3. Click the Delete button next to the Select DN drop-down menu button.

    The selected directory node is removed.

ProcedureTo Display Information for a Directory Node

  1. Log in to the Portal Server management console.

  2. Display information about a directory node using one of the following methods:

    • Type the name of the directory node in the Enter DN text box, and click the Go button.

    • Select the name of the directory node from the Select DN menu.

Chapter 4 Managing the Portal Server Desktop

This chapter describes the Sun JavaTM System Portal Server Desktop and how to manage it.

Understanding Portal Server Desktop Management

This section describes the key components of Portal Server desktop. The following topics are discussed:

Understanding the Display Profile

While installing Portal Server, you create an initial organization. The installer then imports the display profile global level document, and the default organization display profile, based on the input parameters you specify.

After that, each time you create a new organization, suborganization, or role, the display profile is not automatically loaded. However, the new organization, suborganization, or role inherits the display profile defined from its parent. If there are specific entries to the newly created organization, suborganization, or role, you must manually load the display profile.

The display profile creates the display configuration for the standard Desktop by defining the following three items:

Provider definition

Specifies the name and the Java class for the provider. A provider is a template used to generate content, which is displayed in the channel.

Channel definition

Specifies the run time configuration of an instance of the provider class. A channel is a unit of content, often arranged in rows and columns. You can also have channels of channels, called container channels.

Provider and channel property definitions

Specify the values for provider and channel properties. Properties defined in a provider usually specify default values for the channels that are derived from the provider. The display configurations for the channels include properties such as the title, description, channel width, and so on. The properties defined in the channel usually specify the specific value for that channel that is different from the default value.

Container properties define the display definition about how to display the contained channels in the container, including: the layout of the container (thin-wide, wide-thin, or thin-wide-thin); a list of the contained channels; the position of the channel (the row and column number); and the window state of the contained channels (minimized or detached).

The display profile exists only to provide property values for channels. It does not actually define the overall layout or organization of what users see on their Desktops. However, the display profile does indirectly control some aspects of channel presentation, such as column layout for a table container or how the table container draws channels in a table.

The system reports errors when you try to save a display profile document containing invalid XML. The error messages appear as a title, a message, and a sub-message. The title of the message box is “Invalid XML document.” The message appears as one of the following:

If you receive an “Invalid XML document” error, you must correct the error to be able to save the XML document.

The display document syntax is as follows:


<?xml version="1.0" encoding="utf-8" standalone="no"?>
<DOCTYPE DisplayProfile SYSTEM " jar://resources/psdp.dtd">

<DisplayProfile version="1.0" priority="xxx">
	<Properties>
	...
	</Properties>
	</Channels>
	...
	</Channels>
	<Providers>
	...
	</Providers>
</DisplayProfile>

Understanding Desktop Attributes

The Desktop merges all documents in a user's display profile merger set and uses the result to configure the user's desktop. A display profile merger set consists of all the display profile documents associated with a user. Display profiles are defined at different levels in the Portal Server organization tree. Display profile documents from the various levels of the tree are merged or combined to create the user's display profile.

For example, the user's display profile document is merged with the role display profile documents (if any), the organization's display profile document, and the global display profile document to form the user's display profile.

The Desktop display profile and other configuration data are defined as service attributes such as parent container, desktop type and edit container of the portal Desktop service under the Sun Java System Access Manager service management framework. When an organization adds for the Portal Desktop service from the Sun Java System Access Manager management console, all users within the organization inherit the Portal Desktop service attributes in their user profiles. These attributes are queried by the Portal Desktop to determine how information will be aggregated and presented in the Portal Desktop.

See Managing Desktop Attributes

Managing Portal Server Desktop Content

This section discusses how to manage the desktop content. For more information on the desktop, see Understanding the Standard Desktop in Sun Java System Portal Server 7 Technical Overview.

Administering Portlets

This section describes how to deploy and undeploy portlets, and how to modify portlet preferences.

Portlets are web applications that process requests and generate content within the context of a portal. Portlets are managed by the Portlet Container (an implementation of the Portlet Specification as defined by the JSR 168 Expert Group).

A portlet can only be deployed on a selected DN node once. If a portlet has already been deployed on the same DN node, you should undeploy the portlet and deploy it. If your require a portlet to be on multiple sub organizations or roles, then deploy the portlet on the portal global DN or the parent organization.

ProcedureTo Deploy a Portlet

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. From the Select DN drop-down menu, select any DN.

  5. Click Deploy Portlet to start the wizard.

    1. Ensure the selected portal and selected DN are the ones where you want to deploy the portlet, and click Next.

    2. Specify a portlet war file, the roles file, and the users file.

      Note –

      The roles file and the users files are optional. The war file, the roles file, and the users file can be located either on the local machine, or on the remote portal server system.

    3. Select the button for either the local system or the remote portal server system.

      • If the upload file is from the local machine, use the browse dialog box to select the file from the local machine.

      • If the upload file is from a remote portal server system, use the file chooser dialog to choose a file from the remote machine

    4. Verify the information provided, and click Next.

    5. An information page appears when the portlet is deployed.

  6. Follow the instructions to deploy a portlet.

Equivalent psadmin Command

psadmin deploy-portlet

ProcedureTo Undeploy a Portlet

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. From the Select DN drop-down menu, select any DN.

  5. Click Undeploy Portlet to launch the wizard.

  6. Modify the configuration attributes as necessary.

  7. Click Undeploy to record the changes.

Equivalent psadmin Command

psadmin undeploy-portlet

ProcedureTo Modify Portlet Preferences

  1. Log in to the Portal Server management console.

  2. Click the Common Tasks tab, then Manage Channel and Containers from the submenu.

  3. Select a portal and the DN where the portlet is deployed.

    The navigation tree with available channels and portlets is displayed.

  4. From the navigation tree on the left frame, select the portlet channel.

    The preferences table and properties table is displayed on the right frame.

  5. In the preferences table, click Edit Values link of a preference you want to modify.

  6. In the preferences wizard, type the new value in the text field, and click OK.

    • To remove a value, select the value from the list and click Remove.

  7. When you are done with modifying preferences, click Save.

  8. Click Close.

Managing Channels and Containers

This section describes how to manage portal server channels and containers from the management console.

The following topics are discussed:

Viewing Channels and Containers

The desktop for a user is rendered by starting a desktop parent container. You can customize the parent container attribute at every organization, role and user DNs. The content for a desktop at a particular DN is provided by iterating the child containers and channels that are selected to be displayed inside the desktop parent container.

Usually, the desktop parent container contains a few tab or table containers. Each tab container under the list of selected nodes of the parent container will display a tab on the user desktop. The channels that appear under the tab are the channels inside the tab container.

The bottom left frame of the Channels and Container Management in the portal management console has two components:

Items in the View Type menu and the nodes displayed in the tree are dependent on content of the merged Display Profile XML.

The tree contains container and channel nodes. There are three types of channels that deliver content to the desktop:

You can click on any of the node links in the tree to display properties and actions on the right frame.

There are two types of items in the View Type menu:

See To View Display Profile XML Tree and Desktop Views

Display Profile XML Tree

The tree displays a complete set of channels and containers in the merged Display Profile (DP) XML. The root element in the DP XML Tree is DP_ROOT, which is the parent of all the channels and containers of the display profile. You can create a channel directly under DP_ROOT, or in a container under DP_ROOT.

The nodes listed under the DP XML Tree is not always displayed on the desktop. Some nodes in the display profile are never referenced or included in the hierarchy of the desktop container.

For example, the desktop default container JSPTabContainer has two containers, tab1 and tab2. If tab1 contains ch1 and ch2, and tab2contains ch3 and ch4, then there are five channels defined in the DP XML Tree. The DP XML Tree references ch1 to ch4 in the container hierarchy, but ch5 is not. So, only ch1 to ch4 will display on the desktop.

Desktop Views

Desktop views are top level containers available in the merged display profile. You can set each desktop views as the parent container for the desktop at the DN. When you select a desktop view, the tree provides a visual hierarchy of the channels and containers that has a role in rendering content to the desktop.

Channels and containers displayed under the desktop views have two states:

You can change the state of channels and containers in a desktop view by clicking the task link on the right frame. To display a tool tip about the state, place the mouse over a container or channel icon. The tool tip also displays the fully qualified name of the node.

ProcedureTo View Display Profile XML Tree and Desktop Views

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server under Portals, then any DN from the Select DN drop-down menu.

    • You can also select the organization from Select DN menu in the Manage Containers and Channels page.

  4. Under Tasks, click Manage Containers and Channels.

  5. From the View Type drop-down menu select DP XML Tree or a Desktop View.

Modifying Channels and Container Properties

This section discusses the properties of channels and containers, and how to modify them.

You can perform the following tasks:

Understanding Properties

The properties displayed when you click on the node in the tree are top level properties or channel level properties. These properties are defined at the provider level and you can customize these properties for a channel. However, new properties added to a channel cannot be added to the provider. This is the reason you cannot add new properties at the channel level.

The properties table displays client type and locale. There is no column to show the type of the property, however, the following convention is followed:

String

Value column has a wide text field for a maximum of 30 characters.

Integer

Value column has a narrow text field for a maximum of 5 characters.

Boolean

Value is a radio button.

Map

Name is a link.

List

Value column has an Edit Values link. Clicking this link opens a wizard to add and remove values.

Empty Collection

The name is a link showing Edit Values link. Name and value pairs may be added to an empty collection to behave like a map, and the Edit Values disappears. If values are added to an empty collection using Edit Values wizard, the collection behaves as a List and the name link disappears.

In addition to the Name and Value columns, the properties table has two more columns:

Category

Displays if the property is advanced or basic. The advanced properties generally are for experienced administrators.

State

Any property may be in three possible states:

  • Default – Value assigned at the provider.

  • Inherited – Values modified at some level above. For example, if the current node is a role, then the property may have been customized at the organization of the role. This organization may be the parent organization, or parent of the parent organization. When the property is inherited it is a link. Clicking this link shows all the possible parent nodes in the hierarchy from where this property was inherited from.

  • Customized – Value defined at this node.

There are buttons in the properties table:

Remove Customization

Removes values defined at this node from the display profile. This may result in properties to be inherited from some parent in the hierarchy if the properties are customized there. If the value has not been customized anywhere in the hierarchy, the value defined at the provider is displayed and the state will show as Default.

Save

Saves additions, deletions, and changes of value.

Reset

Ignores changes and resets values to last saved state from the data store.

Clear All Sorts

Clears all sorts.

Tip –

Table may be sorted by clicking on any column title. When you click the Name button first to sort by name, a + appears next to the Category and State buttons. Click the + to apply the next sort criteria.

Table Preferences

Sets the table preferences.

Unless modified, the client type and locale are set to default.

ProcedureTo Create a Property

From the New Property wizard you can edit the values and save. You can also add new name and value pairs.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal from Portals.

  4. From Select DN drop-down menu, select any DN.

  5. Under Task, click Manage Channels and Containers.

  6. Select a container in the tree on left frame to display Edit Properties page on the right frame.

  7. Click Table Preferences button to set the client and locale attributes.

  8. Click the New Property button to launch the wizard.

  9. Select the property type, and click Next.

  10. Type a Name, select a Value, and specify if the property is advanced or not.

    Note –

    Collection property behaves like a map when it contains name and value pairs. Property of type Collection can be nested. The property path above the table will change to display the current nesting and you can navigate back.

    Any trailing values are optional. For example, the value may be en or en_US, but cannot be US only. The standard Java format for specifying a locale is followed.

  11. Click Finish to create the property.

  12. Click Close to display the new property in the table.

ProcedureTo Edit a List

Collection property behaves like a List when it contains only values.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal from Portals.

  4. From Select DN drop-down menu, select any DN.

  5. Under Task, click Manage Channels and Containers.

  6. Select a container in the tree on left frame to display Edit Properties page on the right frame.

  7. Click the Edit Values link of a property to launch the wizard.

  8. Make your changes.

    • To add a value, type the name of the value in the New Value text box, and click Add.

    • To delete a value, select a value from the Values list, and click Remove.

  9. Click Close.

    The edit properties page will update number of values in the list.

ProcedureTo Modify Channel and Container Properties

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal from Portals.

  4. From Select DN drop-down menu, select any DN.

  5. Under Task, click Manage Channels and Containers.

  6. Select a channel or container in the tree on left frame to display Edit Properties page on the right frame.

  7. Change the properties, and click Save.

Equivalent psadmin Command

psadmin modify-dp

Creating and Deleting Channels and Containers

This section discusses how to create and delete channels and containers from the portal management console.

ProcedureTo Create a Channel or Container

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal from Portals.

  4. From Select DN drop-down menu, select any DN.

  5. Under Task, click Manage Channels and Containers.

  6. Select a container in the tree on left frame to display Edit Properties page on the right frame.

  7. Under Tasks, click New Channel or Container to launch the wizard.

    In the wizard, ensure that the selected portal and selected DN is where you want to create the channel or container and click Next.

  8. Create a container or channel from the wizard.

    • To create a container, perform the following steps:

      1. Select a provider from the Container Provider drop-down menu, and click Next.

      2. Type a name in the Channel or Container Name text field, and click Next.

      3. Review your selections, and click Finish.

        A message confirms the creation of the container.

      4. Click Close

    • To create a channel, perform the following steps:

      1. Select a channel type.

        Select a channel from the following three types:

        • If you select Provider Channel, a list of provider channels are displayed.

        • If you select JSR 168 Portlet Channel, a list of portlet channels are displayed.

        • If you select WSRP Remote Portlet Channel, select the registered producer and the remote portlet from the drop-down menu.

      2. Type a name in the Channel or Container Name text field, and click Next.

      3. Review your selections, and click Finish.

        A message confirms the creation of the channel.

      4. Click Close.

Equivalent psadmin Command

psadmin add-dp

ProcedureTo Delete a Channel or Container

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal from Portals.

  4. From Select DN drop-down menu, select any DN.

  5. Under Tasks, click Manage Channels and Containers.

  6. Select a container in the tree on left frame to display Edit Properties page on the right frame.

  7. Under Tasks, click Select Channels or Containers to Delete.

  8. Under Type, select Channel or Container.

    Available channels and containers are displayed.

  9. Select a channel or container, and click Delete.

Equivalent psadmin Command

psadmin remove-dp

Creating a Tab

This section describes how to create a tab form the portal server management console.

ProcedureTo Create a Tab

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal from Portals.

  4. From Select DN drop-down menu, select ay DN.

  5. Under Tasks, click Manage Channels and Containers.

  6. From the tree on the left frame, select JSPTabContainer.

  7. Under Tasks in the right frame, click New Tab to launch the wizard.

Displaying Channels and Containers

This section discusses how to display channels and containers on the end-user Desktop. Channels and containers can also be made available on the content page so that the end user can select them to display on the Desktop.

ProcedureTo Display Channels and Containers on Desktop

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal from Portals.

  4. Under Tasks, click Manage Containers and Channels.

  5. Select a container in the tree on left frame to display Edit Properties page on the right frame.

  6. Under Tasks, click Show or Hide Channels and Containers on Portal Desktop.

  7. Under Ready For Use, select a channel or container.

  8. Using the Add button, move the channels to appear on the Content Page or Portal Desktop.

    • Using the Remove button, you can move the channels or containers back to Ready For Use.

  9. Click Save.

Equivalent psadmin Command

psadmin modify-dp.

Managing Desktop Attributes

This section discusses how to manage Desktop attributes. For more information, see Understanding Desktop Attributes.

Desktop attributes for the top level organization is different from different levels of the organization tree. You can change the location bar to TopLevel to see global Desktop attributes, and then select other distinguished names for organization or role Desktop attributes.

ProcedureTo Set Up Desktop Attributes

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server under Portals, then Desktop.

  4. From the Select DN drop-down menu, select any DN.

  5. Modify the configuration attributes as necessary under Desktop Attributes.

    The following options are available:

    COS Priority

    Sets the conflict resolution level for the Desktop service template used to resolve conflicts when multiple Desktop templates are merged. This attribute applies only to Organizations and Roles and doesn't apply to Users and Global DN.

    Parent Container

    Identifies which default container is rendered when the Desktop is called with an unspecified provider. The value for the Parent Container can be one of the containers which is defined as a TopLevelContainer that can draw a header and footer on the portal page. A container is a Top Level container if the display profile property TopLevel is set to true.

    Edit Container

    Specifies which default edit container to use to wrap the content when one is not specified in the URL. This container will be used by the parent container to draw the edit pages when the edit link is clicked on the channel title bar.

    Desktop Type

    The comma separated list used by the Desktop lookup operation when searching for templates and JSPs. The lookup starts at the first element in the list and each element represents a sub directory under the Desktop template base directory. e.g., "sampleportal,foo" in which case the lookup would be sampleportal directory, foo directory, default directory in that order.

    Desktop Attributes

    Specifies whether the Desktop attributes are displayed to the users associated with the role. This dynamic attribute is mainly used for role-based delegated administration in administration tag library. This attribute enabled to show, allows the delegated administrators to administer channels/containers inherited from the parent organizations. This attribute applies only to Organizations and Roles.

    Display Profile Priority

    Sets the priority of the display profile document. Display profile documents are merged from low priority to high priority. A lower number represents a lower priority. For example, a 1 is a lower priority than a 2. High priority documents override values set in lower priority documents using merge semantics (unless a lower priority document has locked the object for merging).

    Note –

    The display profile priority is not stored as Desktop service attribute.

    The following attributes apply only to Global (top level) DN.

    XML Parsing Validation

    Enables the validation for XML parsing.

    Federation

    Enables Identity Federation so that a user can associate, connect or bind multiple internet service providers, local identities, enabling them to have one network identity.

    Hosted Provider ID

    Specifies the unique identifier of the host that provides the network identity of a user.

    Session Reap Interval

    Specifies the session reap interval in seconds.

    Session Idle Time

    Specifies the idle time in seconds after which the session is terminated.

    Maximum Number of Client Sessions

    Specifies the maximum number of client sessions allowed at any given time.

    Anonymous Desktop

    When enabled, allows anonymous Desktop for the selected portal.

    Anonymous Access for Federated Users

    Prevents users with a network identity on a hosted provided to access the portal Desktop by providing a user name and password.

    Valid UIDs for Anonymous Desktop

    List of User IDs authorized to access the Desktop without authenticating.

  6. Click Save to record the changes.

    Otherwise, click Reset to undo any edits.

    Note –

    To modify global attributes, Change the DN in the location bar drop-down to TopLevel.

Equivalent psadmin Command

psadmin undeploy-portlet

Administering the Display Profile

This section describes how to manage the Sun Java System Portal Server display profile. For more information, see Understanding the Display Profile.

You can perform the following tasks from the portal management console:

ProcedureTo Download a Display Profile

You can download the display profile to a file.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. From Select DN drop-down menu, select any DN.

  5. Click Download Display Profile under Tasks.

    The browser's download window pops up.

  6. Select a location and Click Save.

    Note –

    This step may vary from browser to browser.

For equivalent psadmin Command

psadmin get-attribute

ProcedureTo Upload a Display Profile

You can upload the display profile to a file.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. From Select DN drop-down menu, select any DN.

  5. Click Upload Display Profile under Tasks.

  6. Choose a display profile file to upload using the Browse button.

    Note –

    The file should be located on local machine based on the user's browser settings.

  7. Click Upload.

Equivalent psadmin Command

psadmin modify-dp.

ProcedureTo Remove a Display Profile

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. From Select DN drop-down menu, select any DN.

  5. Click Remove Display Profile under Tasks.

  6. Click OK in the warning dialog box to confirm deletion.

Equivalent psadmin Command

psadmin remove-dp

Chapter 5 Web Services for Remote Portlets

Sun JavaTM System Portal Server supports Web Services for Remote Portlets (WSRP). This chapter presents guidelines and best practices for using WSRP. This chapter contains the following sections:

Understanding the WSRP Standard

WSRP 1.0 is an OASIS standard that simplifies integration of remote applications and content into portals. The WSRP standard defines presentation-oriented, interactive web services with a common, well-defined interface and protocol for processing user interactions and for providing presentation fragments suited for mediation and aggregation by portals as well as conventions for publishing, finding and binding such services.

Because the WSRP interfaces are common and well-defined, all web services that implement the WSRP standard plug into all WSRP compliant portals – a single, service-independent adapter on the portal side is sufficient to integrate any WSRP service. As a result, WSRP is the means for content and application providers to provide their services to organizations running portals with no programming effort required.

See the WSRP 1.0 standard for more information:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp

The implementation of the WSRP 1.0 standard in Portal Server includes both the WSRP consumer and the WSRP producer. The WSRP producer implementation supports publishing JSR 168 portlets for use by a remote WSRP consumer. The JSR 168 portlets are deployed locally on a portal server. These portlets can be published by an instance of the WSRP producer.

Another portal server, through its WSRP consumer, can subscribe to these remote portlets. While local portlets can be expected to provide a large part of the base functionality for portals, remote portlets allow the potential to bind to a variety of remote portlets without installation effort or code running locally on the consuming portal server.

Administering the Producer

This section discusses the following topics:

Create a producer if you want to offer locally deployed portlets remotely to other portals that act as WSRP consumers. A portal can host multiple producers. The consumer can import remote portlets offered by a producer. Based on the portlets that you want to provide to WSRP consumers, you may create one or more producers. A producer can support registration or it does not require registration. If a producer supports registration, then consumers must register to work with the producer.

Creating a Producer That Supports Registration

Registration is used to build a technical or business relationship between the consumer and the producer. While creating a producer, you can define any one of the following registration mechanisms: in-band registration or out-of-band registration:

If the producer requires registration and enabled in-band registration: the consumer can provide the details through WSRP interface and register with the producer. Consumer is also provided an option to register through out-of-band communication. That is, consumer can provide the registration handle obtained through out-of-band communication.

If the producer requires registration and enabled out-of-band registration: the consumer should obtain the registration handle through out-of-band communication and provide the registration handle during registration. Out-of-band registration happens with manual intervention such as phone calls, email, and so on. For a producer that supports out-of-band registration, the producer gets the details about the consumer through out-of-band communication, and it creates a registration handle for the consumer. The registration handle is communicated to the consumer through out-of-band communication.

ProcedureTo Create a Producer That Supports Registration

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click the WSRP tab.

  5. From the Select DN drop-down menu select any DN, and click the Producer tab.

    The WSRP Producers table displays all producers that are created.

    Note –

    Organizations are created in Sun Java System Identity Server. Select the DN of an organization or suborganization based on the availability of portlets.

  6. Click New to create a new producer.

  7. Type the name to identify the producer.

  8. Select Required for Registration.

  9. Select Supported for Inband Registration

  10. To add a registration property, click Add Row. Enter the values. Enter the name of the registration property and description.

    Note –

    Registration properties are the details that you want to get from the consumer while the consumer registers to a specific producer. The registration properties entered by the consumer can be validated through the Registration Validation class.

  11. Select Supported for out-of-band Registration if you wish the consumer to provide the details through out-of-band communication, such as phone calls, email, and so on.

  12. Click Next.

    The Review screen displays the details that you entered. Review details. You can click Previous and change the details you entered.

  13. Click Finish.

Equivalent psadmin Command

psadmin create-producer

Creating a Producer That Does Not Support Registration

For a producer that does not require registration, consumer is not required to enter any information or get any information through out-of-band communication. In this case, the consumer can not customize (or edit) the portlets offered by the producer. The producer that does not support registration provides Read-Only portals to the consumers.

ProcedureTo Create a Producer That Does Not Support Registration

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click the WSRP tab.

  5. Select DN.

    The Configured Producers table displays all producers that are already configured.

  6. Click New.

  7. Type the name of the producer.

  8. Select Registration not required.

  9. Click Finish.

Equivalent psadmin Command

psadmin create-producer

Enabling and Editing WSRP Producer Properties

A producer can be disabled. But, all the consumers registered with the disabled producer will not be able to access the portlets offered by the producer.

ProcedureTo Enable and Edit the Producer's Properties

  1. In the Producer tab, click the producer name link.

    The Edit Properties screen appears. The screen displays WSDL (Web Services Definition Language) URL. WSDL URL is a unique URL for a specific producer through which the consumer accesses the producer.

  2. Add one or more published portlets to the producer.

    Note –

    The producer must have at least one published portlet to enable it. The screen displays all published portlets associated with the portal in which the producer is created.

  3. Select a portlet, and click Add.

  4. Edit the Registration Validation Class field if required.

    Registration Validator is used to validate the registration properties that are entered by the consumer. You can also customize this class based on the needs.

  5. Click Save. Now, the Enable check box displayed in the screen can be edited. Select Enable and click Save.

    Note –

    You can also edit other properties of the producer.

Equivalent psadmin Command

psadmin set-attribute

Customizing Registration Validation Class

You can customize the RegistrationValidator class. Using this class, you can process the registration properties. For example, verifying the zip code of the customer. RegistrationValidator is the SPI for registration validation in the WSRP producer. For more information on customizing the validation class, see http://portal/portal/javadocs/. You can also refer to WSRP: Validating Registration Data in Sun Java System Portal Server 7.2 Developer’s Guide.

Generating a Registration Handle

For a producer that supports registration, a registration handle needs to be generated for a specific consumer. After generating the registration handle, it needs to be communicated to the consumer to register with the producer through out-of-band communication. Consumer needs to enter the registration handle, while registering with the producer.

ProcedureTo Generate a Registration Handle

  1. Click the Consumer Registration tab.

    The screen displays all consumers that are already registered to the specific producer.

  2. Click New.

  3. Type details, such as name, status, consumer agent, and method.

    Consumer name

    A unique name to identify the consumer.

    Status

    Can be Enabled or Disabled.

    Consumer Agent

    Specifies the name and version of the consumer's vendor. Consumer Agent Name should be ProductName.MajorVersion.MinorVersion, where ProductName identifies the product the consumer installed for its deployment, and majorVersion and minorVersion are vendor-defined indications of the version of its product. This string can then contain any additional characters/words the product or consumer wishes to supply.

    Method

    Specifies whether the Consumer has implemented portlet URLs in a manner that supports HTML markup containing forms with method, get.

  4. Click Next.

    The screen displays the registration property values that are specified while creating the producer.

  5. Enter the values, and click Next. Click Finish.

Administering the Consumer

This section explains the activities need to be performed at the consumer side.

The following topics are discussed:

Adding a Configured Producer

To communicate with the portlets offered by the producer, a consumer needs to add a configured producer. If a producer requires registration, add a configured producer using the following methods:

If the producer does not require registration, the consumer is not required to enter any details while adding a configured producer.

ProcedureTo Add a Configured Producer

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click the WSRP tab.

  5. Select any DN and click New.

  6. Type the configured producer name. Select the identity propagation mechanism. By default, None is selected.

    Note –

    Identity propagation mechanism allows the users of the consumer portal to present their credentials to the producer portal. It is a mechanism by which users can federate their identity from consumer portal to the producer portal.

  7. Type the WSDL URL, and click Next.

  8. If the producer requires registration, you can register the producer in two methods: by entering the registration property values (in-band registration) or entering the registration handle (out-of-band registration). Click Next.

  9. If you selected the first method in step 7, enter the registration properties and click Next. If you selected the second method, enter the registration handle obtained through out-of-band communication, and click Next.

  10. Review the details and click Finish.

Equivalent psadmin Command

psadmin create-configured-producer

Identity Propagation Mechanism

Identity propagation is a mechanism by which the WSRP consumer supplies the identity of the user to the WSRP producer web service. It is a federation mechanism where the user federates its identity between the consumer and producer. After a successful federation, the consumer portal propagates the user identity to the producer portal. The WSRP producer, after receiving the user credentials from the consumer, validates the credentials and allows or denies access to the resource in the specified user context.

The user has two identities for each portal. That is, one for producer portal and the other for consumer portal. The user federates these identities using the identity propagation mechanism provided. This provides a single-sign on mechanism for the consumer and the producer portal. When the user logs into the portal through the consumer portal, the user gets the content that the user gets when logs directly into the producer portal. The changes that the user makes using the federated identity would be available when the user logs into the producer portal.

Sun Java System WSRP producer supports the following identity propagations:

In the above list, the last three options implement the OASIS WSS Username token profile specification. This specification describes how to use the Username Token with the Web Services. WSS specification describes how a web service consumer can supply a Username Token by identifying the requestor by username, and optionally using a password to authenticate that identity to the web service producer.

Note –

Many portal vendors support and implement the OASIS WSS Username token profile specification. Use one of the three options when interoperability is required.

There are two levels of identity propagation mechanism in Portal Server. First, the administrator of the consumer portal discovers that the producer portal supports one of the above specified identity propagation mechanisms. The administrator may allow the users to send their identity. Portal Server consumer supports all the above mentioned Identity Propagation Mechanisms.

After the consumer is created, the administrator has to create remote channels based on the identity propagation mechanism supported by the consumer. After the channels are available on the user Desktop, they are ready to accept identity propagation.

The identity propagation mechanism is set at the producer automatically. checks for authentication from Sun SSO, then OASIS user name token profile, and then the No Identity Propagation mode.

Configuring Digest Passwords

Only new users can use the Digest Password facility after running the configuration command to store the LDAP passwords in plain text

Creation of a consumer should involve selecting the WSSO Username Token Profile (with Digest Password) option for User Identity Propagation Mechanism.

The Web Services SSO Portlet must be edited to select the appropriate Web service URL (producer) and provide the new username and password.

ProcedureTo Configure the Accept Digest Passwords

Do the following to configure Sun Java System WSRP Producer to accept Digest Passwords.

  1. Run the command /opt/SUNWdsee/ds6/bin/dscfg set-server-prop pwd-storage-scheme:CLEAR to change the password storage scheme of the Directory Server so that plain text passwords are stored.

    Note –

    It is assumed that the default installed location of the Directory Server is /opt/SUNWdsee.

  2. Create a new user in the AM console, to ensure that the Username Token Profile with Password Digest can be used.

Recommendations

Creating User Token Profiles Using WebServices SSO Portlet

You can create user token profiles to authenticate user credentials if the user uses identity propagation mechanism. You can define the user name and password for specific Web service that the producer offers.

ProcedureTo Provide User Credentials Using WebServices SSO Portlet

  1. Log in to Portal Server Desktop.

  2. In the WebServices SSO Portlet, click the Edit button.

  3. In the Create NewToken Profile section, select the WebService URL for which you want to create a user token profile.

  4. Type the user name and password. Click Add.

    You can also edit or remove an existing user token profile.

Updating Service Description

After the consumer configures the producer, use the Update Service Description option to update any changes made to the producer later. For example, addition of new portlets or changes to the registration properties after the registration.

ProcedureTo Update Service Description

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click the WSRP tab.

  5. Select DN (Distinguished Name).

  6. Click the configured producer link.

  7. In the Edit Configured Producer screen, click Update Service Description.

Equivalent psadmin Command

psadmin update-configured-producer-service-description

Mapping User Categories to Roles

WSRP supports the concept of user categories, which are included in the service description of the producer. Mapping user categories to the roles allows the user to map the roles that are defined in the consumer portal to the roles that are defined in the portlet. Sun Java System Portal Server maps Java System Access Manager's roles to the portlet's roles. These roles can be mapped to the corresponding WSRP user categories.

You can perform the following tasks:

Roles can be defined in the portlet while deploying the portlet.

Note –

The roles defined in the portlet must exist in the Access Manger of the producer.

ProcedureTo Create Roles in Portlets

The following task creates a role in amconsole in Sun Java System Access Manager and Portlets.

  1. Log in to the Access Manager console.

  2. Create a role and add a user to it.

  3. In webxml of the portlet application, add the following code:

    <security-role>

    <role-name>PS_TEST_DEVELOPER_ROLE<role-name>

    </security-role>

  4. Add the following lines in portlet.xml of the portal.

    <security-role-ref>

    <role-name>PS_TEST_DEVELOPER_ROLE<role-name>

    <role-link>PS_TEST_DEVELOPER_ROLE<role-link>

    </security-role-ref>

  5. Create the portlet application war file.

  6. Create a roles file with the following entry.

    cn\=AM_TEST_DEVELOPER_ROLE,o\=DeveloperSample,dc\=india,dc\=sun,dc\=com=PS_TEST_DEVELOPER_ROLE

  7. Deploy the portlet using the following command.

    /opt/SUNWportal/bin/psadmin deploy-portlet -u amadmin -f ps_password -d "o=DeveloperSample,dc=india,dc=sun,dc=com"-p portal1 -i stockprice-8080 --rolesfile rolesfile TestPortlet.war

Equivalent psadmin Command

psadmin deploy-portlet

ProcedureTo Map User Categories to Role

Do the following to map user categories to role:

  1. In the Consumer tab, click the producer name link.

    The Edit Configured Producer screen displays the following: User Category: The roles in the producer portlet. Local Roles: The roles that are defined at the consumer's Sun Java System Access Manager.

  2. In the User Categories to Role Mapping section, map user categories to the roles defined at the consumer, and click OK.

Mapping Consumer Attributes

The Sun Java System Portal Server implementation of WSRP Consumer maps common user attributes stored in the user entry on the Sun Java System Directory Server to the standard set of user attributes that the WSRP specification mandates.

If a consumer portlet uses any of the attributes that are not specified in the LDAP schema, create a custom object class to store these attributes and add this object class to the user entry. After attributes are created, map the LDAP attribute to the corresponding WSRP attribute using Sun Java System Access Manager management console.

Configuring Proxies

Proxies need to be configured for consumer and for web container XML files.

You can perform the following tasks:

ProcedureTo Configure Proxy for Consumers in Common Agent Container

  1. Run ./cacaoadm get-param java-flags.

  2. Copy the values and paste it to ./cacaoadm set-param java-flags.

  3. Now add the following to the command: -Dhttp.proxyHost=webcache.canada.sun.com -Dhttp.proxyPort=8080 -Dhttp.proxyUser=Proxyuser -Dhttp.proxyPassword=Password

  4. Press Enter.

  5. Restart the common agent container server.

ProcedureTo Configure Web Container XML file

  1. Edit the following file:

    vi /var/opt/SUNWappserver/domains/domain1/config/domain.xml

  2. Set the following JVM options:

    • Dhttp.proxyHost

    • Dhttp.proxyPort

    • Dhttp.proxyUser

    • Dhttp.proxyPassword

Administering the WSRP Producer

This section describes how to administer the Sun Java System Portal Server Web Services for Remote Portlets (WSRP) service. The tasks to administer a WSRP producer are:

ProcedureTo Create a WSRP Producer

A WSRP producer is created with the following:

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click WSRP, then Producers from the submenu.

  5. From Select DN drop-down menu choose any DN.

  6. From WSRP Producers click New to launch the wizard

  7. Follow the instructions to create the specified producer.

    For more information about the attributes, see Sun Java System Portal Server 7.2 Technical Reference

Equivalent psadmin Command

psadmin create-producer

ProcedureTo Edit a WSRP Producer

You can edit the WSRP Producer as follows:

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click WSRP, then Producers from the submenu.

  5. From Select DN drop-down menu choose any DN.

  6. Select a WSRP producer and modify the configuration attributes as necessary

    For more information about the attributes, see Sun Java System Portal Server 7.2 Technical Reference

  7. Click Save to record the changes.

Equivalent psadmin Command

psadmin set-attribute

ProcedureTo Create a Consumer Registration

Each consumer registration represents a remote WSRP consumer that has established a relationship with the WSRP producer. A WSRP producer that supports allows multiple WSRP consumers to register with it. The registration mechanism allows a WSRP consumer to describe its capabilities to a WSRP producer.

A WSRP consumer is added out of band (such as by email or telephone). The information entered when adding a consumer registration must match the capabilities of the WSRP consumer that is given the registration handle. Consumer registrations allow a WSRP producer to scope artifacts (such as portlet preferences) that a WSRP consumer creates on the WSRP producer.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click WSRP, then Producers from the submenu.

  5. From Select DN drop-down menu choose any DN.

  6. Select a WSRP producer, then Consumer Registrations.

  7. Click New to launch the wizard.

  8. Follow the instructions to create the specified consumer registration.

    For more information about the attributes, see Sun Java System Portal Server 7.2 Technical Reference

Equivalent psadmin Command

psadmin create-consumer-registration

ProcedureTo Edit a Consumer Registration

You can edit existing consumer registrations manually. Note that this could also be done via in-band registration from the WSRP Consumer end. Ensure that both out of band and in band registration are not used simultaneously.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click WSRP, then Producers from the submenu.

  5. From Select DN drop-down menu choose any DN.

  6. Select producers, then select a WSRP producer, then Consumer Registrations.

  7. Select a consumer registration and modify the configuration attributes as necessary.

    For more information about the attributes, see Sun Java System Portal Server 7.1 Technical Reference

  8. Click Save to record the changes.

Administering the WSRP Consumer

This section describes the tasks to administer the WSRP Consumer:

ProcedureTo Add a Configured Producer

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click WSRP, then Producers from the submenu.

  5. From Select DN drop-down menu choose any DN.

  6. Under Configured Producer click New to launch the wizard.

  7. Follow the instructions to create the specified configured producer.

    For more information about the attributes, see Sun Java System Portal Server 7.1 Technical Reference

Equivalent psadmin Command

psadmin create-configured-producer

ProcedureTo Edit a Configured Producer

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click WSRP, then Consumer from the submenu.

  5. From Select DN drop-down menu choose any DN.

  6. Select a configured producer and modify the configuration attributes as necessary.

    Note –

    Use the Update Service Description option to update any changes made to the producer. See Updating Service Description.

    For more information about the attributes, see Sun Java System Portal Server 7.1 Technical Reference

  7. Click Save to record the changes.

Equivalent psadmin Command

psadmin set-attribute

ProcedureTo Specify the Consumer Name

The WSRP consumer sends the consumer name to producers during registration. The value specified for the consumer name is used as the default unless a value is specified for consumer name at the organization or suborganization level.

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server from Portals.

  4. Click WSRP, then Consumer from the submenu.

  5. From Select DN drop-down menu choose any DN.

  6. Under WSRP Consumer, click Edit.

  7. Specify the consumer name.

  8. Click OK.

Equivalent psadmin Command

psadmin set-attribute

ProcedureTo Troubleshoot WSRP Channels

If you cannot access WSRP channels, check whether the Derby is up and running. If Derby is not running, restart it. If you cannot access WSRP channels even after restarting the Derby, follow the below procedure to access WSRP channels.

  1. Login to the Application Server Administration Console.

  2. Click Resources in the left pane.

  3. Navigate to JDBC and click Connection Pools.

  4. Click WSRPDataSourcePool.

    The Edit Connection Pool page appears on the right pane.

  5. Enable Connection validation by selecting Required, and click Save.

  6. Refresh the Portal desktop to view WSRP channels.

Chapter 6 Managing Portal Server End-User Behavior Tracking

This chapter describes how to track Sun JavaTM System Portal Server 7.2 user behavior.

This chapter contains the following sections:

Understanding Portal Server User Behavior Tracking

Portal Server user behavior tracking (UBT) provides a way to track end-user activity on the Portal Server application. User activity on Portal Desktop is captured into a ubt log file. The ubt log file is recorded in a W3C standard Extended Log File Format. From this log file, you can create various end-user behavior tracking reports using the Portal Server console or the psadmin generate-ubt-report command. You can also use third-party tools such asAWStats to generate UBT reports.

You can also enable UBT from the UBTConfig.properties file. Go to /var/opt/SUNWportal/portals/portalID/config/UBTConfig.properties and set com.sun.portal.ubt.enable=true.

The table shows the list of UBT reports, their description, and the available format of the reports.

Table 6–1 User Behavior Tracking Reports

Report Name 

Report Description 

Report Formats 

Portal User Identity Report 

This report lists users along with time of their last portal access. Users are grouped as per the server they accessed, domain they belong to, and relative DN. 

HTML or PDF 

Portal User Login Rate 

This report shows the rate of logins into portal. 

 

Portal Channel View Report 

This report lists users viewing a channel along with number of times they viewed that channel. The channels are grouped as per the containers they belong to. 

HTML or PDF 

User Customization of Portal Containers 

This report shows the portal container customization. Container customization usually refers to content, layout or theme changes on the Desktop. 

HTML or PDF 

Portal Request Rate 

This report shows the rate of request of each top container every hour over a period of time. The top container request is considered a page request. 

HTML or PDF 

User Customization of Portal Channels 

This report lists end users along with the actions they performed on the channels. Users are grouped by the containers they access, and by channels on which they performed actions. 

HTML or PDF 

Portlet Actions Report 

This report shows the rate of portlet action requests in the portal. 

HTML or PDF 

Portlet Render Report 

This report shows the number of times a portlet is displayed in a portlet mode in a particular window state. In MINIMIZED window state, a portlet is not rendered, and the count for this state is not displayed. 

HTML or PDF 

Portal User Login Rate Report 

This report shows the rate of logins into the portal. 

HTML or PDF 

Setting Up Portal Server User Behavior Tracking

This section has information on how to enable user behavior tracking and generate reports.

You can perform the following tasks from the portal server management console:

ProcedureTo Enable the User Behavior Tracking Logging

By default, UBT logging on a Portal Server application is not enabled.

  1. Log in to the Portal Server management console.

  2. Select the Common Tasks tab.

  3. Under Reports and Logs, click Portal Usage Reports to launch the wizard.

  4. From Select Portal drop-down menu select a portal instance, and click OK.

    The User Behavior Tracking page is displayed.

  5. Click the Settings submenu and enable UBT logging under Common Properties.

    For more information on Common Properties, Handler Properties and Event Settings, see Sun Java System Portal Server 7.2 Technical Reference

    Note –

    For all other properties, default values are already set and are sufficient for UBT to work. To apply the changes to all instances of Portal Server, click the Apply to All Instances button. Otherwise, click the Apply to Selected Instance button.

  6. Access the portal Desktop and make sure user behavior tracking log files are generated.

    By default, user behavior tracking logs are written into /PortalData-Dir/portals/PortalID/logs/instanceID/ubt.0.0.log file.

ProcedureTo Generate User Behavior Tracking Reports

  1. Log in to the Portal Server management console.

  2. Select the Common Tasks tab.

  3. Under Reports and Logs, click Portal Usage Reports to launch the wizard.

  4. From Select Portal drop-down menu select a portal instance, and click OK.

    The User Behavior Tracking page is displayed.

  5. Click the Reports submenu.

    Eight reports are listed. All these reports can be generated either in PDF or HTML format. See Table 6–1 for more information.

Equivalent psadmin Command

psadmin generate-ubt-report

Chapter 7 Monitoring Portal Server Activity

This chapter describes how to set up the Sun JavaTM System Portal Server monitoring.

This Chapter contains the following sections:

Understanding Portal Server Monitoring

Monitoring helps record runtime resource information about portal server. Desktop monitoring keeps record of information on requests received by portal server for content, edit, and process types. It also records information on the minimum, maximum and average response time for each type of request for the different channels of portal server.

Information gathered from monitoring portal activity is useful to optimize portal response time either by moving channels that need a higher response time to separate secondary tab, or by setting the time-out property for Desktop channels based on cache hits.

The Java Virtual Machine (JVM) in a portal server collects monitoring data for the Desktop. Monitoring information can be viewed on portal server management console, or can be accessed using psadmin monitoring subcommands. See Sun Java System Portal Server 7.1 Command Line Reference.

Monitoring uses Java Management Extensions (JMXTM technology) and registers Management Beans (MBeans) in the portal server instance's MBeansServer that represents portal server Desktop and portal Desktop channels. Each MBean attribute represents monitoring data collected for each resource. The portal management console and psadmin monitoring subcommands communicate with MBeans to collect and present monitoring data for a portal server instance.

Setting Up Portal Server Monitoring

Monitoring can be configured by accessing monitoring properties stored in /var/opt/SUNWportal/portals/portalID/config/instanceID/monitoring.properties file. Monitoring is enabled by default. To disable monitoring, set com.sun.portal.monitoring.MonitoringContext.monitoring.disable property to true. When the JVM restarts, monitoring is disabled.

You can also enable or disable monitoring from the portal management console.

ProcedureTo Enable or Disable Portal Monitoring

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. Click the Monitoring tab.

  5. Click Settings submenu.

  6. Select a portal server instance.

  7. Click Enable Monitoring or Disable Monitoring button.

ProcedureTo View Desktop Statistics

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. Click the Monitoring tab.

  5. Click Desktop Request/Response Statistics from the submenu.

ProcedureTo View Channel Statistics

  1. Log in to the Portal Server management console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. Click the Monitoring tab.

  5. Click Channel Action Statistics from the submenu.

  6. From Select DN drop-down menu choose an organization.

  7. Select the server from the Server Instance drop-down menu.

Collecting Portal Server Monitoring Data

Monitoring collects seven types of data requests received by the Desktop. Each type of request is represented as MBean with type DesktopRequestStatistic, and name MBean property as the request type. For example, type=DesktopRequestStatistics,name=Content name properties help identify Desktop content request statistics.

Desktop Statistics

The seven types of requests are explained in the following list:

Content

The number of times Desktop successfully served content requests, and the time taken for it.

Edit

The number of times Desktop successfully served edit requests , and the time taken for it.

Exception

The number of times Desktop could not serve a request due to some exception during request processing. Exception information is logged in portal server log files.

LocalAuth

The number of times Desktop responded to local authentication requests.

Logout

The number of times user logged out from portal server, and how long it took to log out

PreLogin

The number of times Desktop responded to pre-login requests.

Process

The number of times Desktop processed edit requests, and the time taken for it

You can view the Desktop statistics from the portal management console.

Channel Statistics

Each type of channel action is represented as MBean with type ChannelActionStatistic along with additional name properties that identify the channel. To know the full MBean name, use the command psadmin get-monitoring-mbean-names.

Portal Desktop presents cached content view for a channel based on time-out channel property

The types of channel actions that are monitored for each Desktop channel are explained in the following list:

Content

The number of times channel provider successfully generated the content view, and the response time for it.

Edit

The number of times channel provider successfully presented the edit view, and the response time for it.

Process

The number of times channel provider processed the edit view.

You can view the Channel statistics from the portal management console.

Chapter 8 Managing Portal Server Logging

This chapter describes how to obtain Sun JavaTM System Portal Server log information.

This chapter contains the following sections:

Understanding Portal Server Logging

Portal Server supports logging across all components. The logs and log configuration are uniform across portal components. Seven standard log levels range from severe to fine grain. The logs can be routed to different files or data sinks and can consist of a single file or multiple files; that is, one for each component.

Log levels can be set for each module and sub-module, and logs can be routed to separate files for each module and sub-module within each component.

Managing Portal Server Logging

You can set up and manage Portal Server logging using the following components:

You can manage portal logging from the portal management console.

ProcedureTo Manage the Log Viewer

  1. To Login to the Management Console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. Click Logging, then Log Viewer from the submenu.

  5. From the Instance Name drop-down menu, select a portal instance.

    The Search Criteria and Search Results page for the log viewer is displayed.

  6. Enter the values for the Search Criteria, and click Search.

    The following search options are available:

    Log File Name

    File name that has the log content.

    Log Level

    Messages at the selected level or higher appear in the log. The available levels are SEVERE, WARNING, INFO, CONFIG, FINE, FINER, and FINEST. The default level is INFO, so the log will contain messages of INFO, WARNING, or SEVERE levels.

    To ensure that the messages you want to view appear in the log, first set the appropriate log levels on the Specific Logger Settings page.

    Timestamp

    Displays log messages of a certain time period.

    You can view 100 most recent log entries, or type a time period in the From and To text boxes.

    If you choose a Specific Range:

    • Both the From Date and To Date values are required

    • The From Date value cannot be later than the To Date value

    • The To Date value cannot be later than Today's Date

    • The From Time and To Time values are optional. If the From Time value is specified, then the To Time value has to be specified. For the Time value, the syntax must take the form hh:mm:ss.SSS. SSS stands for milliseconds. For example, 18:20:10.000

Equivalent psadmin Command

psadmin set-logger in Sun Java System Portal Server 7.2 Command-Line Reference

ProcedureTo Customize the Log Display

You can customize the Search Results page using the following steps:

  1. To Login to the Management Console.

  2. Select the Portals tab.

  3. Select a Portal Server under Portals.

  4. Click Logging, then select a portal server from the Instance Name drop-down menu.

  5. In the Log Viewer Results table, click the Timestamp column header to sort the messages.

  6. Click the details link to view a formatted log message in a new window.

ProcedureTo Manage Common Logger Settings

  1. To Login to the Management Console.

  2. Select the Portals tab.

  3. Select a Portal Server under Portals.

  4. Click Logging, then Common Logger settings from the submenu.

  5. From the Instance Name drop-down menu, select a portal instance.

  6. Modify the configuration attributes as necessary.

    The following options are available:

    General

    Log Level — You can choose what information to view in a log file by selecting a log level setting.

    The choices for Log level include:

    • Severe - errors visible to users

    • Warning - user warnings

    • Info - informative for users

    • Config - static setup information for developers

    • Fine - basic tracing information

    • Finer - detailed tracing information

    • Finest - complete tracing information

    • Off - can be used to turn off logging

    • All - indicates that all messages should be logged

    File Handler Properties

    • Limit — Specify the size of the log file in bytes. If the log file size exceeds this value, the log file will be rotated based on file count. The default value is 5 megabytes.

    • File Count — When the log reaches the specified size in bytes, create a new empty file with the generation number (%g in the File Pattern) incremented by 1. The default value is 2. To turn off log file rotation, set the value to 0.

    • Append — Specify whether the new message is to be appended to the existing file. Default is true.

    • Filter — To filter log records that are sent to destinations such as portal log or a destination specified by a custom log handler, you can plug in a custom log filter. The custom filter must implement the interface java.util.logging.Filter. Type the absolute class name of the filter in the field. Also put the filter class in the Application Server classpath so that the filter is installed during server startup.

    Other

    • Custom Handlers — To send logs to a destination other than portal log, you can plug in a custom log handler. The custom handler must extend the class java.util.logging.Handler (a JSR 047 compliant API). Type the absolute class name of the handler in the field. Also put the handler class in the Application Server classpath so that the handler is installed during server startup. You can specify more than one handler. Use comma to separate multiple names.

    • Use Web Container Log File — To disable portal logging administration and route all logs to the web container log file, chose Yes, other chose No. Default is No.

  7. Click Apply to the Selected Instance or Apply to All Instances to record the changes.

Equivalent psadmin Command

psadmin set-logger in Sun Java System Portal Server 7.2 Command-Line Reference

ProcedureTo Manage Specific Logger Settings

  1. To Login to the Management Console.

  2. Select the Portals tab.

  3. Select a Portal Server from Portals.

  4. Click Logging, then Specific Logger settings from the submenu.

  5. From the Instance Name drop-down menu, select a portal instance.

  6. Modify the configuration attributes as necessary.

    The following options are available:

    Logger Settings

    • Logger Name – Click the logger name to get the configuration details of the logger.

    • Log Level – You choose what information to view in the log file for the logger by selecting a log level setting or you can inherit the log level from the parent logger. For example, if the log level of debug.com.sun.portal is INFO and the log level of debug.com.sun.portal.desktop is Inherit Parent Logger Level, then its value will also be INFO.

    • Log File Merge Strategy – For a logger, you can choose whether you want the log messages in the same log file as parent (Log to Parent Log File) or the log should go to a separate file (Log to Separate Log File).

    • Parent Handler – For a logger, if the Log File Merge Strategy is set to Log to Separate Log File, you can choose whether you want the messages to be logged to both the separate log file as well as the parent log file (Inherit Parent Handlers) or log to separate file only (Do not Inherit Parent Handlers).

    • Parent Handler – For a logger, if the Log File Merge Strategy is set to Log to Separate Log File, you can choose whether you want the messages to be logged to both the separate log file as well as the parent log file (Inherit Parent Handlers) or log to separate file only (Do not Inherit Parent Handlers).

    • Stacktrace – For a logger, you can choose whether you want the stacktrace to be logged for all levels (Print Stack Trace for All Levels) or for only till WARNING log level (Print Stack Trace till Warning Level).

      Note –

      If Log File Merge Strategy value is Log to Parent Log File, Parent Handler and stacktrace values are ignored. If Log File Merge Strategy value is Log to Separate Log File, and if Parent Handler value is Inherit Parent Handlers, the Stacktrace value Print Stack Trace for All Levels is not valid.

  7. Click Apply to the Selected Instance or Apply to All Instances to record the changes.

Equivalent psadmin Command

psadmin set-logger in Sun Java System Portal Server 7.2 Command-Line Reference

Chapter 9 Managing a Portal Server Community

This chapter describes the management of a community and its users. This functionality is made available to a community owner through the Community Info portlet. Similar functionality is made available to system administrator through the Portal Server management console and psadmin command line interface. Refer to the Technical Note: Managing Sun Java System Portal Server 7.2 Update 1 Communities Technical Note for information on the command line utilities for managing communities.

Note –

If you need to set Community Attributes to your portal, follow the procedure described in the procedure To Add the Community Sample in the link, http://docsview.sfbay/app/docs/doc/820-0043/gdsbd?1=en&a=view.

This chapter has the following sections:

Understanding Portal Server Communities

This chapter contains the following:

Managing Access Control

While the concept of “community” has a general notion of being publicly open and making information accessible to everyone, there is a great need for establishing access control around the communities. As in the case of enterprise-based communities, the audience of certain communities might need to be restricted and the data posted to these communities be kept private and secure. This section describes the available access control settings and the common configurations for them.

Available Settings

Following are the three community aspects on which access controls can be set based on requirement of a community.

Membership Access

  • Unrestricted Membership (Public): A community with an unrestricted membership is open for anyone to join.

  • Restricted Membership (Private): A community with a restricted membership requires a user to make a request (to the owner of the community) and be granted or denied of the membership. Alternatively, the owner can invite or explicitly add one or more users to the community.

Community Listing

  • Listed (Public): A community is registered in the community categories and can be browsed and searched by anyone.

  • Unlisted (Private): A community cannot be searched and is not browsed in the community categories.

Secured Content

  • Unsecured (Public): The data posted on the community has the potential of being searched and accessed by non-members.

  • Secured (Private): All data posted on the community will be strictly protected and can only be searched and accessed by the members.

Common Configurations

A community owner or a system administrator can control the various aspects of the access control during or after creation of the community. Note that each setting described in the Available Settings section is independent of each other. In other words, selecting one option for a setting will not influence the behavior or selection of the other settings. For instance, a community with (unrestricted) membership can be unlisted or its content can be made secured. Owner of a community can customize the access control based on the nature of the community. The two most common configurations are explained here.

Public Community

A public community is open for anyone to join and gain membership. The community is listed in the community categories and can be browsed and searched by anyone. The content posted on community is also searchable and accessible to anyone.

Communities created on previous release of Portal Server software are considered public communities and will operate like a public community when the system is upgraded to this release of the Portal Server software.

Private Community

A private community is the most secure form of a community. It is hidden from the community categories thus cannot be browsed nor searched. Private community is a community that is unlisted, secure, and having restricted membership. The community owner can invite or manually add users to the community. The content of the community is protected from non-members such that they will not be able to view or search any posted content.

Managing Membership

A user can be assigned different roles in a community. The two primary roles are OWNER and MEMBER. A user in MEMBER role has all the regular member privileges. If it is assigned the OWNER role too, it will assume additional privileges to manage the community. The privileges and the content presented to the user are controlled by the merge of the corresponding display profiles for each of the role assigned to a user. System administrator must be careful when designing the display profiles templates for each community role. Please see the community template chapter for more details.

A non-member user implicitly assumes the VISITOR role and as a result, the visitor.xml is always merged when a non-member user visits a particular community page. A user is referred as a non-member when it either has no explicit role or has transient roles like BANNED, INVITED, PENDING and REJECTED.

Restricted Membership Workflow

In order for a user to join a community which is either private or has a restricted membership, a membership request should be made by the interested user. The owner of the community then either approves or denies the request. When approved, the user immediately becomes a member of the community. On the other hand, a denied user receives notice of rejection when the user logs into the portal and upon acknowledging the rejection, the user returns to the visitor status. A denied user can then submit request again at a later time. Owners can ban certain users if the owner does not even want the users to submit a request for membership.

VISITOR	--request membership-->	PENDING/VISITOR-->	approved-->	MEMBER
VISITOR	--request membership-->	PENDING/VISITOR-->	denied
																							|
																	-->REJECTED/VISITOR	--acknowledges-->	VISITOR

Inviting Users

As an owner of a community, one can send invitation to users to join the community. An invited user can see the invitation when the user logs into portal. The user then has an option to either accept or decline the invitation.

VISITOR-->		invited-->	INVITED/VISITOR-->	accepts-->	MEMBER
VISITOR-->		invited-->	INVITED/VISITOR-->	declines-->	VISITOR

When the system is set up properly, an invitation message is sent to the invited users through email. In order to receive an invitation through email, the user must have email address properly configured in their portal.

Banning Users

Banning is a process by which the owner can prohibit certain users from accessing the community. Both members and non-members, as well as owners, can be banned from the community and in the case of a restricted membership community, a banned user cannot even submit a request to join the community.

A banned user can be unbanned by the owner and the user's prior privileges are reinstated. If the user was a member before getting banned, the user becomes a member after getting unbanned. Likewise, when an owner gets banned from a community and is then unbanned, the owner becomes the owner of the community again.

MEMBER-->				banned-->	BANNED/VISITOR-->		unbanned-->	MEMBER
OWNER/MEMBER-->		banned-->	BANNED/VISITOR-->		unbanned-->	OWNER/MEMBER

Managing a community status

This section contains the following:

Enabling and Disabling a Community

A portal administrator, using either Portal Server management console or psadmin CLI, can disable a community. Likewise, only the portal administrator can enable a disabled community. Access to a disabled community is blocked to everyone including members and owners. An attempt to search for any content posted on a disabled community would yield no result. By default, a newly created community is enabled.

Use disabled.xml template to show how a disabled community would be presented to users. See Understanding Community Templatesto understand the display profiles for a community template.

Deleting and Restoring a community

A community owner or a system administrator can delete a community. When a community is deleted, the community itself and the data pertaining to the community are not accessible. However, in the back-end storage, the data still remains and thus the community can be restored on demand. The task of restoring a deleted community is done by the portal administrator. This undo functionality is made available to reverse a malicious or accidental deletion of a community. Since the deletion is not permanent, a new community by the same name can not be created. A permanent and persistent removal of a community is currently not supported. But we can use psadmin subcommand destroy-community to remove the community permanently.

Use deleted.xml template to show how a deleted community would be presented to users. See Understanding Community Templates to understand the display profiles for a community template.

Managing Categories

The category tree used in creating communities as well as browsing communities is provided by the taxonomy of the search server. To manage them, please see Managing Categories.

Understanding Community Templates

This chapter contains the following:

Overview of the Community Template

This section contains the following:

What Is A Community Template?

A community template is comprised of a set of services (channels) and the visual layout. However, the layout is not always dictated by the community template as in the case with wiki community template where the layout is dictated by the wiki itself. Community templates define (in the role display profile document) the type of services available for the community, the default settings for each service, and the containers that bind the services.

Physically, a community template is a properties file, and image, plus one or more display profile documents. There are display profile documents, one per community role (such as OWNER, VISITOR, MEMBER). Each role template defines services and the layout associated with the particular role (see Managing Membership for more information on these roles). The content of the role template is represented in a display profile document. In essence, a community template contains the logic for handling different roles (one display profile document per role) and depending on the one or more roles, you get a different set of services and a different layout. There are also display profile documents to customize the content when communities are marked for deletion (deleted.xml) or disabled (disable.xml).

Communities are created from a community template. The system may have any number of community templates. In the Enterprise Sample, end users choose a community template when they create a community.

How Are The Templates Stored?

The community templates are stored on filesystem. Community templates are stored in PortalServer-DataDir/portals/portal-URI/communitytemplates directory (referred to as communityTemplateBaseDir). Note that this means that each Portal (in a multi-portal deployment environment) will and must have its own set of community templates. The resource bundle in communityTemplateBaseDir defines the meta data associated with each template. In addition, each template has its own directory where the role templates are stored.

Example 9–1 Sample communityTemplateBaseDir 

communityTemplateBaseDir   -+-- template1 -+-- deleted.xml
                            |              |
                            |              +-- disabled.xml
                            |              |
                            |              +-- member.xml
                            |              |
                            |              +-- owner.xml
                            |              |
                            |              +-- visitor.xml
                            |
                           -+-- template2 -+-- deleted.xml
                            |              |
                            |              +-- disabled.xml
                            |              |
                            |              +-- member.xml
                            |              |
                            |              +-- owner.xml
                            |              |
                            |              +-- visitor.xml
                            |
                           -+-- template3 -+-- deleted.xml
                            |              |
                            |              +-- disabled.xml
                            |              |
                            |              +-- member.xml
                            |              |
                            |              +-- owner.xml
                            |              |
                            |              +-- visitor.xml
                            |
                            +-- template1.properties
                            |
                            +-- template1_en.properties
                            |
                            +-- template1_fr.properties
                            |
                            +-- template2.properties
                            |
                            +-- template3.properties
                            |
                            +-- template3_en_US.properties
                            |
                            +--       ...

The display profile disabled.xml and deleted.xml files control the content when the community is disabled or marked for deletion. See Managing a community status for more information.

How Are The Templates Managed?

The portal administrator can add a new community template, update an existing community template, archive and restore community templates on the system, and export community templates from one portal instance to others and/or keep them in sync.

Template Syntax and Semantics

Each template is made up of one or more role templates (member.xml, owner.xml, visitor.xml, deleted.xml, disabled.xml) in XML format. The template directory includes the XML files for the roles that it will serve; for example, member.xml for the community member, owner.xml for the community owner, and visitor.xml for the community visitor.

Each role template is a display profile document for community users in that role. The file must be based on the display profile DTD.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE DisplayProfile SYSTEM "jar://resources/psdp.dtd">
<DisplayProfile version="1.0" priority="%COMMUNITY_DP_PRIORITY%">
	<Properties/>
	<Channels>
		<Container name="%COMMUNITY_CONTAINER%" provider="JSPTableContainerProvider">
			<Properties>
				<String name="title" value="%COMMUNITY_NAME%"/>
				<String name="description" value="%COMMUNITY_DESCRIPTION%"/>
				<Boolean name="compileToRealPath" value="true"/>
			</Properties>
			<Available>...</Available>
			<Selected>...</Selected>
			<Channels>...</Channels>
	</channels>
	<Providers/>
</DisplayProfile>

The tokens (surrounded by %), described below, in the display profile are dynamically replaced by actual values by the template engine when a community is created.

%COMMUNITY_NAME%

Specifies the (user-friendly) name given to the community. For example, tourists.

%COMMUNITY_ID%

Specifies the unique string identifying the community. This name is strictly an internal representation and does not get exposed in the user interface. For example, jdo__tourists.

%COMMUNITY_DESCRIPTION%

Includes a description of the community.

%COMMUNITY_CONTAINER%

Specifies the top-level container for the community. For example, jdo__touristsContainer.

%COMMUNITY_DP_PRIORITY%

Specifies the display profile merging priority given to the resulting community display profile. Each role is given a different value. By default, 1000 for the visitor role, 1005 for the member role, and 1010 for the owner role.

%COMMUNITY_SEARCH_URL%

Specifies the Search server URL for the community.

%COMMUNITY_CONTENTS_SEARCH_DB%

Specifies the search database for the community content.

%COMMUNITY_DISCUSSIONS_SEARCH_DB%

Specifies the discussions database.

%PORTAL_ID%

Specifies the ID of the portal. For example, portal1.

Template Descriptor File

Each template includes a resource bundle properties file which defines the meta-data associated with that template. The resource bundle is referred to as the descriptor file that can be localized. Each template descriptor file (must) define the following properties:

id

Specifies an unique ID of the template. The ID must match the template directory name. For example, Baseball for a template directory named Baseball with role templates (or XML files) for all three supported roles.

name

Specifies an user-friendly name used in the user interface (portal desktop) to identify the template. For example, Baseball Template.

description

Contains a verbose description of the template including the services it offers. For example, Baseball-themed template containing the following services: Player Statistics, Game Discussions, TV Schedule, and Online Chat.

tokens

Includes the list of tokens used in the template role files. This merely serves an informative purpose and is not required. For example, %COMUNITY_ID% %COMMUNITY_DESCRIPTION% %COMMUNITY_CONTAINER%.

previewImageURI

Specifies either the absolute or relative URI to the portal context. For example, http://images.domain.com/images/baseball.jpg. The relative URI must be relative to the portal web-app context path.

Example 9–2 Sample Descriptor File


id=Baseball
name=Baseball Template
description=Baseball-themed template containing the following services:
 Player Statistics, Game Discussions, TV Schedule, and Online Chat
tokens=%COMUNITY_ID% %COMMUNITY_DESCRIPTION% %COMMUNITY_CONTAINER%
previewImageURI=http://images.domain.com/images/baseball.jpg

Creating and Modifying a Template

To create a new or modify an existing template, following the instructions in this section. You can create a template in one of the following three ways:

ProcedureTo Create a New Template for Single Portal Environment

  1. Go to the communityTemplateBaseDir.

    Create a:

    • New directory for the new template

    • Copy an existing template to the new template directory

    For example, type:


    cd PortalServer-DataDir/portals/portal-URI/communitytemplates
mkdir NewTemplate
cp 2column/* NewTemplate/

  2. Modify the role based display profile documents in the new template directory as needed.

    For more information on the role based display profile documents, see Template Syntax and Semantics.

  3. Create and edit the properties file to include the properties described in Template Descriptor File and save the file.

    For example, to create a new properties files for the new template, type:


    cp 2colimn.properties NewTemplate.properties

    Or,


    touch NewTemplate.properties
    Note –

    In order to see the newly added template, log out of any current portal session and re-login to see the change.

ProcedureTo Customize or Modify an Existing Template for Single Portal Environment

  1. Go to the communityTemplateBaseDir/template directory and open the file you wish to modify.

  2. Log out of any current portal session and re-login to see the change.

ProcedureTo Create a Template for Multi-Portal Environment

In a muti-portal environment (when there are more than one portal on the system), use PAR mechanism (as opposed to directly editing files in communityTemplateBaseDir) so that the change of community templates can be applied across multiple portals. This will allow all the portals to have the same set of community templates. If you do not wish to have synchronized environment across portals, use the instructions outlined in To Create a New Template for Single Portal Environment.

  1. Either use psadmin export --type desktop to export desktop data (which includes community templates) and then export it so the content can be edited or, create a new PAR structure from scratch with only the community templates and no other desktop data.

    Follow instructions in To Create a New Template for Single Portal Environment to edit content.

    • Create a new PAR file which contains:

         -+-- META-INF -- MANIFEST.MF
    |    
    +-- pbfiles -+-- communityTemplateBaseDir -+-- template1 -+-- deleted.xml
    |                                          |              |
    |                                          |              +-- disabled.xml
    |                                          |              |
    |                                          |              +-- member.xml
    |                                          |              |
    |                                          |              +-- owner.xml
    |                                          |              |
    |                                          |              +-- visitor.xml
    |                                          |
    |                                          +-- template1.properties
    |                                          |
    |                                          +-- template1_en.properties
    |                                          |
    |                                          +-- template1_fr.properties
    |                                          |
    |                                          +-- ...
    |
    +-- static -- community -- images -- template1.gif

  2. Edit or add content as needed.

  3. Create a new PAR file.

  4. Use psadmin import subcommand to import the PAR content across all portals.

    If you exported all desktop data, note that psadmin export subcommand will export all desktop data; if you create a new PAR structure from scratch with only the community templates, the command will only export community templates.

    Tip –

    For more information, see the psadmin export in Sun Java System Portal Server 7.2 Command-Line Reference.

Managing a Portal Server Community

This section provides information on creating and managing communities and community users from the Sun JavaTM System Portal Server administration console.

In Community Management page, a table lists the communities in the portal. Users can search for a community, and manage communities and community users.

The Community Management table contains the following information:

For steps on how to manage communities and users, see Managing Communities and Users.

Managing Communities and Users

This section provides information on how to manage communities and users from Sun Java System Portal Server management console.

Use the following steps to manage communities and users:

ProcedureTo Search for a Community

  1. Under the Portals tab, click a portal.

  2. Click the Communities tab.

    The Community Management page displays.

  3. Type the name of the community in the Search for communities text box, and click Search.

    Communities matching the search criteria are listed.

    Tip –

    You can do a wildcard search. For example, if your search criteria is *blog, all communities with the word blog anywhere in the name will be listed. Typing * will display all the communities.

ProcedureTo Create a Community

  1. Under the Portals tab, click a portal.

  2. Click the Communities tab.

    The Community Management page displays.

  3. Click the New button.

    The Create Community page displays.

  4. Type the values in the text boxes and make selections from the drop-down menus.

  5. Click OK to finish.

ProcedureTo Manage Community Users

  1. Under the Portals tab, click a portal.

  2. Click the Communities tab.

    The Community Management page displays.

  3. Select a community.

    Note –

    Only one community can be managed at a time

  4. Click Manage Current Users button.

    The Manage Users page displays.

  5. Click the Add button.

    The Add Community User page displays.

    Note –

    If you want to change the status of existing users, go to step 7.

  6. Type a user name in the User DN text box, and click Add.

    1. If you do not know the user name, click Choose.

      The Select a User page displays.

    2. Type the search criteria in the Search for Users text box, and click Search.

      Tip –

      You can do a wildcard search. For example, if your search criteria is *user, all user IDs with the word user anywhere in the name will be listed. Typing * will display all the users.

    3. Specify a user, and click Select.

      The User DN text field in the Add Community User page displays the selected user name.

    4. Click Add.

  7. To change the status of an existing user, select a user.

  8. Click one of the available option buttons.

    The following options are available:

    • Remove – Removes user from the community

    • Assign Ownership – Assigns owner privileges to a community member

    • Unassign Ownership – Owner privileges removed

    • Ban – Banned from the community

    • Remove Ban – Ban from the community removed

  9. Click Back to return to Community Management page.

ProcedureTo Manage Pending Users

  1. Under the Portals tab, click a portal.

  2. Click the Communities tab.

    The Community Management page displays.

  3. Select a community, and click the Manage Pending Users button.

    The Managing Pending Users page displays.

  4. Select a user from the Awaiting Membership Approval table, and click the Approve or Deny button.

  5. Click Back to return to Community Management page.

ProcedureTo Enable a Community

  1. Under the Portals tab, click a portal.

  2. Click the Communities tab.

    The Community Management page displays.

  3. Select a community.

    Note –

    Multiple communities can be selected.

  4. Click the Enable button.

ProcedureTo Disable a Community

  1. Under the Portals tab, click a portal.

  2. Click the Communities tab.

    The Community Management page displays.

  3. Select a community.

    Note –

    Multiple communities can be selected.

  4. Click the Disable button.

ProcedureTo Unmark a Community for Deletion

  1. Under the Portals tab, click a portal.

  2. Click the Communities tab.

    The Community Management page displays.

  3. Select a community under Name.

    Note –

    Multiple communities can be selected.

  4. Click the Unmark for Deletion button.

ProcedureTo Mark a Community for Deletion

  1. Under the Portals tab, click a portal.

  2. Click the Communities tab.

    The Community Management page displays.

  3. Select a community under Name.

    Note –

    Multiple communities can be selected.

  4. Click the Mark for Deletion button.

    Note –

    To permanently delete the community, use the command psadmin remove-community -u amadmin -f password_file -p portal --name community_name

ProcedureTo Edit a Community

  1. Under the Portals tab, click a portal.

  2. Click the Communities tab.

    The Community Management page displays.

  3. Click a community.

    The Editing page displays.

  4. Change the values and selections for the community.

  5. Click Save.

Managing Community Webservice URL

Community search and administration functionality involves a community webservice. By default, the community webservice URL contains the same host as the first Portal instance. In a multi-node installation that uses a load balancer, you can change the community webservice URL to use the load balancer host.

ProcedureTo get and set the community webservice URL

  1. Type the following in a terminal window:

    ./psadmin get-attribute -u amadmin -p portal-URI -m communities -a WebServicesURL

    ./psadmin set-attribute -u amadmin -p portal-URI -m communities -a WebServicesURL URL

    amadmin

    Specifies the administrator's distinguished name.

    portal-URI

    Specifies the portal ID.

    WebServicesURL

    Specifies the value for the WebServicesURL attribute. For example, the URL can be of the format http://foo.com:8080/communitymanagerwebservices/communitymanagerwebservices. Please note that the communitymanagerwebservices/communitymanagerwebservices part of the URL must not be changed.

    Note –

    There is no default value for the WebServicesURL attribute. By default, an empty value indicates that the host of the first Portal instance will be used.

Chapter 10 Managing Portal Server Subscriptions

This chapter describes the Sun JavaTM System Portal Server subscriptions component and how to manage it. The chapter contains following topics:

Understanding Portal Server Subscriptions

Subscriptions enable end users to create a profile covering many sources of information, including categories, discussions, and searchable documents. The profile is updated with the latest information each time the end user accesses the Subscriptions channel. The Subscriptions channel summarizes the number of items of relevant information that match each profile entry that the end user defines for categorized document or discussions.

You can match the following types of content using the search server:

The result is displayed as a link that shows the number of matching information to the profile entry. This link redirects the end user to a more detailed view of the match itself.

In case of a category subscription, the link redirects the end user to the search channel, which summarizes the specific documents of interest in a standard category search result format. The Subscriptions channel acts as the doorway to a more detailed view for the end user.

The Profiler function provides email notifications when the content of specified interests has changed. The Profiler obtains subscription details for end users from the Access Manager, fetches the results from the Search server, and sends email notifications to end users. You can schedule the Profiler to run at a specific time at the organization level.

Setting Up Subscriptions

You can enable or disable subscriptions. Subscriptions can be set up at the:

ProcedureTo Set Up Subscriptions

  1. To Login to the Management Console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. Click the Subscriptions tab.

  5. Set the subscriptions level by choosing one of the following, and set the default values:

    • From the Select DN drop-down menu, choose TopLevel [Global].

      Note –

      Administering subscriptions at the TopLevel sets the system-wide default maximum number of subscriptions for each type, or for categories, discussions, and saved searches.

      Maximum number of Categories subscriptions

      Specifies the maximum number of categories that a user can subscribe to.

      Maximum number of Discussion subscriptions

      Specifies the maximum number of discussions that a user can subscribe to.

      Maximum number of Saved searches

      Specifies the maximum number of searches that can be saved.

    • From the Select DN drop-down menu, choose any Organization.

      Note –

      Administering Subscriptions at the Organization level overwrites the system-wide default maximum number of subscription per type (that is, for categories, discussions, and for saved searches).

      Profiler SMTP

      The host system that serves as the SMTP server to route Email notifications to the end users.

      Profiler Email

      Subscription profiler email address from which the user receives email notification. Email should be in the form ID@domain.

      Profiler Provider

      The URL of the Profiler channel that is used to render the content of the Email notification to the user. It should be in the form of http://HOST:PORT/portal/dt?

      provider=profiler&desktop.suid=UID_OF_AUTHLESSANONYMOUS_USER

      Profiler Default Search

      The URL of the default search server. Profiler Default Search is only used for backward compatibility with user profiles created with Portal Server 6.3.x. It should be in the format http://HOST:PORT/search1/search

      Profiler Max Hits

      The maximum number of result hits that any given end user subscriptions in the organization will see in email notification sent to a user. For example, if the value is 5, a saved search with a large scope like “*” is limited with five most relevant results.

      Maximum Category subscriptions

      The maximum number of categories that a user can subscribe to.

      Maximum Discussion subscriptions

      The maximum number of discussions that a user can subscribe to.

      Maximum Saved Searches

      The maximum number of searches the end user can save.

    • From the Select DN drop-down menu, choose any User.

      Note –

      Administering Subscriptions at the Organization User level edits user’s Subscriptions settings. The administrator can maintain the user’s service data.

      • Update user subscriptions

      • Delete user subscriptions

      Profiler Enabled

      Allows users to receive email notifications by selecting Enabled.

      For each type of subscription, add or remove subscriptions. The format of:

      Category subscription

      label | target category | scope | lapsed time | rating | server | database | status

      where

      label

      Refers to a logical reference given to the edited subscription and it must be a string. This is a required field.

      target category

      Must be of the string format ABC:DEF:GHI

      scope

      Refers to a search query and it must be of a string format that is a valid search string, including search operators.

      lapsed time

      Must be one of the following numbers:

      • 0 = forever

      • 1 = since yesterday

      • 7 = since last week

      • 30 = since last month

      • 180 = since last 6 months

      • 365 = since last year

      rating

      This is the minimum rating that a matching document should be to be selected as a match for the subscription.

      Values are number

      • –1 = irrelevant

      • 0 = routine

      • 1 = interesting

      • 2 = important

      • 3 = must read

      server

      This is the URL of the search server that will be queried to find content matching subscription's criteria.

      database

      Target search server database where subscription searches for potential matches. This is a single value database.

      status

      Boolean value that marks whether the subscriptions is active or inactive.

      • Active means the subscriptions is to be evaluated.

      • Inactive means the subscriptions is dormant.

      Discussions subscriptions

      label | target discussion | scope | lapsed time | rating | server | database | status

      where:

      label

      Refers to a logical reference given to the edited subscription and it must be a string. This is a required field.

      target discussion

      Parent node of the discussion thread from which subscriptions will try to find matching content for other defined criteria.

      scope

      Refers to a search query. scope must be a string format that is a valid search string, including search operators.

      lapsed time

      Must be one of the following numbers:

      • 0 = forever

      • 7 = since last week

      • 30 = since last month

      • 180 = since last 6 months

      • 365 = since last year

      rating

      This is the minimum rating that a matching document should be to be selected as a match for the subscription.

      Values are number

      • –1 = irrelevant

      • 0 = routine

      • 1 = interesting

      • 2 = important

      • 3 = must read

      server

      This is the URL of the search server that will be queried to find content matching subscription's criteria.

      database

      Target search server database where subscription searches for potential matches. This is a single value database.

      status

      Boolean value that marks whether the subscriptions is active or inactive.

      • Active means the subscriptions is to be evaluated.

      • Inactive means the subscriptions is dormant.

      Saved searches

      label | scope | lapsed time | rating | server | database | status

      where

      label

      Refers to a logical reference given to the edited subscription and it must be a string. This is a required field.

      scope

      Refers to a search query and if must be of a string format that is a valid search string, including search operators.

      lapsed time

      Must be one of the following numbers:

      • 0 = forever

      • 1 = since yesterday

      • 7 = since last week

      • 30 = since last month

      • 180 = since last 6 months

      • 365 = since last year

      rating

      This is the minimum rating that a matching document should be to be selected as a match for the subscription.

      Values are number

      • –1 = irrelevant

      • 0 = routine

      • 1 = interesting

      • 2 = important

      • 3 = must read

      server

      This is the URL of the search server that will be queried to find content matching subscription's criteria.

      database

      Target search server database where subscription searches for potential matches. This is a single value database.

      status

      Boolean value that marks whether the subscriptions is active or inactive.

      • Active means the subscriptions is to be evaluated.

      • Inactive means the subscriptions is dormant.

  6. Click Save.

Equivalent psadmin Command

psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference

Administering Portal Server Discussions

This section describes the discussions channel and how to manage it.

This section contains the following:

Understanding DiscussionProvider

The Discussions channel is based on the DiscussionProvider, similar to the search channel’s JavaServer PagesTM (JSPTM) files. The discussion channel has a query portion and a display portion, and uses Desktop themes.

The DiscussionProvider:

Discussions and comments are stored as different Resource Descriptors (RDs) in the discussion database. The DiscussionProvider supports:

Administering the DiscussionProvider

You can create a DiscussionProvider channel and manage it from the portal server management console:

End users can configure the discussion channel using the channel edit page.

ProcedureTo Create a Channel from DiscussionProvider

  1. To Login to the Management Console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. From the Select DN drop-down menu, select any DN.

  5. Select the container where you want to create the channel.

    The container Task and Properties are displays on the right panel.

  6. Under Tasks, click New Channel or Container to launch the wizard.

    1. From the Select Portal drop-down menu, select a portal server.

    2. From the Select DN drop-down menu, select any DN.

    3. Under Type, select channel, and click Next.

    4. Under Channel Type, select Provider Channel, and click Next.

    5. From the Provider drop-down menu, select DiscussionProvider, and click Next.

    6. Type a name for the channel in the text box, and click Next.

    7. Review the channel information, and click Finish.

    8. Click Close.

    The channel based on DiscussionProvider is created.

ProcedureTo Delete a DiscussionProvider Channel

  1. To Login to the Management Console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. From the Select DN drop-down menu, choose the DN where the DiscussionProvider channel resides.

    Tip –

    Select DP XML Tree as the View Type from the drop-down menu for a listing of all the channels and containers under DP_ROOT.

  5. Select the container where the channel resides.

    The container Tasks and Properties page displays.

  6. Click Select Channel or Container to delete.

  7. Select the DiscussionProvider channel.

  8. Click Delete.

ProcedureTo Configure a DiscussionProvider Channel

  1. To Login to the Management Console.

  2. Select the Portals tab.

  3. Select a portal server under Portals.

  4. Choose DN organization where the DiscussionProvider channel resides from Select DN drop-down menu.

    Tip –

    Select DP XML Tree as the View Type from the drop-down menu for a listing of all the channels and containers under DP_ROOT.

  5. Select the DiscussionProvider channel you want to configure.

    For more information about the attributes, see Sun Java System Portal Server 7.1 Technical Reference.

DiscussionLite Channel

The DiscussionLite channel displays the top 20 recent discussion titles and the date. Discussions are sorted by creation date (last modified), and the newest discussion is displayed first. Titles can be reconfigured.

The DiscussionLite channel view has links for:

By default, the channel is displayed in a single container, and all links are brought up in a JSPDynamicSingleContainer.

Properties can be configured from the management console. By default, the end user cannot edit properties of this channel.

Chapter 11 Managing the Portal Server Single Sign-On Adapter

This chapter describes how to configure the single sign-on (SSO) adapter in order to adjust options available to end users. This chapter contains the following sections:

Overview of the Single Sign-On Adapter

The single sign-on adapter service allows end users to use applications, such as a portal server provider or any other web application, to gain authenticated access to various resource servers after signing in once. The resource servers that can be accessed depend on the implementations of the SSO Adapter interface that are available in the system.

Portal Server provides SSO Adapters for the following resource servers: Address Book, Calendar, and Mail. Single Sign-On for the Instant Messaging channel is not achieved through SSO Adapter but through the use of the Sun Java System Portal Server authentication method. For information on this method, see the authMethod property in Instant Messaging Channel . The Address Book, Calendar, and Mail services are available through the products:

Resource servers are typically accessed by an application using a standard application programming interface (API), such as the JavaMailTM API for accessing a mail server. To create an authenticated connection using the API, the API must be provided the configuration data for the connection. The purpose of the SSO Adapter is to provide this configuration data, and the SSO Adapter service is used to store that data.

The SSO Adapter service defines two levels of data, meta-adapters and adapters. A meta-adapter defines a class of connections that are going to be made available to users. A single meta-adapter is used by many users. It defines data values that are the same for all users that use the meta-adapter including default values and identification of what values can be edited by a user. Therefore, meta-adapters are defined at a global service level.

An adapter builds upon a meta-adapter by providing data values that are specific to an organization, role, or user. An adapter references a meta-adapter, and takes data values from the meta-adapter for those properties that are not editable by the user. When an end user changes the user-editable properties of an adapter, that adapter would then apply only to that one user.

A Sun Java System Sun Java System Portal Server communication channel that uses the SSO Adapter service references either a meta-adapter or an adapter to get data values needed to obtain a connection to a resource server. If the channel references a meta-adapter, and the user saves configuration information, the reference is changed to refer to an adapter instead. The adapter then references the meta-adapter.

All administration for the SSO Adapter is done either through the Portal Server console web application or the psadmin command-line interface. The default deployment URI for Portal Server console is /psconsole. The default location for the psadmin CLI is /opt/SUNWportal/bin for Solaris.

Managing Meta-Adapters

A meta-adapter defines a class of connections that are going to be made available to users. A single meta-adapter is used by many users.

You can perform the following tasks using meta-adapters:

ProcedureTo View Meta-Adapters

  1. To Login to the Management Console.

  2. Select the SSO Adapter tab.

    The list of meta-adapters is shown in the table.

Equivalent psadmin Command

psadmin list-ssoadapters in Sun Java System Portal Server 7.2 Command-Line Reference

ProcedureTo Create a Meta-Adapter

  1. To Login to the Management Console.

  2. Select the SSO Adapter tab.

  3. From List of Meta-Adapters click New Meta—Adapter to launch the wizard.

  4. Follow the instructions and then click OK to create the specified Meta-Adapter.

Equivalent psadmin Command

psadmin create-ssoadapter-template in Sun Java System Portal Server 7.2 Command-Line Reference

ProcedureTo View Adapters

  1. To Login to the Management Console.

  2. Select the SSO Adapter tab.

    • To view adapter for a DN, click View Adapter for Locations.

      1. From the Select DN drop-down menu, choose any DN.

        The adapters for selected DN are listed.

    • To view adapters for a meta—adapter, select a meta-adapter under List of Meta-Adapters.

      1. Click View Adapters for Selected Meta-adapter.

Equivalent psadmin Command

psadmin list-ssoadapters in Sun Java System Portal Server 7.2 Command-Line Reference

Note –

The only list of adapters allowed by the CLI is by DN.

Managing Adapters

An adapter builds upon a meta-adapter by providing data values that are specific to an organization, role, or user. An adapter references a meta-adapter, and takes data values from the meta-adapter for those properties that are not editable by the user. When an end user changes the user-editable properties of an adapter, that adapter would then apply only to that one user.

You can perform the following tasks using SSO Adapter configurations:

ProcedureTo Create an Adapter

  1. To Login to the Management Console.

  2. Select the SSO Adapter tab.

  3. Select a meta-adapter under List of Meta-adapters.

  4. Click View Adapters for Selected Meta-adapter.

  5. Click New Adapter.

    The New adapter page appears.

  6. Provide the configuration attributes as necessary.

  7. Click OK.

Equivalent psadmin Command

create-ssoadapter-config in Sun Java System Portal Server 7.2 Command-Line Reference

ProcedureTo Edit an Adapter Configuration Property

  1. To Login to the Management Console.

  2. Select the SSO Adapter tab.

  3. Click View Adapters for Locations.

  4. From the Select DN drop-down menu, choose any DN.

    The list of Adapters appears.

  5. Select an adapter and modify the configuration attributes as necessary.

  6. Click OK.

Equivalent psadmin Command

psadmin set-ssoadapter-property in Sun Java System Portal Server 7.2 Command-Line Reference

Creating Anonymous Users

Without logging in, end users have access to any read-only communication channels that administrators have configured. However, end users are usually prevented from editing these channels.

ProcedureTo Create a List of Anonymous Users

  1. To Login to the Management Console.

  2. Select the SSO Adapter tab.

  3. From SSO Adapter Tasks, click Edit list of users allowed to access SSO Adapters without authentication.

  4. From User locations, click Add Users.

  5. From Users Found table, choose users.

  6. Click Add Selected Users.

    Note –

    The Anonymous Users function is available only through Portal Server management console.

Chapter 12 Managing Portal Server Mobile Access

This chapter provides information about how to configure Mobile Access in Portal Server 7.2, how to mention the change in success URL

The following topics are discussed:

Introduction to Mobile Access

Mobile Access extends the services and capabilities of Sun Java System Portal Server platform to mobile devices, such as mobile phones and personal digital assistants.

Mobile Access software enables portal site users to obtain the same content that they access using browsers that require HyperText Markup Language (HTML). It supports Sun Java System Portal Server Secure Remote Access software and uses Sun Java System Access Manager software's administration console.

The features of the Mobile Access product are integrated seamlessly into Portal Server software. If you know how to administer Portal Server software, understanding how to administer Mobile Access software will not be difficult.

Configuring Mobile Access

ProcedureTo Configure Mobile Access in Portal Server 7.2.

  1. Login to the Portal Server Management Console.

  2. Click the Portals tab.

  3. Click the portal1 portal from the list of available portals.

  4. Select EnterpriseSample from the SelectDNdrop down list.

  5. Change the value of ParentContainer field available in the Desktop Attributes to WirelessDesktopDispatcher.

ProcedureTo Enable Mobile Access Anonymous Desktop

  1. Login to the Portal Server Management Console.

  2. Click the Portals tab.

  3. Click a portal from the list of available portals.

  4. Select TopLevel (Global) from the Select DN list.

  5. Under Valid UIDs for Anonymous Desktop, set the default User DN for anonymous deployment of the portal.

    To enable portal users to access the Enterprise Sample Anonymous Mobile Desktop using a mobile device, set the default User DN to anonymousenterprise.

Procedure To Mention the Change in Success URL

  1. Login to the Access Manager Console.

  2. Select the Service Configuration tab.

  3. Click Core under Authentication Modules.

  4. Edit the property of the Default Success Login URL to /portal/dt.

Mobile Access Software

Knowledge of the following Mobile Access software features and how they extend the functions of Portal Server software are useful:

The Portal Desktop

Your portal site provides a mobile Portal Desktop as well as a standard Portal Desktop. A wireless desktop dispatcher, which is a component of the Mobile Access software, controls them. The Portal Server desktop servlet forwards requests to the wireless desktop dispatcher. The wireless desktop dispatcher uses display profile configuration data to determine which Portal Desktop—standard or mobile—is the appropriate one to route user requests to. Regardless of how the user accesses a portal site, the Portal Desktop is the user's interface for the portal site.

These channels are available and visible by default on the mobile Portal Desktop:

For more details on the mobile Portal Desktop, see Managing the Mobile Portal Desktop

Client Types

Mobile Access software supports virtually every mobile device available. It uses a client profile to identify each mobile device, or client. It assigns each client a unique identifier called client type, based on the device markup language the device's browser uses.

These markup languages include:

Mobile Access software certifies WML support for the Nokia 6310i client and cHTML support for the Handspring Treo 180 client, although users can access portal content with any mobile device that uses one of these markup languages.

The Client Manager, which is part of the administration console of Access Manager, is used for managing client profiles. For details about mobile client type and device detection, see Chapter 2

Mobile Access Authentication Modules

Mobile Access software supports the authentication modules that Portal Server software provides, but it also allows you to:

For details on using these authentication modules, see Configuring Mobile Authentication.

Channels, Containers and Providers

Mobile Access software uses providers, channels, and containers to present content to the mobile Portal Desktop.

This section provides information on:

Channels

Channels display content in the mobile Portal Desktop. A channel consists of the provider object, configuration settings, and data files (such as templates) required to support the channel.

Container Channels

A container, or container channel, is a channel that displays content in the mobile Portal Desktop by aggregating the content of other channels. Mobile Access software adds the following default container channels to those included with Portal Server software:

Providers

Providers are the underlying implementation that present channel content to users on the mobile Portal Desktop. They adapt the interfaces of generic resources.

Provider content sources can include:

Providers, which are Java class files, deliver content in the proper format for each type of mobile device. As a mobile Portal Desktop is created, each provider is queried for the content of its associated channel.

The following new providers are added to the default containers:

For details on using channels, containers, and providers to configure the mobile Portal Desktop, see Managing the Mobile Portal Desktop.

Managing Mobile Devices

Sun Java System Portal Server Mobile Access 7.2 software uses Sun Java System Access Manager client detection module to identify and manage the various clients, or mobile devices, that portal site users employ to access a portal site.

This section provides information on the following topics:

Understanding Client Detection

Client detection determines the capabilities and characteristics of each mobile device that is used to access the portal site. To do this, it uses the composite capability and preference profiles (CC/PP) specification, UAProf, or preconfigured data. Mobile Access software requires that three properties be defined for every client. They are:

Mobile Access software also uses conditional properties to store and retrieve specific property values for client types. One example is the desktopContainer conditional property. The wireless desktop dispatcher reads this property to determine what the desktop container is for the requested client type.

Mobile Access software imports client type data from the file /var/opt/SUNWam/config/ldif/sunAMClient_data.ldif into the LDAP directory and uses Access Manager software APIs to identify clientType property matches. Matches are determined in the following order:

  1. An exactmatch

  2. A partialmatch

  3. A keywordmatch

You can also dynamically apply UAProf profile against your base profile. Users need to retain FEDIClientDetector and do one of the following:

Note –

To configure the proxy server to selectively access the public internet:

The JVM provides an option to specify proxy server details for an external connection from the web container using an external proxy. The JVM also allows you to specify the hosts that should not use the specified proxy. You can configure the Mobile Access system JVM to use a proxy server to access the public Internet.

Use the following JVM options in the web container:

Dhttp.proxyHost=your-proxy-server-host

Dhttp.proxyPort=your-proxy-server-port

Use the following option for bypassing proxy server for certain domains and hosts: Dhttp.nonProxyHosts="*.domain-name|hostname|localhost"

Using the Client Manager

The Access Manager administration console provides a Client Manager that enables you to manage properties for mobile devices.

This section explains the following types of information that the Client Manager provides about client types:

This section also explains how to create and customize the client type:

Markup Languages

Mobile Access software supports these markup languages used by mobile client browsers:

Styles

A Style is a set of properties for an associated group of devices for a markup language. For example, a Nokia Style is applied to all WML devices manufactured by Nokia.

At least one Style exists for each markup language. Some markup languages have multiple styles.

You cannot override Style properties. If you use an existing client as a template for a new devices when you create it, the new client inherits the existing client's Style properties.

Device Information

Device information is device-specific client type data that you can update.

When you change the device information for a default client type, you create a new and separate version of the default client type. This custom information is stored in the external library, while the default device information remains in the internal library. Two asterisks are added to the client type name of each custom device to differentiate it from devices in the internal library.

Filter Option

The Filter option is a search field that enables you to find and list groups of specific client types assigned to a specific Style.

Client Editor

The Client Editor enables you to create and customize a client type, and to manage client properties.

The Client Editor organizes properties in the following groups:

ProcedureTo Launch the Client Manager

  1. Log in to the Access Manager administration console as the administrator. By default, Identity Management is selected in the Header frame (the top horizontal frame) and Organizations is selected in the Navigation frame (the left vertical frame).

  2. Click the Service Configuration tab.

  3. From the Service Configuration frame on the left, under the Access Manager Configuration heading, click the arrow for Client Detection. The Client Detection global preferences appear in the Data frame on the right.

  4. Click the Edit link following the Client Types label. The Client Manager interface appears. Details about HTML devices are displayed by default.

ProcedureTo View Style Properties

  1. Log in to the Access Manager administration console as the administrator. By default, Identity Management is selected in the Header frame (the top horizontal frame) and Organizations is selected in the Navigation frame (the left vertical frame). 2. 3. 4.5 6. 7. 8.

  2. Click the Service Configuration tab.

  3. From the Service Configuration frame on the left, under the Access Manager Configuration heading, click the arrow for Client Detection. The Client Detection global preferences appear in the Data frame on the right.

  4. Click the Edit link following the Client Types label. The Client Manager interface appears. Details about HTML devices are displayed by default.

  5. .From the tabs at the top, click the markup language for the device whose properties you want to examine (for example, WML). If client types using the markup language you selected are in the database, they appear in alphabetical order.

  6. From the Style pull-down menu, pick the style that you want (for example, Nokia). The list of client types already in the database appears for the selected style.

  7. Click the Current style properties link. The Edit style page appears. The Styles for General properties are displayed by default.

  8. From the Properties pull-down menu, click the properties type that you want to view (for example: Software Platform).

    Note –

    Properties type choices include General, Hardware Platform, Software Platform, Network Characteristics, BrowserUA, WapCharacteristics, PushCharacteristicsNames, and Additional Properties.

  9. To return to the Client Manager page, click Cancel.

Managing Client Type Data

You use the Client Manager in the administration console to manage client type data.

You can change client type properties, create new client types to accommodate new devices, set up client types with names and other properties that are customized for your site, and remove custom client types.

If you choose to create a new device based on an existing device, a process called inheriting, you must base the new device on either the styles or the properties of the existing device. Examine your new device and the existing device to decide which option—styles or properties—is preferable. Both choices require you to customize device definitions.

Note –

The client type database consists of internal and external libraries. When you change or add to default client type information in the internal library, your updates are stored in the external library. Two asterisks added to the client type name indicate that it is a customized client type.

This section provides instructions for completing the following tasks:

ProcedureTo Edit Client Types

  1. Log in to the Access Manager administration console as the administrator. By default, Identity Management is selected in the Header frame (the top horizontal frame) and Organizations is selected in the Navigation frame (the left vertical frame).

  2. Click the Service Configuration tab.

  3. From the Service Configuration frame on the left, under the Access Manager Configuration heading, click the arrow for Client Detection. The Client Detection global preferences appear appear in the Data frame on the right.

  4. Click the Edit link following the Client Types label. The Client Manager interface appears. Details about HTML devices are displayed by default.

  5. From the tabs at the top, click the markup language for the device you want to edit (for example, WML). If client types using the markup language you selected are in the database, they appear in alphabetical order.

  6. From the Style pull-down menu, pick the Style that you want (for example, Nokia). The list of client types already in the database appears for the selected style.

  7. From the Client Type list, scroll down to find the client that you want to edit (for example, Nokia6310i_1.0).

    Clients are listed in alphabetical order.

  8. To go directly to a specific client type, or to a group of client types, use the Filter option. In the Filter text box, type in the first character or first few characters of the client type you want to view and then click the Filter button. (For example: To find client types that start with the letter S, type in S*.)

  9. To go to specific pages, scroll to the bottom and use the arrows or the Go option.

  10. Click the Edit link in the Actions column for the client that you want to edit. The Edit client-type page is displayed. The General properties are displayed by default.

  11. From the Properties pull-down menu, select the type of properties you want to change (for example, Software Platform).

  12. Change or add values for each property you want to alter.

    Tip –

    To clear your changes and start over, click Reset. To return to the display of client types without making any changes, click Cancel.

  13. Click Save to make these changes.

    If you do not click Save, your changes are not made. You must change one property type at a time and save those changes before you change another property type.

    The properties for this device are now changed, and the list of client types for this style appears.

  14. To verify that its properties are changed, find your client type in the Client Type list. Two asterisks added to the client type name indicate that you have customized this client type.

    Note –

    Whenever you change a default client type, a Default link is added to the Actions column. The Default link points to the internal library.

    To remove your changes and reset the client type's properties to their default values, click this link. A prompt asking whether you want to complete this action is not provided.

ProcedureTo Create a New Device by Inheriting Styles

  1. Log in to the Access Manager administration console as the administrator. By default, Identity Management is selected in the Header frame (the top horizontal frame) and Organizations is selected in the Navigation frame (the left vertical frame).

  2. Click the Service Configuration tab.

  3. From the Service Configuration frame on the left, under the Access Manager Configuration heading, click the arrow for Client Detection. The Client Detection global preferences appear in the Data frame on the right.

  4. Click the Edit link following the Client Types label. The Client Manager interface appears. Details about HTML devices are displayed by default.

  5. From the tabs at the top, click the markup language for the device you want to set up (for example, WML). If client types using the markup language you selected are in the database, they appear in alphabetical order.

  6. From the Style pull-down menu, pick the Style that you want (for example, Nokia). The list of client types already in the database appears for the selected style.

  7. Click the New Device button to display the Create New Device page.

  8. Type in the Device User Agent value.

  9. Click Next. The Device User Agent value you provided appears in the Client TypeName and The HTTP user-agent string fields.

    If appropriate, change these values.

  10. Click OK to save these properties. Your new device is now defined, and the Edit Style page appears. Displayed here are default properties inherited from the parent Style you assigned.

  11. From the Properties pull-down menu, select the properties type that youwant to modify (for example: Software Platform).

    Note –

    Properties type choices includeGeneral,Hardware Platform, Software Platform, Network Characteristics, BrowserUA, WapCharacteristics, PushCharacteristicsNames, and Additional Properties.

  12. Click Save to save your changes to these values.

    Tip –

    To clear your changes and start over, click Reset. To return to the display of client types without making any changes, click Cancel.

  13. Search the Client Type list to verify that your client type is available. Two asterisks added to the client type name indicate that you have customized this client type.

    Note –

    Whenever you add a new client type, a Delete link is added to the Actions column. The Delete link points to the external library.

  14. To remove your new client type, click this link. A prompt asking whether you want to complete this action is not provided.

ProcedureTo Create a New Device by Inheriting Properties

  1. Log in to the Access Manager administration console as the administrator. By default, Identity Management is selected in the Header frame and Organizations is selected in the Navigation frame.

  2. Click the Service Configuration tab.

  3. From the Service Configuration frame on the left, under the Access Manager Configuration heading, click the arrow for Client Detection. The Client Detection global preferences appear in the Data frame on the right.

  4. Click the Edit link following the Client Types label. The Client Manager interface appears. Details about HTML devices are displayed by default.

  5. From the tabs at the top, click the markup language for the device you want to copy (for example, WML). If client types using the markup language you selected are in the database, they appear in alphabetical order.

  6. From the Style pull-down menu, pick the default Style that you want (for example, Nokia). The list of client types already in the database appears for the selected style.

  7. From the Client Type list, scroll down to find the specific client that you want to use as a template for a new client type (for example, Nokia6310i_1.0).

    Tip –

    Clients are listed in alphabetical order.

  8. To go directly to a specific client type, or to a group of client types, use the Filter option. In the Filter text box, type in the first character or first few characters of the client type you want to view and then click the Filter button. (For example: To find a client type that starts with the letter S, type in S*.)

  9. To go directly to specific pages, scroll to the bottom and use the arrows or the Go option.

  10. Click the Duplicate link in the Actions column for the client type that you want to use as a template for a new client type. The Duplicate Device page is displayed. The Client Type and Device User Agent properties for the device you are copying are displayed, with the prefix Copy_of_ added to its name. (For example, Copy_of_Nokia6310i_1.0)

  11. If appropriate, type in new names for these properties.

  12. Click Duplicate to make these changes. The Edit client-type page is displayed. The General properties are displayed by default. The values for all properties views available here are inherited from the client type that you used as the master for this new client type.

    Tip –

    To return to the display of client types without making any changes, click Cancel. From the Properties pull-down menu, select which type of properties you want to change (for example, Software Platform).

  13. Change or add values for each property you want to alter.

    Tip –

    To clear your values and start over, click Reset. To return to the display of client types without making any changes, click Cancel.

  14. Click Save to make these changes.

    Note –

    If you do not click Save, your changes are not made. You must change one property type at a time and save those changes before you change another property type. The properties for this device are now changed, and the list of client types for this style appears.

  15. Search the Client Type list to verify that your client type duplicate is available. Two asterisks added to the client type name indicate that you have customized this client type. (For example, Copy_of_Nokia6310i_1.0 **)

    Note –

    Whenever you add a new client type, a Delete link is added to the Actions column. The Delete link points to the external library.

  16. To remove your new client type, click this link. A prompt asking whether you want to complete this action is not provided.

ProcedureTo Remove a Custom Device

If you set up a custom device incorrectly and do not want to modify it, you can use these steps to remove it entirely.

  1. Log in to the Access Manager administration console as the administrator. By default, Identity Management is selected in the Header frame (the top horizontal frame) and Organizations is selected in the Navigation frame (the left vertical frame).

  2. Click the Service Configuration tab.

  3. From the Service Configuration frame on the left, under the Access Manager Configuration heading, click the arrow for Client Detection. The Client Detection global preferences appear in the Data frame on the right.

  4. Click the Edit link following the Client Types label. The Client Manager interface appears. Details about HTML devices are displayed by default.

  5. From the tabs at the top, click the markup language for the device you want to delete (for example, WML). If client types using the markup language you selected are in the database, they appear in alphabetical order.

  6. From the Style pull-down menu, pick the Style that you want (for example, Nokia). The list of client types already in the database appears for the selected style.

  7. From the Client Type list, scroll down to find the customized client that you want to remove (for example, Copy_of_Nokia6310i_1.0).

    Tip –

    Clients are listed in alphabetical order

  8. To go directly to a specific client type, or to a group of client types, use the Filter option. In the Filter text box, type in the first character or first few characters of the client type you want to view and then click the Filter button. (For example: To find a client type that starts with the letter S, type in S*.)

  9. To go directly to specific pages, scroll to the bottom and use the arrows or the Go option.

  10. In the Actions column for the customized client that you want to remove, click the Delete link. The revised list of client types for this style is displayed.

  11. Search the Client Type list to verify that your client type is no longer available.

ProcedureTo Identify Selected Client Types for a Portal User From the Portal Server Console

  1. Log in to Portal Server administration console as the administrator. By default, the Common Tasks tab is selected and the Common Administrative Tasks page is displayed.

  2. Click the Portals tab. The Portals page is displayed. The available portals are displayed in the Portals table.

  3. Click on the name of the portal, which you want to manage. The Desktop Tasks and Attributes page is displayed. This page lists the Portal Server desktop tasks and attributes that you can edit.

  4. From the SelectDNoptions, choose the username (User) DN. If the username (User)DNoption is not available, you need to add this DN to the SelectDNlist. Follow the steps to add the username (User)DN.

    1. Click the Add DNs button. The Add to DNs list window appears.

    2. From the Search for options, choose the User option.

    3. Type the user name in the text box after the User option.

    4. Click Search. If the user name is available, it will be displayed in the Found table.

    5. Select the check box preceding to the user name you want to add and click Add The username (User)DN is added to the SelectDNoptions.

  5. From the list of Tasks, click the Manage Containers & Channels. The Manage Containers & Channels: Portal name page is displayed. The left frame in this page displays the available View Types and the right frame displays the properties of the selected View Type.

  6. From the ViewType options, choose the WirelessDesktopDispatcher option. The WirelessDesktopDispatcher Tasks and Properties are displayed in the right frame.

  7. In the Properties table, select the check box preceding to the selectedClients property.

  8. Click the Table Preferences button if you need to change the client type and locale settings. Client type settings are necessary to set a client type for the portal, and the locale settings are necessary to set the language attributes.

    The Table Preferences box appears at the top of the Properties table.

  9. In the Client Type and Locale fields, type the appropriate client type and locale information.

  10. Click OK.

  11. Click Save.

    The client type is added in the Value column.

Configuring Mobile Authentication

Portal Server Mobile Access software supports the authentication modules provided by Sun Java System Portal Server software. This chapter describes three authentication modules that can be useful to portal sites offering mobile access:

NoPassword Authentication

If your site specifications require it, you can allow users to log in to the mobile PortalDesktop without being prompted for a userID.

ProcedureTo Enable the NoPassword Module From the Access Manager Console

  1. Log in to the Sun Java System Access Manager administration console as the administrator. By default, Access Control tab is selected and the Realms page is displayed. You can see the available Realm Names in the Realms table.

  2. Click the india realm. The india?Properties page is displayed under which the Realm Attributes of india realm are listed.

  3. Click the Authentication tab. The india?Authentication properties are displayed. Check whether the NoPasswordModule Instance is available under the Module Instances table.

  4. Click the ldapService Authentication Chaining in the Authentication Chaining table. The ldapService?Properties page is displayed. The available Instances are displayed.

    Note –

    If you does not have the ldapService as the Default Authentication Chain or the Administrator Authentication Chain, then you would not be enforced for NoPassword Authentication. If NoPassword authentication is required, then add the NoPassword to the respective configured Authentication Chain. For Default Authentication Chain, add the NoPassword to the respective configured Authentication Chain. In the default installation scenario both will be configured for ldapService.

  5. Choose the NoPassword instance.

  6. Click the Add button. The NoPassword instance is added to the Instance list.

  7. Click the Save button. You will get the information that the authentication chain properties were updated.

  8. Click the Logout button.

  9. Try to login again to the Sun Java System Access Manager administration console. You will get a message that This server uses NoPassword Authentication.

Anonymous Authentication

If you want a user to access your portal site to explore what the experience of an authenticated user is, you can allow users to log in to the mobile Portal Desktop as anonymous users. This feature presents a snapshot of the mobile and voice Portal Desktop of a user with an authenticated session.

Note –

Anonymous users cannot change, store, or alter the content or configuration of channels with stateful data. If you support anonymous authentication, make sure that these channels are not available to these users.

To implement anonymous authentication, see the Sun JavaTM System Portal Server 7.1 Administration Guide.

The Portal Desktop for anonymous authentication uses the WirelessDesktopDispatcher as well as device-specific containers for both JavaServer PagesTM (JSPTM) software and templates. All channels to be displayed to the anonymous user must be included in these containers, just as they are for authenticated users.

ProcedureTo support a new device that may need a client-specific mobile or voice PortalDesktop for an anonymous user.

  1. Create the appropriate device-specific container.

  2. Alter the WirelessDesktopDispatcher in the anonymous user?s display profile to use the new container for that particular device type.

MSISDN Authentication

The users of an organization can be configured to authenticate using MSISDN-Mobile Station ISDN, a standard international telephone number used to identify a given subscriber. This allows the users to log into the mobile portal desktop without the user passing authentication credentials. This feature limits the format of the login URL. The following format for the URL is recommended:

http://access-manager-host:port/service-deploy-URI/UI/Login?module-MSISDN&org-name

To implement MSISDN authentication and how to configure it, see the Sun Java System Access Manager 7 2005Q4 Administration Guide.

Managing the Mobile Portal Desktop

Portal Server Mobile Access software uses the Portal Server administration console to manage the mobile Portal Desktop.

Note –

In order to understand the information provided in this chapter and manage the mobile Portal desktop, you need to know the Portal Server administration console.

This section discusses the following topics:

Understanding the Wireless Desktop Dispatcher

Once you install Mobile Access software, your Portal Server site provides a mobile Portal Desktop as well as a standard Portal Desktop. At the time a user logs in to Portal Server, the wireless desktop dispatcher, which is a component of Mobile Access software, determines which Portal Desktop is the appropriate one to route user requests to. The wireless desktop dispatcher uses an XML Display Profile configuration to determine which Portal Desktop—standard, mobile—is the appropriate one to route user requests to.

The wireless desktop dispatcher:

The default channel for the mobile Portal Desktop is the WirelessDesktopDispatcher. Follow the steps to edit the WirelessDesktopDispatcher container from the Portal Server 7.2 administration console to support other containers for particular devices.

ProcedureTo Edit the Parent Container in Portal Server 7.2 Administration Console

  1. Log in to the Portal Server 7.2 Administration Console as administrator.

  2. Click the Portals tab. The available Portals are displayed.

  3. Click on the name of the Portal, which you want to manage.

  4. Choose the Org option from the SelectDN drop down list box. The Desktop Tasks and Attributes page is displayed. The Parent Container attribute is available under the Desktop Attributes. The top level container value in the display profile for the selectedDN is displayed in the Parent Container text box.

  5. Edit the value in the Parent Container text box to support other containers for particular devices.

  6. Click Save.

Wireless Desktop Dispatcher Properties

This section describes the properties listed for the WirelessDesktopDispatcher container.

The wireless desktop dispatcher properties include:

This property is also used to display a list of devices on the Mobile Devices edit page in the standard Portal Desktop. Individual users can view what devices they have used, and they can add to the list simply by logging into the mobile Portal Desktop with other devices.

ProcedureTo Navigate To the WirelesDesktopDispatcher Container Properties Page

  1. Log in to the Portal Server 7.1 Administration Console as administrator. The Common Administrative Tasks page appears.

  2. Under Configuration, click the Manage Channels & Containers button. The Data Collection pop up window appears.

  3. From the Select Portals drop down list box, choose the Portal you want to manage.

  4. From the SelectDNdrop down list box, choose the DN.

  5. Click OK. The WirelessDesktopDispatcher container tasks and properties are listed in the right frame. You can modify the values of these properties in this page.

  6. Edit the value in the editContainerName text box, to suit the appropriate device.

Conditional Properties

Conditional properties for client types enable administrators to specify properties for a channel or container channel that are specific to a client type. Conditional properties for client types can also be hierarchical, just as client data is hierarchical.

The syntax for a conditional property is client=clientType. For example, client=WML is the name of the conditional property for WML client types.

The desktopContainer property for the wireless desktop dispatcher is an example of a client conditional property for the client type client=WML.

Here is a hierarchical representation of the default desktopContainer property forNokia devices:

client=Nokia —> desktopContainer=JSPNativeContainer

The subset of WML clients defined by the Nokia client style use a different desktopContainer definition, however. They use the JSPNativeContainer.

Channel State Properties

These properties indicate the state of a channel to both the JSPNativeContainer . They allow an end user to display only a channels title bar on a mobile PortalDesktop instead of loading a channels content inline.

Note –

On the standard Portal Desktop, you can provide buttons on a channel so that the user can minimize or maximize its content. This is not currently supported with the mobile Portal Desktop.

These properties include: