Overview of BEA AquaLogic Enterprise Security

This document summarizes the features of the BEA AquaLogic® Enterprise Security™ products and presents an overview of the architecture and capabilities of the security services.

What Is BEA AquaLogic Enterprise Security?

BEA AquaLogic Enterprise Security (ALES) is a fine-grained entitlements engine that allows the user to centrally define and manage policy to control access for both application software components (for example, URLs, EJBs, EJB methods, and so on.) as well as the application business objects (for example, accounts and patients records) that make up the application. Policy is evaluated and enforced locally in the application container so application context can be included as part of the access decision.

A major benefit of ALES as an entitlements engine is that it allows you to remove security logic from the application. Thus, you can take security decisions out of the hands of your developers and define access policy consistently across multiple applications. ALES is also a security infrastructure product that provides a platform for creating a security service layer that can be used by multiple applications. It provides a standard set of security services including authentication, authorization, role mapping, auditing, and credential mapping. The product is distributed in that access decisions are made and enforced at runtime in the application container through a set of Security Service Modules (SSMs).

ALES consists of two major components—the Administrative Server and a set of SSMs. The Administrative Server can be accessed through a browser-based console that you can use to define your users, groups, and roles, the resources in your application, the policies that control access, and the security configurations of the SSMs (see Figure 2-1). ALES also includes Java and Web Services Interfaces that provide administration APIs. You can use these APIs to incorporate ALES administrative functionality into your own applications or even to write your own administrative console. The Administration Server supports delegated administrate in that allows you to delegate administrative functions to other users. Further, it provides a policy analysis function that enables you to analyze your policies to see which policies apply to specific resources, users, groups, and roles. To assist you in defining the access control policies, the Administration Server provides a resource discovery feature that you can use to automatically generate a list of application resources and to create a set of default access policies. Finally, to assist you in transporting your access policies from one Administration Server to another, the Administration Server provides policy exporting and importing tools.

When a security configuration and/or policy is changed, you must distribute it so as to take effect throughout the enterprise, across multiple application execution environments. An open standards-based design allows customers, integrators and vendors to develop and incorporate their own custom security services. And, common security functions can be leveraged by applications throughout the enterprise.

The SSMs plug into the application container and intercept requests, enforce access policies, and make access control decisions in real time. SSMs get updated policy information through a real-time policy distribution mechanism that keeps policy sets up to date and consistent between SSMs. The security framework, the heart of the SSM, provides a set of security services including authentication, authorization, role mapping, auditing and credential mapping. ALES provides SSMs for the BEA WebLogic Platform products and for popular Web servers, such as Microsoft Internet Information Services (IIS) and Apache. Java and Web Services Interfaces are also provided that are language and infrastructure neutral. Applications can invoke the ALES security services directly through either the Java or Web Services APIs. In summary, the ALES SSMs provide the runtime enforcement of policy and a powerful security services layer and can be used as an integration platform for multiple security products in your infrastructure.

Key Features

Support for securing the enterprise, including Security Service Modules for: BEA WebLogic Platform 8.1, Internet Information Services (IIS), Apache, web services, and Java applications.
Simplified infrastructure, that improves information technology efficiency because the application security infrastructure can be leveraged by applications across the enterprise. This feature effectively reduces integration costs and provides stronger investment protection in third-party security technologies through a standards-based architecture.
Centralized policy, leads to lower administration costs. Security administrators can define and deploy access policies without the need for re-coding or re-deploying applications. Policies are all managed through a central Administration Console. In addition, policy inquiry functions allow the administrator to validate access control policy implementations prior to deployment.
Delegation of administrative and user privileges, allows privileges granted to one user to be assigned to another user under certain conditions, or constraints.
BLM API for policy definition, provides programmatic access to the ALES policy management infrastructure. This is a Java API that uses SOAP to communicate with the central ALES management services. The API supports all of the functionality of the Administration Console including the creation and management of users, groups, roles, resources, resource authorization policies, and policy distribution and the security configuration and distribution. The BLM API examples (BEA_HOME\ales30-admin\examples\ policymgtwsapi) demonstrate how to use the BLM API for managing ALES roles and Policies.
For more information on the BLM API, see the BLM API Javadocs.
Java API, that allows security developers to develop environment interfaces or even integrate an application security infrastructure into an application. These Java interfaces support the most commonly required security functions and are organized into services that are logically grouped by functionality.
Web Services API, that allows security developers to write custom applications that invoke ALES 3.0 services through SOAP. These WSDL interfaces support the most commonly required security functions and are organized into services that are logically grouped by functionality.
Role-based access control, with integrated authentication, authorization and auditing. Administrators can design role-based access control (RBAC) policies to model their own business requirements, and then implement, test, and distribute them through a centralized Administration Server. You can include both resource and user attributes in your access control policies, along with other logical functions.
A comprehensive and standards-based design, to leverage Lightweight Directory Access Protocol (LDAP), Security Assertion Markup Language (SAML), Simple and Protected Negotiation mechanism (SPNEGO), eXtensible Access Control Markup Language (XACML), and Java. Additional support for standard security technologies, includes J2EE security technologies such as the Java Authentication and Authorization Service (JAAS), Java Secure Sockets Extensions (JSSE), and Java Cryptography Extensions (JCE).
Maximum performance, scalability, reliability, delivers a seamless, transparent experience for the user, while maintaining the necessary levels of application security through a distributed architecture.
Support for customizing security services, with step-by-step instructions, examples, and an open-standards model to help further reduce the cost of development. Security Service Provider Interfaces (SSPI) provide for rapid and simplified development of custom security services.

What is the Problem?

With the rush to build web-based applications and market services over the Internet, many developers had little comprehension of the security issues they may soon confront. Managing security is a huge challenge for any information technology organization that is providing new and expanded services to its employees, customers, and partners through both web-based and legacy applications. The advent of the Internet made protecting information and applications increasingly difficult to manage, monitor, and maintain. Financial transactions (ATM machines, bank transfers, credit card purchases and payments, stock market transactions), personal medical information (implementation of new Health Insurance Portability and Accountability Act or HIPPA regulations), Federal government facilities (Homeland Security affecting both military and civilian) provide only a few examples of areas where the concern for security has become essential and sometimes mandated by law.

Most applications require some form of security. As the complexity and volume of users and resources increases and with the rapid changes in business requirements that continue to evolve, the need for more stringent and robust security technologies becomes evident. To serve a worldwide network of users, an information technology organization must address the fundamental issues of maintaining the confidentiality, integrity and availability of the system and its data, providing the right information, to the right person, at the right time, across a diverse enterprise.

Because these applications often comprise a number of different components that may or may not reside on the same server or even in the same domain, policy management becomes extremely difficult and ensuring enterprise or regulatory compliance can prove impossible.

A typical application execution environment is multi-tiered as shown in Figure 2-3 and may be distributed (vertically or horizontally) between multiple machines running on different operating system platforms. In this case, you must protect each tier or application component. The type of access control and technology for each one may be different and you need to be able to enforce security at each layer.

To address the multitude of potential breaches of security associated with multi-tiered environments, companies have had to purchase and integrate a variety of different and custom security technologies from a host of different vendors:

Integration of security technologies requires the application developer to embed these technologies and hard-code both integrated and unified security requirements within each application. Thus, as the number of applications increases, the expenses associated with application development and maintenance also increases. As a best practice, the application developer should not be responsible for developing, implementing, and managing security requirements.

Early authorization implementations used static and inflexible approaches to define the different types of access granted or denied for a user. Because this type of implementation is extremely time-consuming (if only due to the number of users and the different types of user storage methods in use), it has become impractical for many implementations. Further, the cost of maintaining static first-generation security services can be exorbitant.

What is the Solution?

BEA has developed an application security infrastructure (ASI) that can be external to and isolated from the application itself. Using a services-oriented, policy-based architecture, you can replace the integrated security silo technologies and hard-coded policies. Figure 2-4 illustrates how a basic application execution environment can be protected using an integrated approach. Each component in the application requires protection, although the type of security typically varies.

A typical information technology environment consists of various types of servers– HTML, proxy, BEA WebLogic, Legacy, J2EE, and application– that access numerous LDAP and database servers containing information such as your user community (name, address, etc.). While the WebLogic platform servers provide application-level security for J2EE components, J2EE-based web services, portal and portlets (EJB, JSP/Servlet, JDNI, JDBC, JMS, MBeans), ALES provides application security for additional platforms and web servers.

The open flexible architecture of the ALES products provides advantages to all levels of users and introduces an advanced design for securing your applications. With distributed computing, applications must be integrated across the network, as shown in Figure 2-5. ALES provides a distributed enterprise security solution that, together with clear and well-documented policies and procedures, can insure the confidentiality, integrity and availability of its applications and data.

Distributed Computing Security Infrastructure

Applications across the enterprise are built on a heterogeneous infrastructure with diverse resources. With an application security infrastructure as shown in Figure 2-5, the ALES products support a fully distributed architecture; integrating all applications across the network.

The ALES products provide a variety of services that use the AquaLogic security framework, including enhanced policy-based authorization with role mapping, authentication with support for single-sign on and credential mapping, and customizable auditing features. A services-oriented strategy to application security infrastructure improves efficiency and strengthens security by providing a unified and consistent approach across the enterprise. BEA delivers security services that allow third-party security technologies to be exposed as reusable services, to further reduce integration time and costs, promote choice, and insure investment protection.

The type of security services you implement depends on the type of the application component you want to protect. You can use the set of security providers delivered with each Security Service Module to configure and enforce each security service or you can develop custom security providers.

The security services seek to provide ease of use, manageability for end users and administrators, and customizability for application developers and security developers. Administrators who configure and deploy applications can use the security providers included with the product that support most standard security functions or can create custom security providers. The product environments supported include WebLogic Server Versions 8.1 and 9.x/10.0, Internet Information Services (IIS) and Apache Web Servers, web services, and Java applications. ALES will expand this family of Security Service Modules in subsequent releases.

WebLogic Server 9.x/10.0 Security Service Module

The WebLogic Server 9.x/10.0 Security Service Module integrates ALES 3.0 with BEA WebLogic Server versions 9.1, 9.2, and 10.0.

WebLogic Server 8.1 Security Service Module

Supports BEA WebLogic Server, Version 8.1 and enhances the existing security services in the application server, providing customizable auditing, multi-domain standards-based single sign-on, database and Microsoft Window NT authentication, database credential mapping, and expanded policy expression capabilities for authorization and role assignments.

IIS Web Server Security Service Module

Supports the IIS Web Server. After installation, the security service module (SSM) binds with the web server through the web server application programming interface (ISAPI) so that the SSM can be used to protect web server application resources.

Apache Web Server Security Service Module

Supports the Apache Web Server. After installation, the SSM binds the web server through the web server filter so that the SSM can be used to protect web server application resources.

Web Services Security Service Module

An application programming interface (API) that allows security developers to write custom applications that invoke ALES 3.0 services through SOAP. These interfaces support the most commonly required security functions and are organized into services that are logically grouped by functionality.

Java Security Service Module

An application programming interface (API) that allows security developers to develop environment interfaces or even integrate an application security infrastructure into an application. These interfaces support the most commonly required security functions and are organized into services that are logically grouped by functionality.

Figure 2-6 Security Framework

Security Framework

Each Security Service Module is delivered with a full set of security providers. Table 2-1 lists the types of providers that are available for configuration.

Table 2-1 BEA AquaLogic Enterprise Security Service Providers
Provider	Description
Authentication Provider	Supports open-standard support for SAML, SPNEGO, and X.509 identity assertion, and authentication support for Microsoft Windows NT, Microsoft Active Directory, Netscape LDAP, Novell LDAP, relational database, and OpenLDAP login modules.
Credential Mapping Provider	Maps credentials used by a legacy or any remote system. The application then uses the appropriate credentials to log in to a remote system on behalf of a subject that already authenticated to support single sign on.
Authorization Provider	Controls access to resources based on the role and policy assigned to the requested resource. An access decision is the part of the authorization provider that actually determines whether a user has permission to perform an operation on a resource. Authorization providers secure access to resources and transactions, enabling an organization with increasingly complex user communities to provide secure finely-grained access to resources. Access decisions, provided through a role-based authorization provider, incorporate relevant environmental, contextual, and transaction-specific information, allowing security policies to support business processes throughout the organization. In addition, an adjudication provider resolves authorization conflicts when you configure multiple authorization providers.
Role Mapping Provider	Supports dynamic role associations by obtaining a computed set of roles granted to a requestor for a resource.
Auditing Provider	Provides an electronic trail of all transaction activity and can include changes to system configuration parameters, policy changes, and transactions. For each audit item, the information can include who, what, when, where, and sometimes why.

How Our Solution Benefits You

Application Developers

Because most security for web applications and EJBs can be implemented by a system administrator, application developers do not need to be concerned about the details of securing the application, unless there are special considerations that must be addressed explicitly in the code. Security developers can also take advantage of BEA-supplied Application Programming Interfaces (APIs). Three sets of APIs are provided:

Server and Application Administrators

Administrators can use the security providers supplied as part of the product to implement an integrated solution. Administrators can use the Administration Server to define security roles and assign security policies to resources to create an authorization scheme that suites the needs of their business. In addition, the administrator can modify, test, and deploy the policy quickly and efficiently.

Security Developers

Third-party providers are integrating their products by using the Security Service Provider Interfaces (SSPI). As the underlying integration mechanism for security providers, the SSPI allows development of custom security providers. The SSPIs are available for Adjudication, Auditing, Authentication, Authorization, Credential Mapping, Identity Assertion, and Role Mapping. For information on the SSPIs, see Javadocs for Security Service Provider Interfaces.

This architecture allows security developers to provide integrated solutions that are easy to use. The result is a reduction in development requirements, which means an increased return on investment when implementing an enterprise security management solution. And, custom security services developed for WebLogic Platform 8.1 are compatible with the ALES services.

Security Architects

A dynamic role-based policy architecture eliminates the need for application developers to design and implement business policy and embed it within each and every instance of an application. More efficient policy administration enables an organization to adapt quickly to dynamic business processes as security policies are designed, tested, deployed, and distributed quickly by security administrators with no coding required.

Delegated administration allows for centralized control and delegated labor, enabling administrators more familiar with the needs of a particular user constituency to implement business policy.

It also allows the implementation of policies across a much larger, more complex, user community with standard policy (for example, consisting of employees, business partners, customers). If a change to a policy is required, it can be distributed throughout the enterprise and take effect whenever desired. With ALES products, if your application is already written to use some form of authentication or authorization schema, and the schema changes, no changes are required within the application.

Standards

Table 2-2 BEA AquaLogic Enterprise Security Standards
XML Standard	Used to
SAML	Participate in SAML-based single sign-on (SSO) environment.
WSDL 1.1	The Web Services Description Language (WSDL) is an XML-based specification that describes a web service. A WSDL document describes web service operations, input and output parameters, and how a client application connects to the web service.
Java Standards	Used to
CertPath	Retrieve X.509 digital certificates associated with infrastructure protection; available for customer direct use.
KeyStore	Retrieve RSA private keys associated with X.509 digital certificates associated with infrastructure protection; available for customer direct use.
JSSE	Protect infrastructure network connections for establishment of mutual trust.
JCE	Integrate cryptographic libraries.
JAAS	Provide authentication service implementations.
Miscellaneous Standards	Used to
XACML 2.0	XACML, the eXtensible Access Control Markup Language, is an OASIS standard. XACML is a standard language for expressing access control, or authorization, policy, and a standard format for expressing queries over these policies.
X.509	Validate the identity of infrastructure components through digital certificates; supported as proof of identity for customer use.
LDAP v3	Retrieve configuration information from the Service Control Manager, and user identity and user attributes from an LDAP v3 directory server.
ISAPI	Support compliant runtimes for authentication, SAML single sign-on, and protection of hosted web pages.
FIPS 140	Support certification of the embedded cryptographic libraries used for cryptographic protection and TLS protocol.
TLS v1 and SSL	Protect network communication between infrastructure components.
JDBC	Provide access to database stores using the database provider.

Examples

This release of ALES 3.0 includes the Administration Console and SSM examples shown inTable 2-1.

Table 2-3 AquaLogic Enterprise Security Examples
Example Location	Description
Admin Examples
`BEA_HOME`\`ales30-admin\DBSetupKit\README`	Provides an example of installing and configuring a policy database for ALES. It also provides an example of installing an Oracle database.
`BEA_HOME`\`ales30-admin\policy\aldsp_sample_policy\README.tx`t	Provides an example of importing the AquaLogic Data Services Platform sample policy.
`BEA_HOME`\`ales30-admin\policy\alsb_sample_policy\README.tx`t	Provides an example of importing the AquaLogic Service Bus sample policy.
`BEA_HOME`\`ales30-admin\policy\portal_sample_policy\README.txt`	Provides an example of importing the WebLogic Portal sample policy.
`BEA_HOME`\`ales30-admin\policymgtapi\readme.txt`	Demonstrates how to use the ALES BLM JAVA API for managing ALES.
`BEA_HOME`\`ales30-admin\policymgtwsapi\readme.txt`	Demonstrates how to use the ALES BLM Web Service API for managing ALES roles and policies. This example demos how to establish a session with a remote BLM service, and how to do some simple operations using the BLM Web Service API.
`BEA_HOME`\`ales30-admin\examples\EJBAppExample`	Demonstrates the principles of an EJB application functioning under the ALES framework. The example shows how the additional layer provided by ALES can make an EJB application more secure by defining custom dynamic authorization policies without any changes in the application or the deployment descriptors.
Java SSM Examples
`BEA_HOME\ales30-ssm\java-ssm\examples\AttributeRetriever\README`	This example shows how to implement a custom Attribute Retriever.
`BEA_HOME\ales30-ssm\java-ssm\examples\JavaAPIExample\README`	This example shows how to use Java SSM APIs to retrieve basic security services, and use them to do authentication, authorization, and auditing.
`BEA_HOME\ales30-ssm\java-ssm\examples\QueryResources\README`	This example shows how to get a list of the resources granted to a user. It also retrieves the list of resources denied to a user.
Web Services SSM Examples
`BEA_HOME\ales30-ssm\webservice-ssm\examples\JavaWebServiceClient\README`	This example shows how to connect to a Web Service SSM, retrieve basic security services, and use them to do authentication, authorization, and auditing.
`BEA_HOME\ales30-ssm\webservice-ssm\examples\SsmNet\README`	This sample demonstrates how to access ALES Web Service SSM through its published WSDL in the .NET environment. This sample contains two parts: An abstraction layer that encapsulates the stub code generated from the WSDL. A simple ASP.NET web application that covers all the interfaces exposed by the Web Service SSM.
`BEA_HOME\ales30-ssm\webservice-ssm\examples\SsmWorkshop\readme.txt`	This example is a simple web application based on page flow, which uses a service control generated from ALES SSM web service WSDL file by Workshop to protect it's content.
`BEA_HOME\ales30-ssm\webservice-ssm\examples\XACMLClient\README`	XACML client is a simple client that does authorization to the Web Service SSM using the XACML protocol. It needs to first authenticate with the Web Service SSM and retrieve an identity assertion, then authorize with the identity assertion as subject.
WLS SSM Examples
`BEA_HOME\ales30-ssm\wls-ssm\examples\ALESEnabledWLP92Domain\README`	This example shows how to protect a WebLogic Portal application using WLS 9.x/10.0 SSM.
WLS 8 SSM Examples
`BEA_HOME\ales30-ssm\wls8-ssm\examples\ALESEnabledWLPDomain\README`	This example shows how to protect a Portal application using WLS SSM.
`BEA_HOME\ales30-ssm\wls8-ssm\examples\ALESEnabledWLSCluster\README`	ALES Enabled WLS Cluster Example.
`BEA_HOME`\`ales30-ssm\wls8-ssm\examples\ResourceConverter`	Resource Converter is a Java-based plug-in that acts as a provider extension to extend the capabilities of the ASI Authorization provider. The example implements a custom Resource Converter.
`BEA_HOME`\`ales30-ssm\wls8-ssm\examples\SAMLServletExample`	The SAML Servlet example demonstrates how an application can use the SAML servlet to use SAML Assertions to allow servers in different domains to operate in a federation of trusted servers based on successful Single Sign On (SSO) login to one of the servers by a user.
`BEA_HOME`\`ales30-ssm\wls8-ssm\examples\taglib`	This example shows how to use ALES with taglibs. This example includes a set of sample taglibs and a simple web application that uses those tags in its index.jsp.

Introduction