Integrating IBM WebSphere Portal 7 with Microsoft SharePoint 2010

Introduction

IBM® WebSphere® Portal and Microsoft® SharePoint are popular platforms that organizations adopt as their base platform for their portals, and organizations often want to integrate the two technologies.
This kind of synthesis is needed because a number of multiple, separately administered SharePoint installations are difficult to integrate with enterprise applications and legacy systems running on WebSphere Portal.

The most common scenario for this type of situation is when an organization is taken over by another. The portal developed in one technology cannot just be retired due to both the technical and functional complexities involved. The differences between the two frameworks make it impractical to embed SharePoint Web Parts within a portal running under WebSphere Portal, and vice versa.

IBM WebSphere Portal interoperability involves enabling portlets from one portal platform to run in another portal platform, and therefore integration between any two different portal platforms can be attained from a number of perspectives.

This article defines the synthesis between IBM and Microsoft, assuming the base portal platform is IBM WebSphere Portal that needs to be integrated with SharePoint. The need arises for this kind of synthesis arises because a number of multiple, separately administered SharePoint installations are difficult to integrate with enterprise applications and legacy systems running on WebSphere Portal.

We discuss five key areas that must be considered when implementing a full-fledged integrated portal: for our purposes here, they are Security, Single Sign-on, Search, Personalization, and Collaboration. For each integration aspect, we provide several options and recommendations for the most suitable approach.

For this study we use WebSphere Portal 7 (Enable/Extend) and SharePoint 2010 Enterprise Edition, and the targeted audiences are Architects, Developers and Administrators who should have a thorough knowledge of Java^TM and some knowledge of XML.

Understanding integration

Before we start discussing the key areas, it is quite important to understand the concept of---and need for---integration. In this section, we explain the respective Web components in IBM and Microsoft, SharePoint’s architectural overview, and integration points within WebSphere Portal.

Portlets and Web Parts. Portlets and their corresponding Microsoft technology, Web Parts, are conceptually similar; however, in terms of implementation and technology, they have entirely different foundations.

A portlet is a server-side application that runs in the context of the WebSphere Portal server. It inherits from the javax.servlet.http.HttpServlet class and is treated as a servlet by the application server.

A Web Part is Microsoft’s term for the Web component that corresponds to a portlet. Web Parts are contained within Web Part pages and are standard ASP.NET custom controls that are wrapped in the System.Web.UI.WebControls.WebParts.WebPart class.

SharePoint architectural overview. Figure 1 shows the simplified, high-level architectural view of SharePoint, in which all the contents are stored in SQL Server databases. A user’s request is received by Microsoft Internet Information Services (IIS), which delegates the request to SharePoint (built on the .NET framework).

Figure 1. SharePoint architectural overview


Presentation layer approaches:

• Include any SharePoint page in a page using Web Application Bridge (WAB)
• Provide links to SharePoint Sites, List, Library, or Item directly
• Leverage Web Services for Remote Portlets (WSRP) producer sample from Microsoft.

Application level approaches:

• Consume WebServices, for example, Feeds, Content Management Interoperability Services (CMIS) using WebSphere Experience Factory (WEF) or IBM Rational® Application Developer (RAD).
• Consume RSS Feeds for Lists

Database level approaches:

• Integrate using Java Database Connectivity (JDBC) via WEF or RAD

NOTE: Even though a database-level approach is cited as a possibility, we will not cover this since Microsoft does not support a SharePoint installation in which its internal databases are accessed by outside systems.

Integration points

• Discover SharePoint servers using the new IBM OmniFindTM crawler is now entitled as a feature of WebSphere Portal Enable and Extend 7.0.

• Federated search of SharePoint 2010 contents and profiles using Open Search is standard.

• Crawl WebSphere Portal contents with SharePoint 2010 search of Microsoft FAST Server for SharePoint 2010.

• Access SharePoint sites and team rooms through a WebSphere Portal interface using the new Web Application Bridge, with a simplified configuration process.

• IBM Portlet for Exchange supports Microsoft Exchange 2010 for Mail and Calendar functions leveraging new Exchange Web Services.

Figure 2 illustrates these integration points.

Figure 2. Integration points



Access SharePoint 2010 documents or services through:

• CMIS interface in IBM Web Content Manager
• New CMIS builders in WEF
• New sample RAD application showcases easy SharePoint integration

Need for integration. Typical scenarios for which integration between WebSphere Portal and SharePoint is required are as follows:

Data stored in a SharePoint custom list or in a document library is required on the WebSphere Portal end. This could be due to a Java-based enterprise application hosted within WebSphere Portal.

There are specific advantages of each portal platform that an organization wants to take advantage of. Interoperability issues between .NET and Java EE can limit the effectiveness of IT.

There could be situations in which different departments have their own private internal portal. Companies often need to deliver departmental resources to broader audiences within and outside the organization.

Single Sign-on

The first step in providing a unified portal experience is to have Single Sign-on (SSO). The primary objective of this is to allow users who have logged in to one of the portals to move back and forth between two portals without being prompted for their credentials.

WebSphere Portal uses form-based authentication, in which the portal server requests the application server to validate the authentication information against a Lightweight Directory Access Protocol (LDAP) user registry. The portal server enforces access control to portal assets, including portlets, pages, and user groups. It is also possible to manage access control for specific resources in an external security manager, such as IBM Tivoli® Access Manager or others.

SharePoint 2010 supports two types of authentication:

• Classic mode, in which Microsoft IIS handles authentication for SharePoint 2010. It is proprietary code modeled on the NT file system security model and uses an SQL Server to store the access control entries for each principal (security rule).

• SharePoint 2010 introduced claims-based authentication that allows integrating with Active Directory Federation Services (ADFS) and other third-party Web SSO providers.

Microsoft recommends using claims-based authentication, unless there is a specific need to go for the classic mode. We extend the claims-based authentication so as to enable Web SSO at the SharePoint end. Since classic mode does not support Web SSO, this is investigated here.

Approach

The primary mode we investigated involved using a common external SSO provider that would be responsible for authenticating the user and maintaining the session state. Both portal platforms would authenticate and check the valid session state from the SSO provider.

SharePoint 2010 uses Windows® Identity Foundation (WIF) to federate the authentication; specifically, it uses WS-Federation, WS-Trust, and the Security Assertion Markup Language (SAML) standard to authenticate and authorize users. These standards, working in conjunction, are not common among Web SSO Providers. As of this writing, ADFS is known to be the only provider that allows all three standards and is compliant with SharePoint 2010.

Another option was to create a custom provider that would act as the bridge between Web SSO provider and SharePoint. This proof of concept (POC) was successful; however, the approach was ruled out as these involved complex transformations that were already available to ADFS. Hence, all the POCs were performed using ADFS v2 as the authenticating provider for SharePoint.

SAML-based authentication is also available with WebSphere Portal and was leveraged to enable SSO with WebSphere Portal.

Options

Option 1: Using ADFS as the Web SSO Provider. Figure 3 below shows a high-level view of the option in which ADFS v2 was used as the Web SSO Provider.

Figure 3. ADFS used as the Web SSO Provider



As a first option, ADFS is used as the SSO provider for both SharePoint and WebSphere Portal. Whenever a user attempts to log into any of the portals, the user is redirected via ADFS, which authenticates the user against LDAP and returns the SAML token to WebSphere Portal or SharePoint, as required.

The user’s session is configured to be maintained at the ADFS end, and the session timeouts at both the portals were configured at half the value of the session timeout at ADFS. This was deliberately done so as to “force” the user to revalidate the session with ADFS.

The ADFS is configured to provide SAML 1.1 tokens with WS-Federation and WS-Trust to SharePoint and SAML 2.0 tokens to WebSphere Portal Server. Active Directory was used as the LDAP for ADFS.

The primary advantage of using this configuration is the simplistic design. Also, the maintenance overhead is low as there is only one SSO provider that must be maintained.

Option 2: Using Tivoli Access Manager (TAM) as the Web SSO Provider. Another option is to integrate TAM as the SSO provider, so as to look at the approach of integrating third-party SSO providers with SharePoint and WebSphere Portal.

Even though we use TAM as the Web SSO Provider, the approach followed here is valid for all other industry-standard Web SSO Providers. Figure 4 shows a high-level view of how TAM is used as the Web SSO provider.

Figure 4. TAM used as the Web SSO provider



Since SharePoint 2010 cannot directly integrate with TAM, an ADFS server is kept as the bridging layer between SharePoint 2010 and TAM.

IBM TAM is configured to authenticate users against Active Directory and to issue SAML 2.0 tokens to both WebSphere Portal and ADFS, which, in turn, converts the token to SharePoint 2010-compatible, Passive SAML 1.1 tokens following WS-Trust and WS-Federation standards.

The session timeouts at ADFS and WebSphere Portal are set at half the value that is set at TAM, and at SharePoint it was set at half the value at ADFS. This is done to forcefully revalidate the user sessions. It was also noted that users had multiple “hops” at the SharePoint end while authenticating. With the above configuration, users could be successfully authenticated into the two portals.

The primary advantage of this configuration is that it can accept any Web SSO providers. Note, however, there will be extra maintenance overhead for managing ADFS and TAM, and the session timeout settings must be very carefully timed; otherwise, users would get undesirable side effects, such as infinite hops.

Recommendations

• Using ADFS as the Web SSO provider is the most suitable, although some amount of custom coding must be done at the WebSphere Portal end.

• Using third-party SSO providers such as TAM reduces custom coding at the WebSphere Portal end, but it adds to the maintenance overhead. The session timeout settings are also “tricky” and requires some amount of trial and error to reach at the optimum value. This option should be exercised if an organization has a Web SSO provider set up and currently in use.

Security

The second feature we look at involves authorization. Authorization is generally based on user attributes such as a user’s department, role, etc., or ad hoc, whereby access is given at the portal level on an individual basis.

Ruling out the ad hoc authorization, under the assumption that these would be maintained at the individual portal level manually by the administrators, we investigated automated authorization options. Both portals' security supports multiple enterprise authentication schemes for portal-to-portal interoperability.

Options

The typical scenario considered is accessing SharePoint libraries and lists from WebSphere Portal. Here enterprise users log in to WebSphere Portal, using their portal credentials, and access SharePoint document libraries and lists based on roles and group memberships stored on WebSphere Portal. In addition, Portal administrators define role-based security rules to access the various SharePoint instances.

Option 1: Common LDAP. WebSphere Portal and SharePoint are connected to the corporate LDAP store and defined as Trusted Entity for authentication (see figure 5).

Figure 5. WebSphere Portal and SharePoint connected to common LDAP



Option 2: Separate LDAP. IT controls enterprise users’ access to SharePoint sites using WebSphere Portal authentication, while the departmental users maintain their ability to update SharePoint site contents directly, using separate SharePoint credentials that authenticate users against a separate departmental directory (see figure 6).

Figure 6. WebSphere Portal and SharePoint connected to separate LDAP

Recommendations

It is highly recommended to maintain a common Corporate LDAP to register all users for authentication and authorization.

Search

The next important aspect we explored was search. It is the single most important tool to which users resort, when they need to find content from a large repository.

There are numerous search engines available that can potentially crawl multiple content sources. Two major routes for crawling were considered: The first was one crawler crawling the content on both portals; and the second was the portal's own crawler crawling each portal’s content and federating the result to the search query service located on either of the portals.

WebSphere Portal provides integrated Web content search capabilities, including a search portlet, a crawler, a document indexer, and content categorization options.

We chose Microsoft FAST Server for SharePoint 2010 as the search provider at the SharePoint end because of its high capability and followed the Open Search standard for federating the search results.

Options

Option 1: Extended Search within WebSphere Portal. Extended Search is the infrastructure approach option and does not require any programming, but it does require setup and configuration within WebSphere Portal.

Primary complexity revolved around setting the content access account at the WebSphere Portal end, which involved several workarounds. The search result showed normal contents, but targeted results could not be set successfully.
The second drawback was that the profile search could not be set up to provide a rich user interface.

Option 2: Develop custom portlet. A SharePoint Query portlet was developed that calls the Query Web service. The Query service accepts a request in the Open Search XML format and returns a response in XML format, which is subsequently rendered in the WebSphere Portal end.

The primary advantage is that the search results were all received, including profile search, which can be shown at WebSphere Portal end. However, since this was a separate portlet, we could not attain a “unified” look and feel of the search results, and the two search results were separate.

Secondly, this option involves development of a custom portlet, which adds to maintenance overhead.

Option 3: Crawl WebSphere Portal contents from SharePoint. This approach involves setting up the FAST Server to crawl WebSphere Portal contents, with the search results displayed from within SharePoint portal.

This approach provides a unified look and feel, but targeted search results could not be achieved. Specialized WebSphere Portal contents could not be crawled without custom code, and we would need to develop custom Ifilters to crawl such contents.

Option 4: Search federation. This approach involves maintaining separate crawlers at both the portal ends and displaying the search results using Search federation. We followed the Open Search protocol for federating the search results, whereby contents are queried on both SharePoint and WebSphere Portal search systems and search results are presented in a common user interface.

This approach provides a unified look and feel, and target results can be shown with some tweaks. However, this involved maintaining two crawlers are the two portals.

Recommendations

We recommend using search federation to provide a unified search result. The indexers at the WebSphere and SharePoint ends can search their own content and provide the search results in a unified search results screen. The server maintenance overhead is outweighed by the overall better search experience.

Personalization

Personalization involves providing a user-specific experience from a portal, that is, providing targeted contents, which we explored here.

WebSphere Portal offerings include the WebSphere Personalization server, which allows targeting content to specific users in support of the portal’s business goals. The WebSphere Personalization server and WebSphere Portal share a common user profile and a common content model. The model is based on the WebSphere resource framework interfaces classes.

Similar personalization services are included in Microsoft SharePoint 2010, and the SharePoint portal server uses Target Audiences to extend this service.

Areas of Personalization

The My Site settings for each user are stored in user profiles and personal sites. There are Web services exposed by SharePoint 2010 for accessing these settings, and WebSphere Portal can access the Web services and gather information about the users.

Alerts are usually set on a document library list, although they can be programmed to act on any list, and receiving alerts is simple.

Out-of-the-box Web service endpoints that allow audience data retrieval and manipulation can be used to get the members and populate a corresponding segment in WebSphere Personalization.

Recommendations

The best bet for My Site-type user customized pages is to redirect the user to SharePoint My Sites, whenever appropriate. We can most easily create alerts and retrieve audience membership by accessing out-of-the-box SharePoint Web services that allow access to profile information.

Collaboration

WebSphere Portal includes people-awareness features, whereby people's names can appear in portlets as hyperlinks, enabling users to contact people with whom they might want to work. SharePoint 2010 already has built-in features to integrate with Microsoft. Our primary aim is to look at different approaches to bringing these features to the WebSphere Portal end.

Approaches

Option 1: Messenger ActiveX Control. Microsoft provides MessengerWrapper.dll, an ActiveX Control for Messenger that can be embedded in a portlet with supporting JavaScript that interacts with the control to produce a user interface.

Option 2: Real-time communications DLL. Microsoft also provides a client API on Windows versions 2003 and later, called RTCDLL.DLL, which enables interaction with Microsoft’s Live Communications Server (LCS). A portlet implementation can use the Java Native Interface (JNI) to invoke methods within the library to register a user’s presence and query the presence of others.

Option 3: Custom LCS service portlet. Install code with the LCS instance to expose a set of Web services specifically tailored to portal requirements. The LCS Management API enables robust interaction with LCS and LCS events, to enable server applications and management functions.

Recommendations

Use Option 1, Messenger ActiveX Control, when a robust Messenger experience is required within the context of a portal page, and a homogeneous IE client-base is in use.

Option 2 or 3 may be required when there is a mixed-client base. However, Option 2 raises serious thread safety and scalability issues, and Option 3 entails a large amount of custom programming.

Conclusion

This article has explained the feasibility of federating IBM WebSphere Portal 7 with Microsoft SharePoint 2010. Note, however, that as portals are user-centric applications, there could be people- or process-related challenges in any such assignments.

Tell us what you think

Please visit this link to take a one-question survey about this article:

Resources

developerWorks WebSphere Portal zone:
http://www.ibm.com/developerworks/websphere/zones/portal/

IBM WebSphere Portal Self Help Guide:
http://www.redbooks.ibm.com/redpapers/pdfs/redp4339.pdf

WebSphere Portal Best Practices:
http://www.redbooks.ibm.com/redpapers/pdfs/redp4100.pdf

“ADFS 2.0 Step-by-Step Guide: Federation with IBM Tivoli Federated Identity Manager,” Microsoft TechNet article:
http://technet.microsoft.com/en-us/library/gg749921(WS.10).aspx

“FAST Search Server 2010 for SharePoint,” Microsoft TechNet article:
http://technet.microsoft.com/en-us/library/ee781286.aspx.

“SharePoint Back-End Protocols,” Microsoft MSDN article:
http://msdn.microsoft.com/en-us/library/cc341380(v=office.12).aspx.

“Using the RTC Client API,” Microsoft MSDN article:
http://msdn.microsoft.com/en-us/library/ms776014(v=VS.85).aspx

“Microsoft Windows Messenger Integration Custom Project Guide,” Microsoft MSDN article:
http://msdn.microsoft.com/en-us/library/aa164953(v=office.10).aspx

About the authors

Pankaj Bose has more than 13 years of IT experience working as a Solution Architect for various Lotus and WebSphere Portal projects. He currently heads the IBM Portal & Collaboration for Corporate Technology Excellence Group within TATA Consultancy Services, Ltd (TCS). You can reach him at pankaj.bose@tcs.com.

Biswajit Dhar has 15 years of experience in Microsoft Technologies and leads the .NET sub focus area in Corporate Microsoft Technology Excellence Group within TCS. He has been associated with TCS for the past nine years, involved in multiple projects with Microsoft Technologies. Before joining TCS he was with a product development organization where he specialized in products targeted for stock market domain on Visual Basic 6 and Visual C++ 6. You can reach him at biswajit.dhar@tcs.com.


Acknowledgement
The authors wish to thank our associate, Mr. Sunil K Singh, and his team, for coming up with requirements for one of our customers that encouraged us to write this article.