Get a handle on portals

Enterprise portals are attractive because of their broad utility and flexible, all-inclusive model. But their functional attractiveness shouldn’t cloud critical technical issues involved in forming a portal-implementation plan.

Security and Identity Management: End-users and administrators will need to be authenticated, identified, and granted access to the portal. Does the portal server allow you to plug into your existing LDAP/Active Directory/SAML systems, or does it force you to use its integrated authorization, authentication, and/or identity administration components? The Sun Java System Portal Server, for example, requires the use of the bundled Sun Java System Identity Server and Directory Server for security/identity management. Microsoft’s Office SharePoint Server product defers to IIS for security management, which typically means using either Active Directory or Passport services for authentication/identity management and IIS permission models for authorization. Clearly this area should be considered carefully before choosing a portal solution, otherwise the needed interfaces may prove an unwelcome fiscal surprise, or, worse yet, you may have to fragment your enterprise security model.

General Infrastructure Interfaces: These interface issues apply equally to any other critical components of your infrastructure. These might include pre-existing content-management systems, intellectual property management systems, workflow engines, document management systems, and so on. Depending on the modular capabilities of the portal environment, you may discover that you need to do a fair amount of old-fashioned (and expensive) software development to make the portal fit your enterprise.

Business Logic Implementation: Many portal environments offer low-end tools for implementing integrated business logic, such as scripting languages and visual "development" environments. These tools promise rapid implementation, but often compromise the architectural "purity" and long-term maintenance of the portal by putting this logic directly in the UI components. Traditional, tiered application design dictates that business logic should be isolated and managed in the middle tier, allowing the UI to evolve separately. It may be necessary to avoid the low-end tools and stick with traditional software development in the application server layer.

Standards-Based Portal Technology: Standard content formats allow you to plug external content into your portal at near-zero cost. Can your portal environment consume standard RSS feeds, for example? Standard portal APIs allow you to plug third-party portlets into your portal at near-zero cost. Does the portal server support the WSRP (Web Services for Remote Portlets) protocol? If the portal environment is J2EE-based, does it also follow the Java Portlet Specification, JSR 168? Many portal vendors -- Sun, Vignette, Oracle, Novell, among others -- are adopting one or both of these standards in their portal offerings, providing you the ability to integrate portlets implemented by others in disparate environments. Standard federated security protocols, such as SAML (Security Assertion Markup Language), and related umbrella standards, including the Liberty Alliance profile or Microsoft Passport, allow you to integrate distributed security/identity authorities into your portal environment. Which of these protocols does the portal product support? Which is the best fit with your infrastructure and that of your partners?