| Let's start with a review of the Domino and WebSphere security models. For our discussion here, we assume you are at least conceptually familiar with the major Internet standard security mechanisms, such as HTTP basic ( name and password) authentication, SSL authentication via public key certificates, and user directory protocols such as LDAP and X.500 naming formats. When discussing security configuration, we also assume the reader has some familiarity with both WebSphere and Domino administration functions. Domino Security The Domino security model is referred to as a "resource-based" model; that is, the control of access to resources is defined on the resources to be protected. Specifically, the users and the types of actions permitted to users are defined in Access Control Lists (ACLs) stored with any Domino database. The access controls can be further refined at the document or field level. Additional access controls to the Domino server itself can be specified in the server configuration document (the "server" document in the Domino directory). You specify the set of users and user groups to be granted access to a Domino database and their level of access in the database ACL. Two special user names can be specified, "Default" and "Anonymous." The Default user name controls the level of access granted to users not specified in the ACL. The Anonymous user name controls the level of access granted to unauthenticated users making Web requests to the Domino server. If both the Default and Anonymous users are specified with a level of "No Access," then a requesting user must be authenticated and matched to a user or group name in the ACL. (This assumes that the requesting user has been permitted access to the server itself.) You specify the type of authentication and session protocol via the port configuration in the Domino server document. For the HTTP port, basic authentication, SSL client-certificate, or session-based (cookie) authentication are supported. WebSphere Security As one would expect, the WebSphere security model conforms to the J2EE security model. The WAS security functions are an implementation of the security services specified by the J2EE standard. The J2EE security model is characterized as a "role-based" model. A security role is a logical group of users defined by the J2EE application designer for the purpose of controlling access to application resources. Access controls (referred to as "security constraints") are specified within a J2EE application in terms of the defined security roles. For example, an application may define security roles of " employees " and "customers" and a security constraint, which specifies that the GetBenefits servlet may be permitted to only the "employees" role. The type of user authentication to be used by the application server also can be specified within the application. Security functions can only be defined for J2EE enterprise applications. When a J2EE enterprise application is deployed to an application server, the application security roles are mapped to specific users or groups defined in the server's user registry (directory). When the application runs, the application server performs user authentication and applies the security constraints on requests for those resources protected by constraints. To be precise, the container managing the particular J2EE component applies the security function ”the Web container applies security for servlets and JSPs, and the EJB container applies security for EJBs. There are two basic means of specifying access controls within a J2EE application. One way is by defining the security roles and constraints in the application deployment descriptors. This method is referred to as "declarative" security. The other way is to define the security constraints within the application code, referred to as "programmatic" security. Using the declarative security method leads to more portable and flexible applications. Programmatic security can be used when the application security requirements can't be met by declarative security functions. As we will see later, sometimes programmatic security must be used to achieve the desired authentication and access control for an application implemented across WebSphere and Domino. The Single Sign-On (SSO) Problem Any security model, whether resource-based or role-based, is predicated on validating that a connecting user is who they say they are, or "user authentication." Both WebSphere and Domino need to authenticate any user attempting access to a protected resource. User authentication is most often done using some sort of credential check or "sign-on" exchange. When a user interacts with a Web application involving protected resources, they naturally expect to be prompted for a sign-on only once for the Web session. Unfortunately, this was not always the case with applications served by both WebSphere and Domino. We had the "SSO problem." The SSO problem arises when both Domino and WebSphere are configured to use a standard user authentication mechanism, most often HTTP basic authentication. Because both Domino and WebSphere may be serving different components of a Web application separately, they may not be aware that a user has already been authenticated on a previous request and will attempt to reauthenticate the user. If the request URL is different enough from the previous (that is, belongs to a different "realm"), the browser will ask the user for their userid and password again. Thus, the user sees two or more annoying prompts for their userid and password within the same Web application. In order to provide SSO authentication, both WAS and Domino must generate and understand a common set of authentication information. Indeed WAS and Domino are capable of performing shared authentication with the current product versions and and in versions dating back to WAS 3.5 and Domino R5.05. WAS and Domino are able to recognize previous user authentications, even if they were established by the other product. They employ the HTTP "cookie" mechanism to keep track of user authentications within an HTTP session. Using cookies, which are stored on and returned by the browser, each can recognize when a user has already been authenticated by the other. The use of shared authentication tokens as cookies provides SSO. Next, we'll discuss some of the detail of how SSO works and some of the issues involved. | 