|
|
This section describes the general architecture of the ALES services, providers and service modules. Each Security Service Module comes with a set of security providers. Although applications can leverage the services offered through the existing security providers, the flexible infrastructure also allows security vendors, integrators, and customers to write their own security providers. The ALES providers and third-party security providers can be mixed and matched to create unique security solutions, allowing organizations to take advantage of new technology advances in some areas while retaining proven methods in others. The Administration Server allows you to configure and manage all your security providers and service modules through one unified management console.
The architecture comprises the following major components, which are discussed in the following sections:
The Administration Server gives you the enterprise-wide visibility you need to analyze security policies and ensure that applications and resources are properly protected. ALES also lets you delegate security administration to remote administrators who often better understand local users and business needs and who are better positioned to manage the security policies. By combining centralized control with delegated administration, you can define and manage overall policies while specifying the management responsibilities to be handled by organizational administrators. For additional information on the Administration Server features, see Security Administration. The Administration Server consists of several components (as shown in Figure 3-1), including:
Policy Distributor—Ensures that the correct policies are provided to each Security Service Module and maintains policy synchronization.
Policy Database—Maintains policy data managed by the Administration Server in a relational database. The database management system provides the authoritative source of configuration and policy. Data from the policy database is distributed to the Security Service Modules by the Policy Distributor.
Policy Exporter—Exports policy data from the policy database for later use with the same Administration Server or another instance of the Administration Server.
Policy Loader—Imports policy data from an external file, generated in another system, exported from another instance of an Administration Server, or manually coded.
Administration Console and Entitlements Management Tool—Supports administrative policy security and administration delegation through browser-based user interfaces. Security configuration, policy configuration, user attributes (if required), resources, and rules are all managed through these console.
Administration Logic—Maintains the Policy Database used by both the administration consoles and the Policy Loader.
ALES employs a fully-distributed security enforcement architecture consisting of Security Service Modules embedded in the applications, application servers, and web servers being secured (see Figure 3-2). To facilitate the management of a potentially large number of distributed Security Service Modules, the Administration Server uses a remote administration mechanism to distribute appropriate configuration and policy data to each Security Service Module.
The Service Control Module (SCM) is an essential component of this remote administration mechanism. Each Service Control Module is responsible for storing and maintaining the configuration data for all Security Service Modules running its machine. Once started, a Security Service Module receives its configuration data from the local Service Control Module. When a change is made and distributed from the Administration Server, the Service Control Manager receives the change and updates the cached copy of the configuration. On restart, the Security Service Module receives updated configuration data from the Service Control Manager. Policy data does not require a restart, but is applied based on the desired provisioning characteristics.
| Note: | It is possible to deploy an SSM without the SCM. You can use the PolicyIX tool, described in PolicyIX in the Administration Reference, to communicate directly with the BLM and retrieve configuration data. The PolicyIX tool allows you to export configuration data (configured either through the ALES Administration Console or directly via the BLM API) for a given SSM to an XML file, and use it with the configured SSMs when the SCM is not available. See the SSM Installation and Configuration Guide for additional information. |
| Note: | The SCM is always installed on the ALES Administration server. |
In addition to facilitating management, the Service Control Manager enables Security Service Modules to operate in the absence of the Administration Server. Because the Service Control Manager maintains a persistent copy of each configuration, new Security Service Modules can be started and existing Security Service Modules continue to function, even if the Administration Server goes down or is intentionally unavailable, such as in occasionally connected computing environments.
ALES supports a variety of Security Service Modules that you integrate with the security framework and provision as needed. The primary function of the security framework is to provide a simple application programming interface (API) that can be used by security and application developers to define security services. For a complete discussion of ALES services, see Security Services. You may incorporate as many Security Service Modules as you need to secure the enterprise, and configure and manage them directly through a central Administration Server as shown in Figure 3-2. The distributed nature of the architecture allows you to configure, manage and distribute policy throughout the enterprise.
Configuration data for each Security Service Module is maintained within each machine and handled by a Service Control Manager. One additional benefit of this architecture is that even if the administration server goes down (either for maintenance or due to failure), there is no impact on the applications or security services provided by those Security Service Modules. At this time, the following Security Service Modules are available:
The WebLogic Server 8.1 Security Service Module is a security enhancement product that supports BEA WebLogic Server, Version 8.1. Further, the Security Service Module ties the application server into the Administration Server so that all application server administrative security activities are performed through the Administration Server. The application server with the Security Service Module add-on supports enterprise-level security by making security for WebLogic Server host applications an integral part of the enterprise policy. All WebLogic Server security-related functions remain available, but those functions are provided through the Security Service Module. Figure 3-3 shows the major components of the WebLogic Server 8.1 Security Service Module.
The WebLogic Server 9.x/10.0 Security Service Module is a security enhancement product that supports BEA WebLogic Server, Version 9.x/10.0.
This SSM uses a different security framework from the one used in the WebLogic Server 8.1 SSM and the other AquaLogic Enterprise Security SSMs. When you install the WebLogic Server 9.x SSM, AquaLogic Enterprise Security uses the WebLogic Server 9.x security framework. As a consequence, when you use the WebLogic Server 9.x SSM, you configure security providers and other aspects of the SSM in the WebLogic Administration Console, rather than the AquaLogic Enterprise Security Administration Console.
You still use the AquaLogic Enterprise Security Administration Console to write security policies for all SSMs, and to configure SSMs other than the WLS 9.x SSM. You must also use the ALES Administration Console to configure the ASI Authorizer and ASI Role Mapper providers.
The Web Server Security Service Module (SSM) provides an environmental binding between the ALES infrastructure and IIS and Apache web servers. The SSM consists of three components, a Web Server Environmental Binding, an internal Web Services Client, and the Web Services SSM (which includes the Security Service APIs, Security Framework and security providers) (See Figure 3-4). The ALES 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 ALES 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.
The environmental binding is used to bind to and interact with web servers. Binding a Web Server SSM to the server projects the ALES subsystem into the web server environment. The SSM accepts HTTPS requests from the web server and presents them to the ALES security framework.
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. Additionally, the Web Server SSM implements the server-side includes (SSIs) that process SAML Browser/POST profile.
This section covers the following topics:
Web single sign-on enables users to log on to one web server and gain access to other web servers in the same domain without supplying login credentials again, even if the other web servers have different authentication schemes or requirements. Figure 3-5 shows the basic components of a web single sign-on service.
While web single sign-on facilitates access and ease of use, it does not improve security. In fact, security requirements should be considered when implementing a web single sign-on solution.
The Web Server SSM supports the following single sign-on (SSO) use cases.
The Web Server and WebLogic Server SSMs support single sign-on using the ALES Identity Assertion provider.
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, http://www.example.com/framework.jsp?CNT=index.htm&FP=/products/aqualogic/ is presented as /framework.jsp. The query arguments CNT and FP and associated values are made available in the application context.isAuthenticationRequired() method to check if 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 supports hard-coded roles in applications. Generally hard-coding behavior into an application based on roles is not recommended. It is possible, however, that some customers may need to replace an existing system that uses this mechanism or may want to use roles for user interface personalization. Support for this feature requires that a list of mapped roles available from a security provider for a particular request be provided in a usable form by applications running within the web server.
| Note: | It is important to note that roles are not global in ALES but can change depending upon the resource and various elements of the context. |
ALES 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:
Administering the security configuration involves writing policies for users, groups, roles, and the web application resources that the SSM protects. The Web Server SSM has the following features:
To manage session behavior, the Web Server SSM supports the following capabilities:
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:
The Web Services SSM provides an application programming interface (API) that allows security developers to write custom application clients that invoke AquaLogic Enterprise Security services through SOAP. These interfaces support the most commonly required security functions and are organized into services that are logically grouped by functionality.
A Web Service client can use the Web Services SSM (which incorporates the Security Services APIs, the Security Framework, and the configured security providers) to make access control decisions for the web server to which it is connected. Then you can use the AquaLogic Enterprise Security Administration Server to configure and deploy a security configuration to protect the web server application resources. Thus, the Web Services SSM enables security administrators and web developers to perform security tasks for applications running on a web server.
The Web Services Security Service Module (SSM) provides five security services: Authentication, Authorization, Auditing, Role Mapping, and Credential Mapping (see Figure 3-8). The WSDL provided for these services can be used to developed web services clients to access the ALES infrastructure and use it to make access control decisions for custom applications.
Figure 3-8 shows the components of the Web Services SSM.
The Web Services SSM includes a set of examples that illustrate Web Services client development in different environments. The examples are located in BEA_HOME/ales30-ssm/examples:
Demonstrates how to access the ALES Web Services SSM through its published WSDL in a WebLogic Workshop 8.1 or 9.x /10.0 environment.
Demonstrates how to access the ALES Web Services SSM through its published WSDL in the .NET 1.1 or 2.0 environment.
Demonstrates a simple Java client that accesses the ALES Web Services SSM for authorization.
Demonstrates how to access the ALES Web Services SSM using the XACML protocol.
| Note: | For a Web Services client developed on Axis, use Axis 1.2 or later. For more information, see the Apache Axis site: http://ws.apache.org/axis/ . |
For more information about developing security services for Web Services client applications, see Programming Security for Web Services.
The Web Services Security Service APIs enable access to the ALES 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 Sun’s documentation 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. |
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 the access control policy implemented. Because the inclusion of coding in the application to handle these attributes creates an undue coupling between the application and security infrastructure, the SSM inserts these returned attributes into the SOAP request or response 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 SOAP request or response 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.
The Java Security Service Module provides an application programming interface (API) that allows security developers to insert security into their applications. These interfaces support the most commonly required security functions and are organized into services that are logically grouped by functionality.
After you use the Java Security Service Module interfaces to implement security functions in your Java application, you can deploy and run your application on any instance of a Java Security Service Module that supports the configuration requirements of your application. The Java Security Service Module offers five security services: Authentication Service, Authorization Service, Auditing Service, Role Service, and Credential Mapping Service. The name of each service indicates a type of function that can be implemented within a Java application. Each of these services is discussed in Security Services. Figure 3-9 shows the major components of the Java Security Service Module. The Java Security Service Module comprises the security service APIs, the security framework, and the security providers that you configure.
|