Novell is now a part of Micro Focus

How to Build a Personalized, Secure Web Portal Using eDirectory, iChain, and Corporate Yahoo! Enterprise Portal

Articles and Tips: article

Karl Bunnell
Senior Software Engineer
Novell Developer Solutions
kbunnell@novell.com

01 May 2002


This AppNote describes how to use Novell eDirectory and iChain along with the Corporate Yahoo! Enterprise Portal to build a personalized, secure Web portal that provides authentication, single sign-on, identity services, and Web acceleration.


Topics

Yahoo! Portal Builder, Novell eDirectory, iChain

Products

Novell eDirectory 8.6, iChain v2.0, Yahoo! Portal Builder 4.0

Audience

network administrators

Level

beginner

Prerequisite Skills

HTML, iChain/eDirectory/LDAP installation and configuration

Operating System

Windows NT, 2000

Tools

ConsoleOne, iChain Administration Console

Sample Code

no

Introduction

The topic of Web portals has generated a lot of excitement in the industry as players rush solutions to the market that promise to solve many of the problems inherent to the first generation of Web applications. The promise of a scalable, secure Web portal that serves content based on identity has at its root a dependence on a scalable, reliable, blazing fast directory service coupled with a Web security infrastructure that provides authentication, single sign-on, identity services, and Web acceleration.

Novell eDirectory provides a proven directory service that scales to millions of objects while maintaining industry-leading search performance. Novell iChain provides Web authentication using eDirectory, access control to Web resources based on identity, single sign-on to Web applications, and Web acceleration. A third tool, Corporate Yahoo! Enterprise Portal, integrates leading enterprise applications with rich Yahoo! content and Web services that allow companies to customize and present personalized business information to employees, customers and partners.

Note: Corporate Yahoo! Enterprise Portal is the name of the overall portal solution from Yahoo!. The portal software and tools are referred to as Yahoo! Portal Builder and will be referenced using the acronym YPB throughout the remainder of this AppNote.

The combination of eDirectory, iChain, and YPB finally deliver on the promise of a secure, scalable Web portal that provides granular access control, personalization based on directory services identity, single sign-on, and Web acceleration. The purpose of this AppNote is to familiarize you with YPB and describe how to integrate these three technologies to provide personalized Web content by leveraging your eDirectory identity via iChain authentication and delivering the personalized content via YPB.

This AppNote is not intended to be an exhaustive installation tutorial for eDirectory, iChain, or YPB. Rather, it is intended to familiarize you with YPB and how it works together with iChain and eDirectory to provide an end-to-end portal solution. For more information about eDirectory and iChain, visit http://www.novell.com/products. For more information about YPB, visit http://site.corporate.yahoo.com.

About Yahoo! Portal Builder

Overshadowed by the tragic events of September 11, 2001, was a joint press release from Novell and Yahoo! made at NetWorld+Interop that described two key areas around which a new partnership between the two companies would revolve:

  • Yahoo! will include Novell's eDirectory as the default directory server for Corporate Yahoo! enterprise portal deployments

  • Novell will provide solutions built around Corporate Yahoo! portal technologies

(See http://www.novell.com/news/press/archive/2001/09/pr01088.html for the full press release.)

YPB provides the capability to aggregate the popular My Yahoo! content and services (http://my.yahoo.com) with corporate content and applications from behind existing corporate firewalls. According to Nielsen/NetRatings' latest rankings, Yahoo! is the most visited property at work. By building a corporate portal that includes the most popular, personalized content on the Web combined with corporate applications and services, YPB presents a "sticky" portal which the corporate community will want to use as a home base as they access corporate and Internet resources.

Installing Yahoo! Portal Builder

The first time you run the YPB installation wizard, you will create a YPB deployment. A YPB deployment consists of the Portal Engine (series of Java servlets) and a number of additional required components.

YPB can be installed on the following platforms:

  • Microsoft Windows NT 4.0 Server with Service Pack 5 or higher

  • Windows 2000 Server with Service Pack 2

  • Sun Solaris 2.7 or 2.8

  • HP-UX 11

At a minimum, when installing YPB you'll need the following:

  • Web server (NetScape Enterprise Web Server or Microsoft IIS are the supported Web servers)

  • Java servlet execution environment (included with iPlanet, JRun required for IIS)

  • Java Virtual Machine (JVM)

  • LDAP version 3 directory server

  • Access to a relational database (Microsoft SQL Server or Oracle)

The YPB install routine verifies that these prerequisite components exist before allowing the installation to begin. Once the installation wizard has successfully guided you through the installation process, you'll have a single deployment, which consists of a set of one or more YPB servers (instances) configured to provide portal services to a community of users. Subsequently, you can install additional instances of YPB servers that all belong to the same deployment. Each instance shares the configuration of a single deployment and works in parallel with other instances to provide an extensible, scalable portal service.

Step-by-Step Installation Procedure. Let's take a closer look at the series of steps you'll take as the YPB installation wizard guides you through the install.

  1. First, the wizard presents a series of windows that prompt you for the location of the Java Runtime Environment, the portal content encoding (default is UTF8), the default locale (English), and proxy server information.

  2. You are next presented with a few screens that merit further description. The first is the "Authentication Settings" window, shown in Figure 1.

    The YPB "Authentication Settings" window.

    The Authentication Method selection made in this window dictates how users will authenticate to the portal system. This selection cannot be changed at a later date without re-installing the portal. Which method to select depends primarily on what you want to use as the source for user authentication.

    For example, if you choose "Cookie Authentication," the portal completely handles authentication. Users are created and maintained in the YPB local repository.

    If you have a corporate directory you want to use for authentication so that applications can leverage a single corporate identity (user ID and credential), select "Web Server Authentication." This configuration delegates the responsibility of authenticating users of the portal to the Web server. Authentication is performed using the HTTP or HTTPS authentication built into the browser. The Web Server is configured to validate supplied user credentials against your corporate LDAP server.

    Note: In order to use iChain for seamless authentication to YPB, you must select Web Server Authentication! The other authentication options allow alternate authentication sources to be used.

  3. The next window of interest is the "LDAP Settings" window. YPB uses an LDAP repository as its underlying database for storing information about categories (content selections), pages, roles, and deployment information. The YPB install program extends the schema of the LDAP repository specified in this window to include 65 new object class definitions and over 400 new attribute class definitions. YPB uses these definitions to create the object hierarchy it requires to manage the portal deployment including defining roles, personalized content subscriptions, page definitions, users, and groups. (I'll explain more about this under the section entitled "eDirectory and Yahoo! Portal Builder").

  4. The next window is the "JDBC Connectivity" window. Connectivity to a relational database (Microsoft SQL Server or Oracle) is required for storing information for the content publishing system, user alert histories, and persistent content (used to maintain headline history and so on).

  5. Next the installation wizard presents you with a "Yahoo! Settings" window. Here you specify the Yahoo Account credentials required by YPB to retrieve Yahoo! content from the My Yahoo! content servers. You are provided a Yahoo! portal ID and password when you purchase the product. Once a user is authenticated to YPB, it associates the user's corporate ID with the user's My Yahoo! ID to provide the YPB user with customized corporate content as well as personalized My Yahoo! content. These settings are used to authenticate to the content servers and retrieve the My Yahoo! personalized content and aggregate it with corporate content.

  6. You also specify the "Model Account" in this window. Model Accounts are used to define default personalization settings for Yahoo! content categories. A Model Account can then be associated with a role so all occupants of the role share the same personalization settings. For example, you may want all occupants of a role named "Provo Engineering" to have the same content personalization settings for weather, business news, and stock portfolio. To accomplish this, you simply define a Model Account that has the personalization settings you desire for the content categories, then associate this model account with the "Provo Engineering" role. In addition to receiving a Yahoo! portal ID and password, you are also provided a password that allows you to define or modify Model Accounts.

  7. At the bottom of the Yahoo! Settings window is a checkbox entitled "Import". Check this box if you want to import Yahoo! content categories and a default (example) portal at installation time.

  8. Finally, the installation wizard presents a window that allows you to specify the Web server and servlet execution environment you want to use. Based on these settings, the install program will automatically configure the specified Web server to support the Java servlets that comprise the majority of the YPB system.

  9. YPB requires that an instance of the Tibco Rendezvous (referred to hereafter as RV) messaging framework be installed on that same host as the portal engine. RV is a distributed messaging framework that allows applications to share information in a reliable, fault-tolerant manner across disparate machines on an interconnected network. This framework allows multiple instances of YPB to keep such things as configuration information, content subscriptions, and database changes synchronized between multiple instances of YPB in a deployment. If RV is not already present on the host, the YPB install program detects this and installs the appropriate build automatically.

Configuring Yahoo! Portal Builder

Once the YPB installation completes, the product is ready to be configured using the Portal Administration utility. This utility is accessed via a Web browser by entering the following URL: http://host-web-server/portal_admin where host-web-server is the Web sever where YPB is installed.

Portal Administration from the User's Perspective. Before we jump into the details of how to configure YPB, let's take a look at some of the visual components that comprise the portal view when accessing YPB as a user of the portal. To access YPB the first time as a user, direct your browser to the following URL: http://host-web-server/yahoo

If YPB has been configured to use Web Server authentication, you will be presented with the HTTP authentication dialog box. The Web server should be configured to validate credentials against your corporate LDAP directory. Once authenticated, you'll be presented with a page similar to the one shown in Figure 2.

Notice that you are presented with three options: (1) I have a Yahoo! ID, link it now; (2) I do not have a Yahoo! ID, sign me up; and (3) I do not want a linked Yahoo! ID, continue without linking.

The Novell Enterprise Portal Development welcome page.

What is this Yahoo! ID linking stuff all about? Recall that YPB connects to the My Yahoo! content servers to retrieve personalized content. The first time you authenticate to YPB, you'll be presented with this page so you can determine for yourself how you would like your My Yahoo! ID to be linked to YPB (your corporate portal):

  • If you are already one of the millions of users of My Yahoo! and you have an ID, simply link to it.

  • If you do not have a My Yahoo! ID, select the middle option to create one.

  • If you are not interested in having a separate My Yahoo! ID, select the option on the right.

The benefit to linking to a My Yahoo! ID is that all personalization settings you have established with your My Yahoo! account will automatically be reflected in the corporate portal. Even cooler is the fact that these personalization settings will be identical whether you use your YPB corporate portal at work or your My Yahoo! account from home. Personalization changes made in either place will be reflected in both. You only have to link this ID the first time you authenticate to the YPB portal. YPB will remember how you have chosen to link your ID and never prompt you for it again.

Figure 3 shows an example of the portal view you might see once you are authenticated to the portal.

Sample portal view for an authenticated user.

Content Categories

If you are a My Yahoo! portal user, the "look and feel" of this interface will be very familiar. The contents of the portal view consist of a portal page that represents default content categories defined for the user.

An example of a content category is the "Weather" category (surrounded by a blue box). The content categories are placed in "panes" (columns) that serve as containers for category content. The portal administrator can easily customize the look and feel of the portal view to match the corporate standards by altering existing HTML templates that contain YPB custom tags. Any individual with rudimentary knowledge of HTML can easily customize the templates that make up the look and feel of the portal.

You can personalize the content categories on the portal page by clicking the "Personalize" link (upper right). This operation presents you with a page that details the content categories you can select from to organize content on the page according to your preference. Of course, the content categories presented to you depend on the rights granted you by the administrator. Some panes (category containers) can be defined to be user-controlled, while the administrator may choose to lock down other panes so only administrator-defined content can reside there.

Portal Administration for the Administrator. Now that we've seen what a user of YPB sees, let's take a look at what the YPB Portal Administration utility looks like to the administrator. Figure 4 is a screen shot of a typical Portal Administration utility window.

The YPB Portal Administration utility "Categories" window.

Listed along the top are tasks the portal administrator can accomplish. The "Categories" selection allows you to create new content categories, organize them, and define presentation options and access to them. YPB comes with a rich set of content categories available for the Yahoo! content servers.

Defining New Categories

In addition to the predefined Yahoo! Categories, you can define categories that expose corporate business applications, corporate news, e-mail, and so on. The screen shot in Figure 5 shows some of the available Category Types that can be defined.

Defining new category types.

Each category type represents a mechanism used to expose content from a variety of different sources. For example, the "Database" category allows you to define a relational database as the content source for the category, specify the SQL used to retrieve specific data (such as sales data for a region), and make the category available as a selection for personalizing a portal page. An XML category can be defined that retrieves the content from an XML source and renders it in YPB using XSLT style sheets. A SOAP category can be defined to retrieve content from a SOAP source.

In addition to the Category Types listed, YPB includes a developer API (Application Programming Interface) that allows you to define custom category types.

Other Administrative Tasks

Other tasks you can perform as the Portal Administrator include the following:

  • Portal Pages. Define the layout and "look and feel" of your portal, as well as access control to pages for users and administrators

  • Users/Groups. Define/view users and groups that can access the portal

  • Sessions. Add/modify content sources

  • Roles. Assign users and group membership to roles and define access control to portal pages for both users and administrators. For example, roles can be used to delegate responsibility to portal administrators to customize the portal view to suit the needs of a specific role or geographical region.

  • Server Settings. Manage portal deployment and instance settings

The details of defining content categories and portal pages and establishing roles for who can access and configure the portal are too vast to cover in this AppNote, but that will be the subject of a follow-up AppNote. Hopefully this brief overview has given you a good idea of what is involved from both the user and administrator perspectives.

Yahoo! Portal Builder Architecture

The Yahoo! Portal Builder software consists of a set of services that provide personalized content to users over standard protocols suitable to the interface used to view the content. Figure 6 is a block diagram of the overall architecture.

The portal services are a series of Java servlets that run within the context of a Java Servlet execution environment supported by the Web server (center box in Figure 6). Multiple instances of YPB can be installed within a deployment, each running on its own Web server/Java servlet environment. As mentioned previously, you can deploy additional instances to work in parallel to create an extensible, scalable system able to adapt as performance demands on the system increase.

YPB architecture.

An individual instance need not enable all services; instances can be dedicated to run selected services according to the performance demands of the system. For example, the Content Manager service is dedicated to retrieving content from the content sources (left box in Figure 6) defined in the content categories. If a particular deployment has many content sources from which content categories are constructed, multiple Content Manager services can be enabled on multiple YPB instances to distribute the load.

The Presentation Manager service communicates with the Content Manager service to render the content categories and deliver them to the user on the requesting device via the appropriate protocol (right box in Figure 6).

The specific function of the other portal services is evident from their names.

  • The Local Repository (eDirectory) serves as the persistent store for an entire deployment. All instances are configured to communicate with the same LDAP Local Repository. It is used to store all deployment configuration settings, content subscriptions, user profiles, group memberships and role definitions. Essentially any metadata required by YPB is stored in the Local Repository.

  • The RDBMS repository is used to store user alert histories, persistent headlines, and some content publishing information. (Persistent headlines are a great feature. Have you ever returned to your office after time away and wondered what news you missed? If a news category is configured to use persistent headlines, you can review past news stories!)

  • The Corporate LDAP Repository works in conjunction with the Web server (if Web Server Authentication is selected) to authenticate users and serve as the source for users, groups and group membership. (More information about this follows.)

It is important to understand that the Tibco Rendezvous (RV) messaging bus connects all instances of a deployment. This allows all instances of a deployment to work together as an interconnected framework of services providing fault-tolerance, excellent division of labor, and optimized distribution of workload.

eDirectory and Yahoo! Portal Builder

The press release referenced at the beginning of this AppNote highlights the fact that YPB 4.0 will include eDirectory as the default directory server. YPB has a significant dependence on a highly-scalable, reliable directory. At the heart of YPB is the ability to associate user identities with content personalized for the specialized needs of the connected users. In this section, we'll explore that ways in which YPB 4.0 utilizes the directory.

Yahoo! Portal Builder 4.0 leverages an LDAP repository in two distinct ways:

  • The Local LDAP repository is used for storing information about content categories, category subscriptions, portal page definitions, role definitions, user profiles, group membership as well as deployment configuration information.

  • The Corporate LDAP repository is used as a source for users and groups for purposes of synchronizing group and group membership information to the Local LDAP repository.

Let's take a closer look at how YPB uses each of these LDAP repositories.

Local LDAP Repository

YPB uses an LDAP repository for its underlying database. The YPB installation routines extend the schema to include all of the object and attribute classes required to create the underlying database objects. In addition to extending the schema, the YPB installation routines also create the object hierarchy that represents the object store used by YPB to store all metadata required by the portal services. Figure 7 is a screen shot from ConsoleOne of the object hierarchy created by YPB.

The object hierarchy created by YPB.

The YPB objects are created beneath the Organizational Unit (OU) container named TIB/PB. This container is created beneath the "Base DN" location specified in the "LDAP Settings" window of the installation program. All objects created beneath the TIB/PB container are derived from the schema extensions added by the YPB install routines. Among the hierarchy of objects you will find the following:

  • The usr container contains the user ID (cn) of users that successfully authenticate to the Corporate LDAP server (via iChain and the Web server authentication). Each "user" object and subordinate objects maintain information about content category subscriptions, profile information and access control information for users of the portal.

  • The grp container contains a list of groups synchronized from the Corporate LDAP server (more on this in a moment). The "group"objects are used extensively to define a group of users as role occupants when defining access control to view content as users as well as for administrators that use the YPB administration utility.

  • The dep object and subordinate objects contain the deployment configuration settings.

  • The schema object and subordinate object contain the schema definitions used by YPB. If you are familiar with how to extend the schema with LDIF, these definitions will look familiar. The YPB installation routines use these schema definitions to validate the schema version when upgrading to new versions of YPB.

The entire YPB hierarchy consists strictly of objects defined by the YPB schema extensions. All administration for this object hierarchy is performed using the browser-based Yahoo! Portal Builder administrator utility. Novell's ConsoleOne utility can be used to browse these objects, but it should not be used to modify any objects in the YPB hierarchy.

Note: YPB requires new features, such as Persistent Search, present in eDirectory 8.6.2 in order to function properly. Previous builds of eDirectory (8.5 or earlier) cannot be used as the Local LDAP repository for YPB.

Corporate LDAP Repository

The previous section outlined the fact that YPB uses the Local Repository to store user and group information, which brings up the question: What is the role of the Corporate LDAP repository? It is used in three ways:

  • As the authentication source for the Web server (and iChain)

  • As the source for users and groups to be synchronized to the Local LDAP repository

  • As the source for user profile information (directory attributes such as title, department, and so on, can be used to further personalize content within the portal)

You might be asking yourself, why not simply have a single directory that serves as both the Local Repository and the Corporate Repository? The approach of YPB is to minimize intrusion on the corporate directory while still leveraging the identity (credentials) of the corporate directory. The recommended configuration is to install a separate eDirectory deployment (tree) for use as the Local Repository for YPB and configure YPB to synchronize only the required user identity information from the Corporate Repository. YPB uses the Local Repository extensively, creating potentially millions of objects, submitting frequent complex searches as well as extending the schema to accommodate hundreds of new schema definitions to support its object hierarchy.

The approach to separate the Local Repository from the Corporate Directory simplifies deployment, eliminates additional performance demands on the corporate directory, removes the requirement to make schema extension changes to the corporate directory, and ensures the Local Repository tree design can be constrained in scope to optimize performance for both searching and synchronization.

As mentioned previously, the Corporate LDAP repository can only be used in the "Web Server Authentication" (WSA) configuration of YPB. Other authentication methods use the Local Repository exclusively for users, groups, authentication and access control. In the WSA configuration, YPB delegates the responsibility of authenticating the user to the Web server and retrieves the user identity from the HTTP header.

If the user submits invalid credentials, the Web server will deny access before access to YPB is possible. If the Web Server successfully validates the authentication of the user, YPB considers the user a trusted user of the YPB system and creates an object that represents the user beneath the "usr" container in the Local Repository.

After the first successful login to YPB, all associations concerning content subscriptions, access control, role associations, and so on, are based on the user identity in the YPB Local Repository. So how does YPB know what groups the connected user is a member of in the Corporate Repository? That information is synchronized from the Corporate LDAP Repository. You "point" YPB to the Corporate LDAP repository by defining the source for users and groups under the "Server Settings" selection of the Portal Administration tool. Figure 8 is a screen shot of the window used to specify this information.

The "Edit Deployment Settings" window.

The "LDAP URL" points to the Corporate LDAP repository, the same used by the Web server (and iChain) for authenticating the user. The identity used by YPB to bind to the Corporate LDAP need not be an object with admin-equivalent rights. The object must have rights to browse for "group" objects and to read the "uniquemember" attribute. These credentials are used by YPB to establish the "Persistent Search" connection required to synchronize groups and group membership as we discussed earlier.

The "Synchronization Type" radio button specifies the method used to retrieve this group information. If the LDAP server referenced by the LDAP URL supports Persistent Search functionality, YPB will detect this and automatically set this type to "Dynamic". If the LDAP server is an eDirectory build prior to 8.6.2, this type will be set to "Periodic". This implies that YPB will periodically poll the specified directory for changes.

Note: AlthoughYPB will support versions of eDirectory prior to 8.6.2 as the Corporate LDAP Repository (source for user and groups), using "Dynamic" (persistent search) is more efficient and less bandwidth intensive than the "Periodic" (polling) method.

Integrating iChain and Yahoo! Portal Builder

As described at http://www.novell.com/products/ichain, iChain provides identity-based Web security services that control access to application and network resources across technical and organizational boundaries. In other words, iChain provides the infrastructure to enable true Web application single sign-on, granular access control to Web applications, encrypted channel to protected resources, as well as accelerated access to Web content using industry-leading caching technology. At the heart of iChain's authentication and access control capabilities is eDirectory, which serves as the repository for user identity, profile information and access control definitions.

Configuring iChain as the YPB Authentication Source

This section outlines the procedure to follow in configuring iChain as the authentication source for YPB.

The steps below assume that iChain v2.0 has already been installed and that you have experience configuring iChain using the iChain Web Administration console and the iChain ConsoleOne snap-ins. For more information on how to install and configure iChain, see the following AppNotes:

Note: Although these AppNotes were written for iChain 1.5, the information relative to installing and configuring the product remains accurate.

Step 1: Create an Authentication Profile

To begin, use the iChain Web Administration Console to create an "Authentication Profile". The authentication profile defines the method used by iChain to authenticate a user to an accelerated Web resource.

Creating an authentication profile.

As shown in Figure 9, perform the following steps to create the Authentication profile:

  1. Select the Authentication tab and click the Insert button. Provide a name that describes the profile (for example, "LDAP Profile").

  2. Select the "LDAP Authentication" radio button and define the LDAP profile options by clicking on the "LDAP Options" button.

  3. In the LDAP Options window, specify the information required to bind to validate user credentials against the Corporate LDAP repository.

Note: The bind information specified here must match the bind information used by the Web Server to authenticate the user to YPB.

Step 2: Create a Web Server Accelerator

Next, use the iChain Web Administration Console to create a "Web Server Accelerator" for the Web server where YPB resides. To do this, select the Web Server Accelerator tab and fill in the required information as shown in Figure 10.

Creating a Web Server Accelerator.

This creates an accelerated connection pathway that places the iChain reverse proxy in front of the Web server to be accelerated, ensuring that all access to the accelerated Web server (YPB in our case) is directed through iChain. This allows iChain to govern access to YPB and all other configured Web applications in the enterprise, thus providing a single point of administration for Web resources and a single point of authentication to such.

Step 3: Enable Authentication

Next, use the iChain Web Administration Console to modify the Accelerator you just defined in Step 2 and enable it to require authentication using the authentication profile defined in Step 1.

Enabling Web Server authentication.

As shown in Figure 11, perform the following steps to accomplish this task:

  1. Select the Web Server Accelerator you want to modify from the Web Server Accelerator page.

  2. In the ensuing "Web Server Accelerator" window, enable authentication by checking the box entitled "Enable Authentication".

  3. Define the authentication profile to use by clicking on the Authentication Options button.

  4. In the "Add Authentication Profiles" window, check the box entitled "Forward authentication information to web server". This ensures that the HTTP authentication header information is forwarded to the Web server that hosts YPB.

  5. Highlight the authentication profile you defined in Step 1 and click on the Add button to select this authentication profile.

Step 4: Enable OLAC

Now use the iChain Web Administration Console to enable the "Object Level Access Control" feature of iChain. Accomplish this by checking the box entitled "Enable Object Level Access Control" (OLAC) on the Access Control page. You must ensure that the IP Address specified on this Access Control profile panel matches the one used for the Authentication Profile defined in Step 1.

The OLAC feature enables iChain to add name/value pairs to the HTTP header, as well as define what attributes are defined in this header. The value added to the HTTP header is retrieved from the authenticated user's LDAP attributes. By default, iChain adds the user's full distinguished name (for example, cn=kbunnell,o=novell) as the "User ID" portion of the HTTP authentication credential. We need to configure OLAC to instruct iChain to send only the CN (common name) value (for example, kbunnell) as the User ID portion of the HTTP authentication header. YPB requires that the user ID be in this format.

Step 5: Define the OLAC Parameters

Finally, we need to use ConsoleOne and the corresponding iChain snap-in to define the OLAC parameters.

Defining the OLAC parameters.

As shown in Figure 12, find the iChain Service Object (ISO) and select to edit its properties. Perform the following steps:

  1. Create a protected resource and define the "Access" value to "Restricted". This ensures that in order to access the URL identified by the protected resource the connecting user must authenticate before accessing it.

  2. Highlight the "Protected Resource" that corresponds to the YPB server then click the "OLAC parameters" button.

  3. On the ensuing "OLAC Parameters" panel, define an OLAC parameter with the name ICHAIN_UID with a "Data Source" value set to LDAP and the "Value" set to cn.

Under normal circumstances the "Name" of the OLAC parameter can be whatever you choose; however, recall that we want to instruct iChain to change the User ID value in the http base-64 encoded header with an alternate value. The ICHAIN_UID value is a special identifier that instructions iChain to bypass the default behavior and replace the LDAP full distinguished name value with the cn (common name) value.

Once you have completed these steps, refresh the iChain appliance to enable the changes to take effect.

Conclusion

This AppNote has described how a combination of eDirectory, iChain, and Yahoo! Portal Builder 4.0 formulate an end-to-end portal solution that finally solves the hard problems related to providing identity-based personalization and securing Web-based applications that scale to meet the needs of the intranet, extranets and the Internet.

How to Get Hands-On Development Help

Novell Developer Labs is available to assist developers who would like hands-on help with integrating their products with Novell technologies such as Novell eDirectory, LDAP, DirXML, Novell Portal Services, Novell Modular Authentication Services, and many more. For more information about how you can take advantage of Novell's convenient lab facilities, engineering assistance, and related resources, visit http://developer.novell.com/devlabs/.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates