InfoCenter Home > 5.1: The WebSphere security componentsSecurity for the WebSphere Application Server product is managed as a collaborative effort by these components distributed throughout WebSphere Application Server:
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 serverThe 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:
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 collaboratorThe 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:
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-inThe 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.
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|