eight steps to deploying an enterprise portal - part four

Eight Steps to Deploying an Enterprise Portal – Part Four

Intelligent Business Strategies

Springfield House, Water Lane, Wilmslow,

Cheshire, SK9 5BG

01625 520700

November, 2005

Mike Ferguson

© Intelligent Business Strategies Ltd 1

Part Four – Eight Steps to Deploying an Enterprise Portal By Mike Ferguson

Managing Director, Intelligent Business Strategies

In this month’s article in EI magazine, we will continue to look as eight steps to deploying

an enterprise portal outlined below.

1. Develop the portal business case, and plan for portal implementation

2. Understand user functionality and content requirements

3. Define a portal architecture, and select, install and integrate portal products

4. Develop the portal taxonomy and categorisation scheme

5. Design and customise the portal user interface

6. Develop the security and single sign-on architecture

7. Develop, implement and integrate information, collaboration, applications with the

portal

8. Personalise and prototype to create multiple role-based portals, train users, and

deploy portal technology in a phased manner

Having covered step 4 in my last article, this month we will focus on steps 5 and 6.

Step 5 – Design and customising the portal user interface

Perhaps the first thing to state is what we mean by customisation. Customisation is the

process of tailoring and extending a portal to match an organization’s presentation standards,

as well as extending the portal to connect to all back-end business content and services that

are required. This is not the same as personalisation. Personalisation is the process of

filtering business content to fit the role and requirements of the portal user while remaining

within an organization’s security policies. Portal customisation is typically done using the

portal administration screens and/or a portal development kit that is shipped with the portal.

Customisation can take place in two areas:

Customisation of the front end-user interface

Customisation of the back end to extend the portal by adding additional portlets to

access additional content.

Looking at customisation of the front-end user interface first, this type of customisation

typically involves providing allowing authorised users to:

Select or define portal colour schemes

Portal branding

Customise portal page layout

Extend the portal to support multiple devices e.g. mobile phones, PDAs, browsers


Over the years portal user interface customisation controls have got increasingly more

sophisticated and easier to use. In addition customisation can take place at the enterprise or

community level. To speed this up, many portal products today come with pre-built colour

schemes and templates that you can choose from and in addition offer the ability to define

your own templates. Administrators can design these templates and then deploy them as a

base for others to build from. Figure 1 shows an example of portal user interface

customisation.

Change banners to brand

different business units,

customers etc.

Place free-form content in

magazine style layout

areas

Customize styles and

colours for portlets

Community Based Portal User Interface Customisation

Figure 1

Figure 1 shows portal branding, the selection of a magazine style layout for free-form

content and portlet colour selection. Some portal products such as SAP NetWeaver Portal

include a rules editor that allows portlet layout to vary depending on the user or user group.

Other products such as IBM WebSphere Portal Server include integrated customisation tools

built into the portal user interface. Figure 2 shows these customisation tools (in orange)

integrated into each portlet and the portal page. He purpose of this is to support self-service

customisation by authorised users without the need to request changes to be made by central

administrators and without the need to switch to administrator screens.


IBM WebSphere Portal In-Line Customization Editing Tools

Figure 2

Customisation of a portal also includes extending the portal to support multiple devices.

Many portal products ship with pre-built support access from laptop and personal desktop

computers as well as PDAs and mobile phones. However they also allow you to extend the

portal to support additional devices. Portal products can render content in portlets to fit the

web device being used to access the portal. This is typically done via an XSL processor built

into the portal server. Here the portal merges portlet XML content with the appropriate

device specific XSL style sheet to generate mark-up language needed to render the content

onto device being used. This is shown in figure 3.

Devicespecific

XSLstylesheet

Applications,Applications,BIBI

DatabaseDatabase, File &, File &XML dataXML data

Collaboration ToolsCollaboration Tools

EnterpriseEnterprise

PortalPortal

XML

XML portlets

HDMLVoXML… (any

mark-up)

XSLProcessor

WMLHTML

Adapting Portal Content For Presentation on Multiple Devices

Figure 3


The second major type of customisation is customisation of the back end to extend the portal

by adding new portlets. Portlet development can be done by:

Portlet wizards built into IDE tools

Portlet development tools shipped with the portal product

Portlet development in IDE tools normally occurs when the IDE tool is supplied by the same

vendor that sells the portal product. For example, BEA WebLogic Workshop can be used to

build portlets for BEA WebLogic Portal. Equally Microsoft Visual Studio .Net can be used

to build Web Parts (their name for portlets) for Microsoft Office Sharepoint Portal Server.

Portlet development tools that ship with the portal include Vignette Builder to build portlets

for the Vignette Portal and also BEA AquaLogic Studio that can build portlets for the BEA

AquaLogic Portal. Many portal vendors also attempt to expedite portlet development by

offering portlet galleries on the web from where you can download portlets that have been

developed by partners and customers.

Step 6 – Develop the security and single sign-on architecture

One of the most publicised benefits put forward by portal software suppliers is the benefit of

single sign-on. While single sign-on is easy to say it is not that easy to implement. A lot

depends on the existing security environment. In this respect, many companies have a

complex, multi-vendor environment with multiple authentication and authorisation schemes

and technologies. In this case they are struggling with fractured ‘silos’ of security

management and the fear that portal software may create another security ‘silo’ and add to

the complexity. So the fact is that before you look to solve this problem you have to

understand your existing set-up. How are user profiles and user groups maintained? How

many user directories exist in you enterprise? Do applications have their own specific user

management and authorization schemes built in? How many access control lists (ACLs) do

you have and how are they maintained and synchronized? Is your HR system integrated

with security management? Planning and implementing portal software will bring this to a

head and will force you to find ways to integrate security administration ‘silos’. Four main

areas need to be addressed:

Managing user profiles (member services)

Verifying user identity (authentication)

Enforcing access policies (authorization)

Managing access to backend applications (single sign-on)

To make this possible requires you to manage and synchronise security metadata.

Authentication requires integration with multiple existing authentication techniques so that

existing authentication services can be leveraged. Multiple authentication methods may

need to be supported, so that single sign-on can take place across multiple sites, applications

and enterprises. This also requires interoperability across sign on methods and integration

preferably the establishment of a cross platform common LDAP-compliant directory such as

Microsoft Active Directory, Novell eDirectory or Sun ONE Directory Server. All portal

products integrate with an LDAP server to inherit user and user group information which is a

good thing. However the problem with user directories is that portal vendors often


complicate the matter by requiring you to have to use their directory server if you use their

portal product. This is often not welcome if you have invested in another directory server

for user management. For example, Microsoft requires that you use Active Directory with

Office SharePoint Portal Server and provides Microsoft Internet Integration Services (MIIS)

to synchronise with any other directory that you may have. Equally Oracle requires that you

use Oracle Internet Directory (OID) and again mechanisms for synchronisation with other

directories are provided. Other vendors such as IBM will let you plug the portal into any

LDAP server without requiring that you change to their product.

Authorisation is an altogether much more difficult problem to solve. This is because you

need portal authorization to integrate and synchronise with existing application authorisation

mechanisms. The authorisation problem is totally unique to every company mainly because

each legacy and/or packaged application could have its own authorisation scheme and

therefore portal authorisation needs to be aligned with other application specific

authorisation mechanism which is not at all straight forward.

Portal security can be implemented in two main ways:

1. Using the portal integrated security service i.e. ‘out of the box’ security provided by

the portal product

2. Using a web single sign-on product (SSO) integrated with a portal product e.g. RSA,

CA SiteMinder, Oracle Oblix etc.

The advantage of the leveraging the security service that comes built-in to the portal product

is that it is easier to implement and comes at no additional cost. This kind of service is

provided via administration screens that offer a single administration point of control. User

management is supported via portal integration with LDAP compliant directories. Once

connection with an LDAP directory is established, the portal inherits the user and user group

information defined there. To carry out authentication checks, a portal typically leverages the

authentication service provided by the underlying application server to check user

credentials against those held in an LDAP server. In addition the portal server holds

additional metadata about the user e.g. their role, personalisation rules, content

authorisations for roles etc. Portal products offer various levels of authorisation granularity

that can be controlled at the enterprise, user community and individual user levels. Users can

be granted/refused access to portal pages, individual portlets and even individual documents.

To support single-sign-on, many portals provide a credential vault that allows SSO cookies

to be held to store credentials that need to be passed to ‘back-end’ applications, services and

information systems connected to the portal server. In addition the security service itself can

often be delegated to additional users so that user management is distributed across the

enterprise.

A key question in portal security is how is the LDAP directory maintained? If you have your

own application that you use to do this then the portal needs to be able to support read only

LDAP connectivity because otherwise the portal administration screens would offer a second

and possibly conflicting LDAP maintenance option to the application you are using to

manage the LDAP. An example of a product that does this is IBM WebSphere Portal Server.

A frequent requirement from many companies is to have their human resources (HR)

application maintain their LDAP directory and therefore to dictate the portal security. Figure


4 shows an example of how this can be done via Oracle PeopleSoft. Here, when a new

employee is recruited or an employee leaves or moves to a new job within the company, then

the HR database is updated and the LDAP is synchronised accordingly. Many HR

applications (e.g. Oracle PeopleSoft, SAP) come with an LDAP directory interface. Figure 4

shows the PeopleSoft Directory Interface.

Application Server

XMLXML

Integrate

PeopleSoft portlets

into the portal

Enterprise

Portal

Server

Portal security

repository

PeopleSoft

Application

Server

PeopleSoft

database

Cross platform

LDAP

PeopleSoft

Directory Interface

Portal needs to support

read only LDAP option

HR Maintained LDAP

Figure 4

Here the HR system manages the LDAP indirectly via the directory interface and the portal

server simply accesses the LDAP in read only mode to automatically pick up the user and

user group details held there. In addition, the HR application can itself be integrated into the

portal via portlets and nominated users can then be authorised to have access to the HR

portlets. In this way the HR application is used via the portal user interface to maintain its

own database and the LDAP directory with the portal server automatically inheriting

whatever changes are made. If the portal administration screens are used to maintain the

use information then the LDAP server would have to be accessed from the portal in

read/write mode. An example of a product that does this is Microsoft Office SharePoint

Portal Server and Microsoft Active Directory.

With respect to single sign-on, the portal can authorise a user or user group to have access to

portlets that access a remote application. The authorisation strategy is more difficult. With

the best will in the world, it is impossible for a portal to automatically align itself with

application specific proprietary authorisation schemes. Authorisation control in a portal is

typically done by giving users or user groups access to application function granularity via

portlets. By authorising users to have access to specific portlets, we can control user access

to some or all of an applications’ functionality. However there are a few things to be aware

of. For new internally developed applications it is relatively easy to adopt the authorisation

service of a portal rather than invent one that is application specific. In addition new

applications can be developed with a web services based portlet user interface.


However, portlet based authorisation can’t fix packages and existing legacy systems with

their own built-in authorisation schemes. In this case it is better to grant authorised users

access to the legacy application or package and let the package or legacy system handle its

own authorisation. Also, packaged applications need to be integrated with cross platform

LDAP directories to inherit users and user groups. The LDAP directory metadata itself also

needs to be kept synchronised with legacy system and package metadata when LDAP entries

change. For packaged applications with portlet user interfaces (several applications now

provide this) it may be better to surrender package authorisation to portal provided that the

level of granularity needed can be controlled via that mechanism. In this case the portal can

handle the authorisation as long as the portal security service is accessible from remote

portlets. At the very least single sign-on is needed. The authorisation strategy should be

revisited regularly as packaged applications and legacy systems move to a portlet based user

interface (UI).

Web Single Sign-on (SSO)

The second option for portal security is to use a separate web single sign-on product in

addition to the portal server as opposed to the built-in capabilities that may come with a

portal product. Examples of this type of product include RSA ClearTrust, Oracle Oblix, CA

eTrust and Netegrity SiteMinder. Web single sign-on products often offer better security

integration features such as support for multiple authentication methods, interoperability

across sign on methods, multi-site SSO including across enterprises, mobile security and

centrally based policy management. In addition, because they were built from the ground-up

to just manage security they are often more comprehensive than portal built-in capability and

can manage secure access to portals as well as other resources. On the negative side theses

products come at an additional cost and are inevitably more complex to set up that portal

built-in security because the web SSO product needs to be integrated with the portal.

However in the case of Oracle and IBM, these vendors recommend this strategy to be

implemented with their portal products because they also provide web SSO products.

The way web SSO works is by sitting in front of the portal. Here an agent on a web server

(of which there can be many) intercepts the log-on request and re-directs it to the web SSO

server. The web SSP server then authenticates the user against all known directories in the

enterprise. It then checks authorization before letting the user access the appropriate

applications. Single sign-on is supported by using an encrypted cookie mechanism typically

held on the SSO server. The cookie passes a web user's credentials to the web server plug-in,

eliminating the need for the user to resubmit their password. The cookie enables all protected

web servers to share authentication information. Users accessing resources secured with a

plug-in on multiple web servers only enter one username/password combination per session.

The plug-in then logs the user on to the appropriate back-end application. Note that in this

case the web SSO server just treats the portal as an application and can manage

authentication and authorization to any other application that is not yet accessible via the

portal itself. This includes Windows applications under the management of a terminal server

like Citrix MetaFrame for example. Figure 5 shows how a Web SSO product works.


Web SSO

Authentic

-ation &

Authoriza

tion

SSO

agent

Web SSO And Portal Integration

Enterprise

Portal

Server

Portal security

repositoryWeb

security

repository

(policies)

Browser

login

App’ns

Content

BI

E-Business

Application

Enterprise

Application

Server

= protected server plug in

cookie

cookie

cookie

JSPs

EJBse.g. IBM WebSphere,

BEA WebLogicF

I

R

E

W

A

L

L

User Stores

LDAP,

NT Domain

Mainframes,

ODBC,

ADSI

SAML

Web

Svr

Figure 5

If you have a complex heterogeneous environment web SSO is a strong option. Also this

tends to be the preferred approach put forward by portal vendors themselves if they also

provide such software. It may also be a preference if you have already installed a Web SSO

product to manage intranet access to applications for example.

In next month’s article I will look at the step 7 on integrating applications, information and

collaboration tools into the portal user interface.

-------------------------------------------------------------------------------------------------------

Mike Ferguson is Managing Director of Intelligent Business Strategies Limited, a

leading information technology analyst and consulting company. He is also a partner in

iBonD. As an analyst and consultant he specialises in enterprise business intelligence,

enterprise business integration, and enterprise portals. He can be contacted at +44

1625 520700 or e-mail at [email protected]

eight steps to deploying an enterprise portal - part four

Documents