7.5 WebSphere Portal Solution guidelines

When you implement one portal solution, it is possible to integrate information from multiple sources in your company in a single point of access. In this case, you have one infrastructure to support different types of devices and data sources.

Create components with object-oriented design principles. Design Portlet applications according to good object-oriented design principles with loosely coupled , encapsulated components to maximize the opportunity for reuse.
Avoid writing Java code in JSP: use Java beans to encapsulate the interface operation.
Understand the customer's problem: take the time to fully understand the requirements of a comprehensive user profile to support all related applications before starting the application design process.
Understand Portal Solution; use the Portal in the way it was intended: as a framework for aggregating application components. Design JSPs, servlets, beans, and so forth, to handle all of the business processing and plug into the portal framework rather than developing portlets. This will maximize flexibility of the solution and reduce platform independence.
To avoid making default portlets user-customizable, create a default page using custom portlets and persistence based on a key comprising the page, portlet, and user ID to allow for a default page. Do not use the default persistence model for shared portlets; changes made by one user will be seen by all.
A clear definition of success and measurement criteria at the beginning of a portal effort is critical. Clear definitions of the goals, functions, and measurable success criteria will help lead to a successful effort.
Existing business rules must be evaluated and potentially changed to fit into the user experience.
Consumer trend data must be constantly monitored and acquired , internally and externally, to be useful. Applications must be developed with flexibility. The vast amounts of data that can be collected must be managed and transformed to be worthwhile.

This solution should cover many functionalities and provide flexibility for the user. The Portal Solution provides some concepts to help you achieve this level of quality. These concepts, such as Single Sign-On, personalization and internationalization, are ones that the developer should take into consideration when developing the solution.

7.5.1 Internationalization

Today's international high-tech marketplace has created a need for global applications and Web-delivered content. As more and more companies attempt to accommodate their customers' needs and internationalize their offerings, the challenges of managing the technology and resources are emerging.

Included in the Java 1.1 API are the java.text package and the ResourceBundle classes contained in the java.util package, which together with the Locale classes make up the backbone of localization on the Java platform. Resource bundles use a cascading mechanism to provide the best translation support with the minimal amount of work for both the developer and resources of the computer. In this scheme, the developer creates files that define a lookup table for translation and adds encoding to the names of these files to specify the locale of the file.

Portal aggregation allows you to package JSPs to support multiple markups , clients , and locales. JSPs that contain mostly text, such as help JSPs, can be translated directly rather than storing strings in a resource bundle. You need to store JSPs that do not use resource bundles in the appropriate localized location. When a portlet uses a JSP for rendering the portlet's content, the portal searches for and selects the proper JSP based on the client type (including browser), markup language, and locale indicated in the request. To include a JSP in a portlet, use the function PortletContext.include() :

 getPortletConfig().getContext().include(jsp_path/jspname.jsp,    portletRequest, portletResponse);

To support multiple markup types and locales, the portlet's JSPs must be packaged in the WAR. The elements in this structure are as follows .

jsp_path: a path defined by the developer. For example, JSPs can be located in the root of the WAR file or in a JSP directory. However, this path must not include mime-type/language_country_variant. The include() method already locates the correct JSP also in those directories.
markup_type: either html, wml, or chtml .
language: the language for this JSP, for example: en, ja, or pt .
country: the country of the JSP, for example: US, UK, or BR.
client: the type of device. For example, this could indicate a JSP with browser-specific markup, such as IE or NS4. Manage Clients Help describes how clients are identified by the portal server.

The directory structure is:

 jsp_path/markup_type/language _country/client/jspname.jsp

You can find more information about internationalization at the following site:

http://java.sun.com/docs/books/tutorial/i18n/

7.5.2 Session

The PortletSession holds user-specific data for the virtual instance of the portlet. Virtual instances differ from each other only by the data stored in their respective PortletSession or objects. The PortletSession contains transient data for the portlet virtual instance. Any persistent data must be stored using PortletData. Information stored in a portlet's class variables is shared between all virtual instances, with read and write access. Make sure you do not use class attributes for user-specific data. On the other hand, you have to be cautious about what the portlet adds to the session, especially if the portlet ever runs in a cluster environment where the session is being serialized to a shared database. Everything being stored in the session must be serializable too.

Like an HttpSession, a PortletSession is not available on an anonymous page.

During login, a PortletSession is automatically created for each portlet on a page. To get a PortletSession, the getSession() method (available from the PortletRequest) has to be used. The method returns the current session or, if there is no current session and the given parameter "create" is true, it creates one and returns it.

When you are working with Session, the Portal Application Server creates a session cookie to maintain the data from PortletSession.

We have three different ways to manage this cookie.

The browser should accept cookie from the server. This cookie will still be on the client and when the client closes the browser, this cookie will be removed from the client machine. In another words, this cookie will exist while the session is alive .
With WAP, the cell phone should support the cookie. The older phones do not support the cookie; in this case, it is necessary to install software to manage this cookie for you, such as WebSeal.
With PDA the device should accept the cookie. The behavior of the PDA is similar to the Web browser.

7.5.3 Personalization

Personalization is about tailoring Web content and applications to specific users. This is done by gathering and storing information about site visitors , analyzing the information, and based on the analysis, delivering the right information to each visitor at the right time. A number of techniques can enable your site to personalize news feeds, recommend documents, provide advice, target e-mail, target advertising, and promote products.

When personalizing a Web site, there are two fundamental reasons for targeting individual users:

To match content (information), application access, application interests, roles, and needs of each visitor to a Web site.
To deliver the information and applications that you want your visitors to see and alter the processing of the applications based on the services you want to provide.

Elements of a personalization solution include the following:

User profile
- Users of the Web site
- Attributes about the user
- Groups and hierarchies
Content model
- Products, articles, programs, and so on
- Defines attributes about the content
- Groups and hierarchies
Matching technology
- User profile, rules, collaborative filtering, and collaborative filtering/market basket analysis or a combination
- Matches the user to the right content
Populating the user content repositories
- Explicit and implicit
Feedback on personalization effectiveness

There are several types of personalization:

User profile-based: User profile-based personalization or simple filtering is used to display content based on predefined groups or user profiles. For example, when a user registers on a portal site, selects which news feeds he or she would like to see information on.
Rules-based: Rules-based personalization is used to display content on predefined business rules.
Collaborative filtering: Collaborative filtering is used to display information based on a combination of your preferences and those of like-minded users.

If you want more information about personalization, please refer to the redbook WebSphere Personalization Solutions Guide , SG24-6214.

7.5.4 Single sign-on

The users in a corporate system are commonly required to use a separate password to authenticate themselves to each server they need to access in the course of their work. Multiple passwords are an ongoing headache for both users and system administrators. Users have difficulty keeping track of different passwords, tend to choose poor ones, and tend to write them down in obvious places. Administrators must keep track of a separate password database on each server and deal with potential security problems related to the fact that passwords are sent over the network routinely and frequently.

Solving this problem requires some way for a user to log in once, using a single password, and get authenticated access to all servers that the user is authorized to use without sending any passwords over the network. This capability is known as Single Sign-On .

This process includes two different processes that need to be clearly understood . These are authentication and authorization .

Authentication

Authentication is the mechanism through which callers and service providers prove to one another that they are acting on behalf of specific users or systems. When the proof is bidirectional, it is referred to as mutual authentication . Authentication establishes the call identities and proves that the participants are authentic instances of these identities. An entity that participates in a call without establishing or proving an identity (anonymous authentication) is called unauthenticated .

Authentication is carried out in two phases:

Service-independent authentication that requires knowledge of some secret is performed to establish an authentication context that encapsulates the identity and is able to create proofs of identity, called authenticators.
The authentication context is then used to authenticate with other called or calling entities.

Authorization

Authorization mechanisms limit interactions with resources to collections of users or systems for the purpose of enforcing integrity, confidentiality, or availability constraints. Such mechanisms allow only authentic caller identities to access components. Mechanisms provided by the J2SE platform can be used to control access to code based on identity properties, such as the location and signer of the calling code. In the J2EE distributed component programming model, additional authorization mechanisms are required to limit access to called components based on who is using the calling code. As mentioned in "Authentication" on page 142, caller identity can be established by selecting from the set of authentication contexts available to the calling code. Alternatively, the caller may propagate the identity of its caller, select an arbitrary identity, or make the call anonymously.

In all cases, a credential is made available to the called component. The credential contains information describing the caller through its identity attributes. In the case of anonymous callers, a special credential is used. These attributes uniquely identify the caller in the context of the authority that issued the credential. Depending on the type of credential, it may also contain other attributes which define shared authorization properties (for example, group memberships) that distinguish collections of related credentials. The identity attributes and shared authorization attributes appearing in the credential are referred to together as the caller's security attributes. In the J2SE platform, the identity attributes of the code used by the caller may also be included in the caller's security attributes. Access to the called component is determined by comparing the caller's security attributes with those required to access the called component.

In the J2EE architecture, a container serves as an authorization boundary between callers and the components it hosts . The authorization boundary exists inside the container's authentication boundary, so that authorization is considered in the context of successful authentication. For inbound calls, the container compares security attributes from the caller's credential with the access control rules for the target component. If the rules are satisfied, the call is allowed. Otherwise, the call is rejected.

There are two fundamental approaches to defining access control rules: capabilities and permissions . The capabilities approach focuses on what a caller can do. The permissions approach focuses on who can do something. The J2EE application programming model focuses on permissions. In the J2EE architecture, the Deployer maps the permission model of the application to the capabilities of users in the operational environment.

When a user requests a resource from a server, the server collects the access-control lists (ACLs) associated with that resource and evaluates them. If the server's evaluation of the ACLs requires identification of the user, the server requests client authentication, in the form of either a name and password or a digital certificate presented according to the Secure Sockets Layer (SSL) protocol.

After the server has established the user's identity, optionally including user/group information stored in a Lightweight Directory Access Protocol (LDAP) directory, it continues its evaluation of the ACLs and authorizes or denies access to the requested information according to the user's access privileges.

Single Sign-On WebSphere Portal Server

Single sign-on support in Portal Server provides a mechanism that assists a portlet in retrieving one of several representations of a user's authenticated identity, which the portlet can then pass to a back-end application. This is much like Portal Server and the portlet acting as an authentication proxy to the back-end application. Using Single Sign-On, a user can authenticate once when logging into the Portal Server, and the user's identity is passed on to applications without requiring additional identity verification from the user. Portal Server supports Single Sign-On through Application Server as well as other authentication proxies, such as IBM Tivoli Access Manager and Netegrity SiteMinder, and leverages the Single Sign-On capabilities between Application Server and Domino.

Single Sign-On in Portal Server has two levels:

The first is a Credential Service, which encapsulates the functionality of Single Sign-On for the portlet writer in an object provided by the Service and for which sample code exists so as to make the use of these objects easy for the portlet writer.
The second level is more flexible but requires portlet writers to directly utilize the Single Sign-On functions of the Portal Server and manage their own connections and authentication to back-end applications.

JAAS

The Single Sign-On functions of Portal Server utilize a subset of Java Authentication and Authorization Services (JAAS). The subset is the authentication portion; Portal Server does not support true JAAS authorization. Portal Server builds a JAAS Subject for each logged on user. The Subject consists of Principals and Credentials.

A Principal is a piece of data, such as the user ID or user's DN, that gives the identity of the Subject.

A Credential is a piece of data, such as a password or a CORBA credential, that can be used to authenticate a subject. The Subject carries around the Principals and Credentials that can be used by the portlet directly or via the Credential Service. See Advanced Topics in Developing Portlets for details on working with Single Sign-On.

JAAS is one Java specification from Sun. JAAS can be used for the authentication of users, to reliably and securely determine who is currently executing Java code, and for authorization of users to ensure they have the access control rights (permissions) required to perform security-sensitive operations.

JAAS authentication is performed in a pluggable fashion. This permits Java applications to remain independent from underlying authentication technologies. New or updated technologies can be plugged in without requiring modifications to the application itself. An implementation for a particular authentication technology to be used is determined at runtime. The implementation is specified in a login configuration file.

JAAS authorization (not supported by WebSphere Portal Server) extends the existing Java security architecture that uses a security policy to specify what access rights are granted to executing code. This architecture, introduced in the Java 2 platform, is code-centric, that is, the permissions are granted based on code characteristics: where the code is coming from, whether it is digitally signed, and if so, by whom.

Credential Service

Credential Service objects exist to handle Basic Authentication, LTPA Token authentication, and simple form-based user ID/password login challenges. Credentials can take their input identity from the JAAS Subject Principals, from the portlet configuration, or from the Credential Vault service. Portlet writers can use the Credential Service to retrieve Credentials from the Credential Vault or the JAAS Subject. Credential Service objects can also be used to pass IBM Tivoli Access Manager or Netegrity SiteMinder Single Sign-On tokens from the JAAS subject to the back-end application in the appropriate headers.

Credential Vault

The Credential Vault is a portal service to assist portlets and portal users in managing multiple identities. The Credential Vault stores credentials that allow portlets to log in to applications outside the portal's realm on behalf of the user. Portal Server provides one simple database vault implementation for mappings to secrets for other enterprise applications. The Default Vault comes pre-configured with an administrator-managed vault segment and a user-managed vault segment. The user managed vault allows users to add application definitions, such as a POP 3 mail account, under the user vault and store a mapping there. Administrator-managed vaults allow users to update mappings; however, users may not add new applications to this vault. By default, the default vault loads an encryption exit for which Base 64 encodes the passwords.