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

Single sign-on to WPS
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.

URL access control
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.

Common security model
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 PDPermission class to request authorization decisions.

Now Java application developers have the following advantages:

• The security of Java applications that use PDPermission is 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.

Conclusion
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 PDPermission class 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.