Web Server Installation
|
 |
 |
|
 |
 |
This section covers the following topics:
This document provides security administrators with the information needed to install and configure three BEA® WebLogic® Enterprise Security products:
This section covers the following topics:
It is assumed that readers understand web technologies and have a general understanding of the Microsoft Windows or UNIX operating systems being used. The general audience for this installation guide includes:
Prior to reading this guide, you should read the Introduction to BEA WebLogic Enterprise Security. This document describes how the product works and provides conceptual information that is helpful to understanding the necessary installation components.
Additionally, BEA WebLogic Enterprise Security includes many unique terms and concepts that you need to understand. These terms and concepts—which you will encounter throughout the documentation—are defined in the Glossary.
This document provides security administrators with the information needed to install and configure the Web Server Security Service Module.
The document is organized as follows:
BEA product documentation, along with other information about BEA software, is available from the BEA dev2dev web site:
To view the documentation for a particular product, select that product from the Product Centers menu on the left side of the screen on the dev2dev page. Select More Product Centers. From the BEA Products list, choose WebLogic Enterprise Security 4.2. The home page for this product is displayed. From the Resources menu, choose Documentation 4.2. The home page for the complete documentation set for the product and release you have selected is displayed.
The BEA corporate web site provides all documentation for BEA WebLogic Enterprise Security products. Other documents that may be of interest to the reader include:
Your feedback on the BEA Web Server documentation is important to us. Send us e-mail at docsupport@bea.com if you have questions or comments. Your comments will be reviewed directly by the BEA professionals who create and update the Web Server documentation.
In your e-mail message, please indicate that you are using the documentation for BEA WebLogic Enterprise Security Web Server Security Service Module 4.2 SP2.
If you have any questions about this version of Web Server, or if you have problems installing and running the product, contact BEA Customer Support at http://support.bea.com. You can also contact Customer Support by using the contact information provided on the quick reference sheet titled "BEA Customer Support," which is included in the product package.
When contacting Customer Support, be prepared to provide the following information:
The BEA Weblogic Enterprise Security provides three Web Server products: the IIS Web Server Security Service Module (SSM), the Apache Web Server SSM, and the Web Services SSM (see Figure 1-1).
Note: Henceforth, the IIS and Apache Web Server SSM products will be generally referred to in this document as the Web Server SSM. When it is necessary to highlight differences, they will be referred to specifically be name.
Figure 1-1 Web Server Product Components
The following topics provide more information on the these products:
Figure 1-2 shows the major components that make up the BEA WebLogic Enterprise Security Web Server product environment.
Figure 1-2 Web Server Product Environment
The Administration Application allows you to configure, deploy, and manage multiple Security Service Modules in a distributed environment. While the modules consume configuration data and then service security requests accordingly, the Administration Application allows you to configure and deploy security configuration information to the modules and modify that information as needed.
The Service Control Manager (SCM) is an essential component of the configuration provisioning mechanism and a key component of a fully-distributed security enforcement architecture. A Service Control Manager is a machine agent that exposes a provisioning, or deployment, interface to the Administration Application to facilitate the management of a potentially large number of distributed Security Service Modules (SSMs). The Service Control Manager can receive and store meta-data updates, both full and incremental, initiated by the Administration Application.
The Administration Application uses this provisioning mechanism to distribute configuration data to each enrolled instance of a SSM where it is stored locally (see Figure 1-3). Each instance of a SSM is assigned a unique configuration ID, which is registered with the SCM when the SSM is enrolled. The SCM uses the configuration ID when distributing and updating configuration data to each SSM instance to ensure that the correct data is distributed.
The Web Server Security Service Module (SSM) is used to adapt web servers to the WebLogic Enterprise Security infrastructure so that web server resources can be protected by a custom security configuration. You define and deploy the security configuration using the Administration Application. You can only configure one instance of each type of Web Server SSM (IIS, Apache and Web Services) on a single machine, however, the number of machines in your network on which you can configure Web Server SSMs is unlimited (see Figure 1-3). After you deploy the initial security configuration to a Web Server SSM, it does not require any additional communication with the Service Control Manager (SCM) to perform runtime security functions. However, the SCM does maintain communication with each Web Server SSM instance so that it can distribute, or deploy, full and incremental security configuration updates.
Figure 1-3 Deploying Security Configuration Data
The Web Server Security Service Module (SSM) provides an environmental binding between the WebLogic Enterprise Security infrastructure and IIS and Apache web servers. The WebLogic Enterprise Security infrastructure provides six distinct services: Registry, Authentication, Authorization, Auditing, Role Mapping, and Credential Mapping. Each of these services is expressed in a way that is understandable to applications running within a web server that is protected by the WebLogic Enterprise Security infrastructure. Therefore, the SSM can be used to configured and enforce security for web server applications and resources.
The Web Server SSM makes access control decisions for the web server to which it is bound. The security configuration on which the access control decisions are based is defined and deployed by the Administration Server via the Security Control Module.
You can tailor the Web Server SSM to meet your specific needs. Using templates provided as part of the product, security developers can customize the look and feel of authentication pages and configure parameters that allow fine tuning for a particular installation. Web applications can have information added to the HTTP request by the security framework, such as roles and response attributes. Additionally, the Web Server SSM enables security administrators and web developers to perform security tasks for applications running on a web server.
Figure 1-4 shows the components of the Web Server SSM. The following topics describe the components:
Figure 1-4 Web Server SSM Components
The environmental binding is used to bind with and interact with specific types of web servers. Bindings are provided for two types of web servers: ASF Apache and Microsoft IIS. The second function is ultimately for enforcing access control and providing a means of implementing the SAML Browser/POST profile.
After you install the Web Server SSM, you use it to bind it to the web server, which, in effect, projects the WebLogic Enterprise Security subsystem into the web server environment. For the Microsoft IIS Web Servers, the binding is implemented using the ISAPI. For the Apache Web Servers, the binding is implemented using an Apache module. The Web Server SSM accepts HTTPS requests from the web server and presents them to the Security Framework using the Web Services SSM.
Additionally, the Web Server SSM implements the server-side includes (SSIs) that process SAML Browser/POST profile.
The Web Services Security Service APIs enable access to the Security Framework. These APIs provide the following security services:
Note: The following topics provide a very brief description of these APIs. For more information, see Programming Security for Web Services.
There are two variations of authentication, JAAS-based and identity assertion. JAAS-based authentication collects evidence (credentials) from a user in order to establish user identity.
Note: For more information on JAAS, see Java Authentication and Authorization Service (JAAS) on the Web at http://java.sun.com/products/jaas/.
Identity assertion authentication consumes a trusted token object to establish identity. The Web Services SSM supports both types of authentication.
Note: The Web Services SSM does not support custom callback types.
The Web Services SSM security infrastructure provides fine grained highly contextual authorization. However, the granularity of the authorization decision is often restricted by the web server you are protecting. The only standard form of addressable resource in a web server is a URL, so that is the resource that is protected with the HTTP method as the operation on the resource.
In addition to providing a simple permit or denied decision on a URL, the authorization service also has the ability to return attributes into the request as determined by security policy. Because the inclusion of coding in the application to handle these attributes creates an undue coupling between the application and security infrastructure, the Security Service Module inserts these returned attributes into the HTTP request header. Depending upon the technology used (ASP, CGI, ISAPI), these headers can be extracted and used by the application.
The auditing service audits all transactions through the security subsystem. Every URL accessed is sent through the auditing infrastructure.
Although roles are primarily used in authorization, some applications may wish to have access to the roles to which a user is mapped for the purposes of role-based personalization. In order to provide this information to the running applications, the Web Services SSM adds a list of roles to the HTTP request header. Depending upon the technology used (ASP, CGI, ISAPI), the application can extract this list of roles from the header and use it.
The credential service returns sensitive credentials to an application so that the application can use systems that require a secondary (or tertiary) layer of authentication. The Web Services SSM extracts mapped credentials from the security system and makes them available in the HTTP header for use by the application. Depending upon the technology used (ASP, CGI, ISAPI), the application can extract the credential headers and use them to authenticate to other back-end systems.
When you install a Security Service Module, a JAR file is deployed that contains all the security providers that ship with the product. However, before any of the security providers can be used, you must use the Administration Console to configure them. You have the option of configuring either the security providers that ship with the product or custom security providers, which you may develop yourself or purchase from third-party security vendors.
Note: To use security providers with the Security Service Module, you must deploy the security provider MBean JAR file (MJF) to the providers directory on both the machine on which you install the Security Service Module and on the machine on which you install the Administration Console.
The Security Service Module supports the following security providers:
For more information on security providers, see Introduction to BEA WebLogic Enterprise Security, the Administration Application Guide, and the Console Help.
For more information on how to develop custom security providers, see Developing Security Providers for BEA WebLogic Enterprise Security.
This section describes the features of the Web Server Security Service Module. The following topics are covered:
This section covers the following topics:
Web single sign-on is an access-control mechanism that enables users to log on to one web server and gain access to other web servers in the same domain without supplying log-in credentials again, even though the other web servers may have their own authentication schemes or requirements. Figure 1-5 shows the basic components of a web single sign-on service.
While web single sign-on removes the requirement for users to log on every time they access a different web server and thus makes user access easier, it does not improve security. In fact, you should take security requirements into consideration when implementing a web single sign-on solution.
The Web Server Security Service Module (SSM) supports the following single sign-on (SSO) use cases.
Figure 1-6 Web Server SSM to Web Server SSM Single Sing-on
Figure 1-7 Web Server SSM to WebLogic Server SSM Single Sign-On
The Web Server Security Service Module (SSM) and WebLogic Server 8.1 SSM support single sign-on using the ALES Identity Assertion provider.
For instructions on how to implement Single Sign-On, see Configuring Web Single Sign-on with ALES Identity Assertion.
The authentication service supports the following features:
Note: If a new callback type is encountered during authentication, the Web Server SSM ignores it.
The authorization service supports the following features:
.." and decodes URL encoding. The resource is presented as the path element of a URL and the file or application name. For example, the following URL:http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/
isAuthenticationRequired() method to check whether a resource is protected by a security system. This feature is important because you may want to leave some web server resources unprotected.The auditing service has the following capabilities:
The role mapping service has the following capabilities:
Note: It is important to note that roles are not global in WebLogic Enterprise Security but can change depending upon the resource and various elements of the context.
Credentials are any objects or set of objects that can be used as evidence for the propagation of identity or for impersonation. WebLogic Enterprise Security defines two types of credential objects: username/password credentials and generic credentials; however, there is no limitation as to the format of objects that can be used. Credentials can be "mapped" and associated with a resource and identity or an alias.
The credential mapping service has the following features:
In addition to configuring security providers for the SSM, administering the security configuration involves writing security policy for users, groups, roles, and resources policy for the web application resources the SSM protects. The Web Server SSM has the following features:
Presents the full URL—The Web Server SSM makes the full URL, including the protocol, server name, port, full path, and query string, available to the security framework. The full URL is presented as part of the context to allow its use in security policy. However, the resource presented to the system is in the canonical form. For example, for a web server with the names www.bea.com, www.beasys.com, www. web.internal.bea.com, and 204.236.43.12 , the canonical name is www.bea.com.
The WebLogic Enterprise Security services are stateless services, so it is the client of the Web Services SSM that is responsible for determining session related information. In addition, in HTTP, there is no notion of a logout, and so session termination must be inferred by a lack of activity. Therefore, to manage session behavior, the Web Server SSM has the following capabilities:
Configuration includes the process by which the web server is integrated with the Web Server SSM. Specifically, the web server is configured to use the filter component of the Web Server SSM. Local configuration of the web server should only be necessary once and should be static.
The Web Server SSM has the following configuration capabilities:
The Web Server SSM has the following constraints and limitations:
|
|
|