The perfect portal implementation: Eight steps to heaven

Part IV

Once the design and development stages are complete, it is time to begin tailoring the portal to fit with company brand and user requirements. Part four of this workshop series covers user-interface design and customisation, and the development of security and single sign-on architecture. By Mike Ferguson

The eight-step approach to portal implementation
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 and applications with the portal;
8. Personalise and prototype to create multiple role-based portals, train users and deploy portal technology in a phased manner.

We have now reached the half-way stage of the eight-step approach to deploying an enterprise portal. So far this series has detailed the processes involved in developing the portal business case, understanding user requirements and functionality, defining your architecture, and installing portal products. Having developed your taxonomy and categorisation scheme (as featured in last month’s workshop), you are now ready to progress to steps five and six.

Step five: Design and customise the portal user interface
Customisation is the process of tailoring and extending a portal to match an organisation’s presentation standards, as well as connecting it to all the back-end business content and services that are required. This is not the same as personalisation, which filters business content to fit the role and requirements of the user, while remaining within an organisation’s security policies. Customisation is typically performed using portal administration screens and/or a development kit that is shipped with the software. This process can take place in two areas:

Customisation of the front-end user interface;
Customisation of the back end to extend the portal (including extra portlets to access additional content).

Customisation of the front-end user interface usually involves allowing authorised users to:

Select or define portal colour schemes;
Select or define portal branding;
Customise portal page layout;
Extend the portal to support multiple devices – for example, mobile phones, PDAs or browsers.

Portal user-interface customisation controls have become increasingly sophisticated and easier to use, and customisation can take place at enterprise or community level. To speed this up, many portal products include pre-built colour schemes or templates and, in addition, offer the ability to define your own templates. Administrators can design these templates and deploy them as a base for others to build from.

Figure 1 shows an example of portal user-interface customisation. It also highlights portal branding, the selection of a magazine-style layout for free-form content and portlet colour selection. Some portal products include a rules editor that allows portlet layout to vary depending on the user or user group. Others include integrated customisation tools built into the portal user interface. Figure 2 shows customisation tools (in orange) integrated into each portlet and the portal page. This supports self-service customisation by authorised users, without the need to request changes to be made by central administrators or switch to administrator screens.

Customisation also involves extending the portal to support multiple devices. Many 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 system, typically 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 the device being used. This process is illustrated in Figure 3.

Back-end customisation to extend the portal by adding new portlets can be achieved through:

Portlet wizards built into integrated-development-environment (IDE) tools;
Portlet-development tools shipped with the portal product.

This type of portlet development normally occurs when the IDE tool is supplied by the same vendor that sells the portal product. Many vendors also attempt to expedite portlet development by offering portlet galleries on the web, from which 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 single sign-on (SSO), which it is not that easy to implement. Much depends on the existing security environment. Many companies have a complex, multi-vendor environment with numerous authentication or authorisation schemes and technologies. They are struggling with fractured ‘silos’ of security management and fear that portal software may create another to add to the complexity. Before you look to solve this problem, you have to understand your existing set-up. How are user profiles and groups maintained? How many user directories exist in your enterprise? Do applications have specific user-management and authorisation schemes built in? How many access-control lists do you have, and how are they maintained and synchronised? Is your human-resources (HR) system integrated with security management? Planning and implementing portal software will bring these issues to a head and will force you to find ways to integrate security-administration silos. Four main areas need to be addressed, which will require management and synchronisation of your security metadata:

1. Managing user profiles (member services);
2. Verifying user identity (authentication);
3. Enforcing access policies (authorisation);
4. Managing access to back-end applications (SSO);

Portal authentication will require integration with existing techniques so that existing authentication services can be leveraged. Multiple authentication methods may need to be supported so that SSO can take place across disparate sites and applications. This also requires interoperability across sign-on methods and integration, preferably the establishment of a cross-platform lightweight directory-access portal (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 use their directory server if you use their portal product. This is often not welcome if you have invested in another product for user management. For example, Microsoft requires that you use Active Directory with SharePoint and provides internet-integration services to synchronise with any other directory that you may have. This is the same for Oracle. Other vendors such as IBM will let you plug the portal into any LDAP server without changing to their product. Authorisation is a much more difficult problem to solve because you need to integrate and synchronise with existing application-authorisation mechanisms. This problem is common to every company, mainly because each legacy and/or packaged application could have its own authorisation scheme.

Portal security can be implemented in two ways:

Using the portal-integrated security service – ‘out of the box’ security provided by the portal product;
Using a web SSO product integrated with the portal. For example, RSA, CA SiteMinder or Oracle Oblix.

Portal integrated security service
The advantage of 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 within it. A portal typically leverages the authentication service provided by the underlying application server to check user credentials against those held in the LDAP server. The portal server also holds additional metadata about the user – for example, their job title, personalisation rules and role-based content authorisation. 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 or refused access to portal pages, portlets and even individual documents. To support SSO, many portals provide a vault that allows cookies to store credentials that need to be passed to back-end applications, services and information systems connected to the portal server. The security service itself can often be delegated to additional users, so user management is distributed across the enterprise.

A key question in portal security is that of LDAP directory maintenance. If you use your own application, the portal needs to be able to support read-only LDAP connectivity, otherwise the administration screens could offer a second and possibly conflicting LDAP maintenance option to the application you are using. An example of a product that does this is IBM WebSphere. A frequent requirement from many companies is to have their HR application maintain their LDAP directory and, therefore, dictate the portal security. Figure 4 shows an example of how this can be done using Oracle PeopleSoft. Here, when a new employee is recruited, leaves or moves to a new role within the company, the HR database is updated and the LDAP is synchronised accordingly. Many HR applications come with a LDAP directory interface.

Here, the HR system manages the LDAP indirectly via the directory interface, which the portal server accesses 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 using portlets, which nominated users can then be authorised to access. In this way the HR application is used via the portal-user interface to maintain its own database, with the LDAP directory and the portal server automatically inheriting whatever changes are made. If the portal administration screens are used to maintain user information then the portal will need to access the LDAP server in read and write modes. An example of a product that does this is Microsoft SharePoint alongside Active Directory.

The authorisation strategy is more difficult. Even 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 performed by giving users or user groups access to application-function granularity through portlets. By authorising access to specific portlets, we can control user access to some or all of an application’s 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 the portal, rather than invent one that is application specific. In addition new applications can be developed with a web-services based portlet-user interface.

But portlet-based authorisation will not ‘fix’ packages and existing legacy systems with their own built-in authorisation schemes. It is better to grant authorised users access to the legacy application or package and let the technology handle its own authorisation. Also, packaged applications need to be integrated with cross-platform LDAP directories to inherit users and user groups. The LDAP metadata itself also needs to be kept synchronised with legacy system and package metadata when entries change. For packaged applications with portlet user interfaces (several applications now provide this), it may be better to surrender package authorisation to the 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 its security service is accessible from remote portlets. At the very least, SSO is required. The authorisation strategy should be revisited regularly as packaged applications and legacy systems move to a portlet-based user interface.

Web single sign-on
The second option for portal security is to use a separate web SSO product in addition to the portal server, as opposed to the built-in capabilities that may come with a portal product. Web SSO products often offer better security-integration features, including support for multiple authentication methods, interoperability across sign-on methods, multi-site SSO across enterprises, mobile security and centrally based policy management. Because they are built from the ground up, purely to manage security, they are often more comprehensive than built-in capability and can manage secure access to portals as well as other resources. On the negative side these products come at an additional cost and are inevitably more complex to set up than built-in security, because they must be integrated with the portal.

Web SSO works by, effectively, 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, which then authenticates the user against all known directories within the organisation. It then checks authorisation before letting the user access the appropriate applications. SSO is supported by an encrypted cookie mechanism typically held on the 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 – and 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 and 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 simply treats the portal as an application and can manage authentication and authorisation 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, for example.

If you have a complex, heterogeneous environment, web SSO is a strong option. It also tends to be the preferred approach of vendors themselves if they provide the appropriate software. If you have already installed a Web SSO product to manage intranet access to applications, for example, this may also be your preference.

In next month’s article I will move on to step seven, which covers the integration of applications, information and collaboration tools into the portal user interface.

Mike Ferguson is managing director of Intelligent Business Strategies. As an analyst and consultant he specialises in enterprise business intelligence, business integration and portals. He can be contacted on +44 1625 520700 or by e-mail at mferguson@intelligentbusiness.biz.