InfoCenter Home >
5: Securing applications -- special topics >
5.1: The WebSphere security components

5.1: The WebSphere security components

Security for the WebSphere Application Server product is managed as a collaborative effort by these components distributed throughout WebSphere Application Server:

  • Security server
  • Security collaborator
  • Security plug-in
These components collectively make up the WebSphere security application. Each is attached to a primary WebSphere Application Server component:
  • The security server is attached to the WebSphere administrative server.
  • The security collaborator is attached to application servers.
  • The security plug-in is attached to supported Web servers.

Together, the security components provide a unified security model, allowing a single policy to govern the security of a diverse set of resources.

A realm is the domain in which a security system operates. All of the related applications reside in the same realm. The administrator sets the name for the realm, and applications and their supporting services like security operate within that single realm.

The security server

The run-time security components (the plug-in and the collaborator) consult the security server, which controls security policies and provides authentication and authorization services. The run-time components enforce these policies.

The security server has two primary purposes:

  • To centralize control over security policies such as permissions.
  • To provide application-wide services like authentication and authorization.

In both of these capacities, the security server acts as a trusted third-party for security policy and control. The run-time components consult the security server for policy information and for services such as authentication and authorization, including token services for Lightweight Third-Party Authentication (LTPA).

The security server provides authentication services.

The security server uses persistent storage (like a DB2 database) to store its configuration information permanently.

The security collaborator

The security collaborator is a component of the application server process, which acts as a common run-time environment for servlets and JavaServer Pages (JSP) files. When a Java client attempts to invoke a method on a servlet, the security collaborator does the following:

  • Performs an authorization check.
  • Logs security-tracing information.

For example, when a Web client invokes a servlet, the user is prompted for a user ID and password, and the method invocation is passed to the application server. The security collaborator authenticates the user against the user registry, and if the authentication succeeds, the collaborator consults the security server to determine if the user is authorized to invoke the servlet.

If so, the collaborator then consults the security server for any delegation information. The security collaborator builds a security context that contains the appropriate information for the user. If, for example, the delegation policy says that methods are invoked under the user's credentials, the directly requested servlet and any methods it calls are invoked under the user's credentials. For each indirect invocation, the collaborator ensures that the user has permission on the invoked method as well.

The security plug-in

The security plug-in resides with the Web server and protects access to HTML pages served by the Web server. (The security collaborator performs all other security checks.) When a Web resource is protected by WebSphere Application Server security, the security plug-in consults the security server for authentication and authorization services.

For example, when a user invokes a servlet by entering its URL in a Web browser, the target Web server receives the request. It ascertains whether the URL is protected. If the URL is protected, it challenges the user to provide a user ID and password. The plug-in collects this information and passes it to the security server for authentication. If the authentication succeeds, the plug-in consults the security server to determine if the user has the permissions necessary to access the URL. If the user is authorized, the plug-in sets up a security context for the user, including the security credentials, and passes the request to the servlet engine in the application server process. Before invoking a specific method on the servlet, the security collaborator extracts the credentials and verifies that the user is authorized to invoke that method.

Note   The security plug-in protects the URL name space, not the physical files. This means that if two URLs point to the same physical resource, security on one URL can grant access while security on another URL can deny it.

IBM WebSphere Application Server Version 3.5 Security Overview is available from the IBM White Papers site.
Go to previous article: Securing applications -- special topics Go to next article: Security features

 

 
Go to previous article: Securing applications -- special topics Go to next article: Security features
Go to previous article: Securing applications -- special topics Go to next article: Security features

 

 
Go to previous article: Securing applications -- special topics Go to next article: Security features