Web portals centralize access to information, applications, and services for employees, customers, or partners. Web portals deliver a consolidated view that lets users access the most important electronic resources of the organization using a standard technology (a browser), simply and efficiently. Portals are often called the "desktop" for Web-based business.
Security, or the portal's ability to authenticate users and authorize access to the Web resources, has generally not been designed into the portal products. Security has been a late addition to existing products without the strength or flexibility many organizations require. Consequently, the quality of security services provided with enterprise portals rests in the degree of integration between the portal service and an enterprise security product.
Access Manager is an enterprise-level security product that provides a single point-of-user authentication and authorization administration. Its Web single sign-on makes it a player in the Web world. Access Manager provides a single point of authentication and authorization to Web-based resources, and provides standards-based APIs that allow Web application servers to access Access Manager's security services.
In this article, we outline the functions of Web portals and Access Manager, and discuss the general integration of Access Manager with Web based products by using its reverse Web proxy and security APIs. I then specifically address IBM WebSphere Portal Server (WPS), and outline the integration points of WPS with Access Manager.
Organizations deploy a Web portal to give employees, partners, and customers easy access to the complete range of information and services in an organization, such as
- Documents
- Enterprise applications
- e-business
- Internet services
Employees, partners, and customers can also collaborate through a portal, yielding important business and technical information resources.
Many products are touted as being Web portals. The important distinction is that a Web portal can provide a single view of a range of information sources rather than being specific to a particular application or technology. Some products labeled as Web portals only provide access to specific vendor applications or services. These can be used to consolidate some information sources, but miss the target on providing a single consolidated view of all information sources an organization uses. Essentially, a Web portal authenticates a user and then queries a range of information sources to assemble and consolidate the view of information and services. This view can be customized for the individual, so users can personalize the delivery of information sources that are important to them.
Security for the Web portal falls into two service areas:
- Web single sign-on: When users first enter a portal, they're prompted to provide authentication information that lets the Web portal verify the identity of the user. Authentication is usually based around username and password, although other mechanisms, such as token based or biometric authentication, are also available.
- Authorization: Determining what resources an authenticated user can access. For example, a customer may only be able to access e-business applications from the Internet, whereas an employee might be able to also access corporate applications from the Internet.
In general, Web portals have focused on providing content consolidation and ease of access, and strong security is best provided by integration with security products.
Access Manager is a robust and secure policy management tool for e-business and distributed applications. It addresses the challenges of escalating costs for e-business security, growing complexity of enterprise security solutions, and the inability to implement security policies across platforms. Through its highly available centralized authorization service, Access Manager enables better management of business-critical distributed information. It provides simple, secure access to critical information, and enhances communications with customers, business partners, and others. Figure 1 below shows the facets of Access Manager.
Figure 1. Access Manager

Access Manager provides authentication and access control services for Web resources. The WebSEAL server, a component of Access Manager, manages access to all Web servers, regardless of their platforms. This allows an organization to centrally control their Web resources as a single, logical Web space. Access Manager also adds security support for CORBA applications written with Visibroker or Orbix object request brokers (ORBs). Access Manager is also the backbone for Tivoli Privacy Manager, an access control product that helps implement e-business privacy policies.
For applications developed in-house, Access Manager also provides application APIs that give access to its services. Access Manager supports the J2EE standard Java Authentication and Authorization Service (JAAS) to allow native Java applications to access Access Manager for authorization decisions. Access Manager also provides an implementation of the Open Group's standard authorization C-language API (azn-API) to let applications that want to call out to a C API use the Access Manager authorization and entitlements services. Access Manager provides a robust Web-based delegated security administration utility that lets administrators delegate security administration to members of their e-community.
Access Manager in the Web environment
This section gives a generalized view of Access Manager integration in the Web environment. Ease of application integration is a key principle that Access Manager adheres to. Though there are many facets to integration, my focus is on how Access Manager can add value to Web application environments. Following are three levels of integration for developers or architects to consider. Each level builds upon the previous level.
The first level of integration involves configuring Access Manager's WebSEAL smart junctions for any HTTP-compliant Web server or application server with WebSEAL. An example of WebSEAL smart junctioning is in Figure 2 below. By junctioning these servers, WebSEAL can provide Web single sign-on, coarse-grained access control (whether one can access the Web server or not), high availability, and scalability. Level 1 integration is shown in Figure 2.
Figure 2. Web single sign-on

Level 2 integration enables access control for individual objects on the Web server or application server, and requires placing a small customizable common gateway interface (CGI) script called query_contents on the Web server. This allows the management console to display and manage the Web space, or application space, of the Web and application servers. Access Manager handles access control for static content and dynamic content. With the dynurlcp utility you can place ACLs in components of applications or CGIs. By passing user and group information in the HTTP headers, the application server can make further access control decisions if required. This information passed from WebSEAL can also be used to access back-end applications. Level-2 integration is shown in Figure 3 below.
Figure 3. Level 2: URL Access Control

Level 3: Web application server aznAPI or J2EE/JAAS integration
With level 3 integration, Access Manager implements aznAPI, which allows an application to call out to an authorization service for authorization decisions. The Access Manager identity information (iv_user, iv_group and iv_cred), passed to the application server by the HTTP header, can be used by aznAPI to make further fine-grained access control decisions based on the specific internals of the application (and any authorization decisions enforced by WebSEAL). Information passed from WebSEAL and obtained from the Access Manager framework can be used to make access decisions to back-end applications. Figure 4 below shows level 3 integration.
Figure 4. Level 3: Integration with Access Manager - Web application aznAPI integration

Level 3 integration requires installing aznAPI on the application server, extending or developing the application server to use aznAPI, and loading the application namespace into the Access Manager management server (either by using query_contents or the Access Manager management API). Access Manager is responsible for both authentication and fine-grained access control. With aznAPI, integration can be enhanced by using dynamic roles, which are enabled by Privacy Manager. Access Manager offers Java programmers an alternative to aznAPI by enabling Access Manager as a provider of authentication and authorization services for any 1.3 JVM (and IBM 1.2.x JVMs).
Integrating Access Manager with WebSphere Portal Server
WebSphere Application Server security includes its own services for authentication and authorization, which are available only to WebSphere applications. WebSphere Portal Server (WPS) is an application running on WebSphere Application Server that can use Application Server's security services. Access Manager enables organizations to consistently enforce their security policy across WebSphere and non-WebSphere applications. When WebSphere server and Access Manager are implemented together, there are choices for doing authentication and authorization. There are many facets of integrating with Access Manager, but in this article I focus on:
- Single sign-on to WPS
- URL access control
- Authentication and authorization integration
- Common security model
With single sign-on options, the WPS trust of WebSEAL is maintained through the junction between WebSEAL and the Web server. A junction is a physical connection between a WebSEAL server and a Web server, configured such that:
- There is trust between WebSEAL and the Web server.
- WebSEAL protects its own resources and the resources on the junctioned server.
Another essential aspect of trust is the target application server's trust of the requester. There are essentially two options for achieving single sign-on, and each handles trust of the requester differently. The two options are:
- Running WPS in Trust Association mode, which allows WebSEAL to act as a front-end authentication server while WPS applies its own authorization policy onto the resulting credentials that WebSEAL passes to it.
- Passing mapped usernames and passwords to WPS, with which the target Web server can do its own authentication and add its own authorization policy.
With both options, both aspects of trust are maintained. And, all of the advantages of WebSEAL (such as high availability, load balancing, state management, scalability, and support for multiple identity mechanisms), and of products that work with Access Manager, accrue. This includes Privacy Manager with its support for dynamic roles.
The next facet of integration involves enabling access control for individual objects on WPS, which requires placing a small customizable CGI script called query_contents on WPS. This allows the management console to display and manage the Web space and application space of the Web and application servers as a single virtual Web namespace.
Authentication and authorization integration
As mentioned, WebSEAL provides robust authentication, authorization, availability, and single sign-on services for the Web environment. As browsers attempt to access Web resources, WebSEAL filters all HTTP traffic before it enters the Intranet, thus isolating and protecting Web servers from Internet attacks and managing access at the URL level.
WPS contains applications called portlets. Although WebSEAL can provide access control to these portlets, the portlets themselves often need to make further access control decisions, finer-grained than those controlled by WebSEAL. For example, these finer-grained access control decisions can help personalize the requesting user's Web browser screens. So, for flows coming through WebSEAL, to enable fine-grained processing, WebSEAL can be configured to pass user information, group information, or Access Manager credential information to the target portlets.
Access Manager supports the Java 2 security model and JAAS, a standard Java 2 extension that identifies the user who is running the code. This identity is factored into Access Manager security decisions. Support for the standards provides great flexibility for Java developers to leverage fine-grained usage of security and authorization services as an integral component of their application and platform software. With the Java 2 and JAAS support in Access Manager, Java applications can:
- Invoke the Access Manager-supplied JAAS LoginModule to acquire authentication and authorization credentials from Access Manager.
- Use the
PDPermissionclass to request authorization decisions.
Now Java application developers have the following advantages:
- The security of Java applications that use
PDPermissionis managed using the same consistent model as the rest of the enterprise. - There is no requirement to learn additional security technology beyond Java 2 and JAAS.
- Updates to security policy involve Access Manager-based administrator actions, rather than code updates.
WPS supports standard exits to enable third-party ISVs to be plugged in. One of the exits is a security exit. WPS development is planning on a security exit to leverage the Access Manager Java 2 support, as described above, which will include WPS access to the Access Manager entitlements service.
Access Manager and WPS are based on different security models. The options below help Access Manager and WPS users choose between either of the security models, or a mix:
- Access Manager as an end-to-end solution. You can choose to use Access Manager to manage access to all WPS resources. Though this has the advantage of using a single security model, the disadvantage is that authorization cannot be as granular as in WPS. Developers have to code using the
PDPermissionclass to enforce fine-grained authorization on portal resources. - Access Manager and WPS for providing security solution. You can choose Access Manager and WebSphere security to coexist. This has the only advantage of NO CODING to enforce fine-grained authorization on portal resources. The disadvantages are redundant effort in defining ACLs, and maintaining and administering two security solutions.
- Participate in the discussion forum.
- Learn more about IBM Tivoli Access Manager.
- Get more information on Tivoli Security Management Products.
- Find out about WebSphere Portal Server.
- Learn how WebSphere Portal Server can work in wireless networks.
- Get a general understanding of portals from this developerWorks article.

Dr. Paul Ashley is a Security and Privacy Architect working in the Tivoli Security Business Unit (part of the IBM Software Group). His area of expertise is providing secure and manageable e-commerce solutions to enterprises and their edge systems, which includes architecting solutions for customers, working on new product development, and standards work. Before joining Tivoli, Paul worked as a lecturer in information security and data communications at the Queensland University of Technology. You can contact him at pashley@us.ibm.com.

Dr. Sridhar Muppidi is a Security and Directory Architect working in the Tivoli Security Business Unit (part of the IBM Software Group). His work involves design, integration and implementation of various security and directory solutions for distributed systems. This includes architecting solutions for customers, working on new product development and standards work. Before joining Tivoli, Sridhar worked in IBM's Global Services group. You can contact him at muppidi@us.ibm.com.

