Understanding WebLogic Security

Overview of the WebLogic Security Service

The following sections introduce the WebLogic Security Service and its features:

Introduction to the WebLogic Security Service

Deploying, managing, and maintaining security is a huge challenge for an information technology (IT) organization that is providing new and expanded services to customers using the Web. To serve a worldwide network of Web-based users, an IT organization must address the fundamental issues of maintaining the confidentiality, integrity and availability of the system and its data. Challenges to security involve every component of the system, from the network itself to the individual client machines. Security across the infrastructure is a complex business that requires vigilance as well as established and well-communicated security policies and procedures.

WebLogic Server includes a security architecture that provides a unique and secure foundation for applications that are available via the Web. By taking advantage of the new security features in WebLogic Server, enterprises benefit from a comprehensive, flexible security infrastructure designed to address the security challenges of making applications available on the Web. WebLogic security can be used standalone to secure WebLogic Server applications or as part of an enterprise-wide, security management system that represents a best-in-breed, security management solution.

Features of the WebLogic Security Service

The open, flexible security architecture of WebLogic Server delivers advantages to all levels of users and introduces an advanced security design for application servers. Companies now have a unique application server security solution that, together with clear and well-documented security policies and procedures, can assure the confidentiality, integrity and availability of the server and its data.

The key features of the WebLogic Security Service include:

A comprehensive and standards-based design.
End-to-end security for WebLogic Server-hosted applications, from the mainframe to the Web browser.
Legacy security schemes that integrate with WebLogic Server security, allowing companies to leverage existing investments.
Security tools that are integrated into a flexible, unified system to ease security management across the enterprise.
Easy customization of application security to business requirements through mapping of company business rules to security policies.
A consistent model for applying security policies to J2EE and application-defined resources.
Easy updates to security policies. This release includes usability enhancements to the process of creating security policies as well as additional expressions that control access to WebLogic resources.
Easy adaptability for customized security solutions.
A modularized architecture, so that security infrastructures can change over time to meet the requirements of a particular company.
Support for configuring multiple security providers, as part of a transition scheme or upgrade path.
A separation between security details and application infrastructure, making security easier to deploy, manage, maintain, and modify as requirements change.
Default, WebLogic security providers that provide you with a working security scheme out of the box. This release supports additional authentication stores such as databases, and Windows NT account information.
Customization of security schemes using custom security providers
Unified management of security rules, security policies, and security providers through the WebLogic Server Administration Console.
Support for standard J2EE security technologies such as the Java Authentication and Authorization Service (JAAS), Java Secure Sockets Extensions (JSSE), Java Cryptography Extensions (JCE), and Java Authorization Contract for Containers (JACC).
A foundation for web services security including support for SAML.
Capabilities which allow WebLogic Server to participate in single sign-on (SSO) with Web sites, Web applications, and Desktop clients.
A framework for managing public keys which includes certificate lookup, verification, validation, and revocation as well as a certificate registry.
Improved performance of the Secure Sockets Layer (SSL) protocol and the LDAP Authentication providers.

Balancing Ease of Use and Customizability

The components and services of the WebLogic Security Service seek to strike a balance between ease of use, manageability (for end users and administrators), and customizability (for application developers and security developers). The following paragraphs highlight some examples:

Easy to use: For the end user, the secure WebLogic Server environment requires only a single sign-on for user authentication (ascertaining the user's identity). Users do not have to re-authenticate within the boundaries of the WebLogic Server domain that contains application resources. Single sign-on allows users to log on to the domain once per session rather than requiring them to log on to each resource or application separately.

For the developer and the administrator, WebLogic Server provides a new Domain Configuration Wizard to help with the creation of new domains with an administration server, managed servers, and optionally, a cluster, or with extending existing domains by adding individual severs. The Domain Configuration Wizard also automatically generates a config.xml file and start scripts for the server(s) you choose to add to the new domain.

Manageable: Administrators who configure and deploy applications in the WebLogic Server environment can use the WebLogic security providers included with the product. These default providers support all required security functions, out of the box. An administrator can store security data in the WebLogic Server-supplied, security store (an embedded, special-purpose, LDAP directory server) or use an external LDAP server, database, or user source. To simplify the configuration and management of security in WebLogic Server, a robust, default security configuration is provided.

Customizable: For application developers, WebLogic Server supports the WebLogic security API and J2EE security standards such as JAAS, JSS, JCE, and JACC. Using these APIs and standards, you can create a fine-grained and customized security environment for applications that connect to WebLogic Server.

For security developers, the WebLogic Server Security Service Provider Interfaces (SSPIs) support the development of custom security providers for the WebLogic Server environment.

New and Changed Features in This Release

This section describes features that have been added to the WebLogic Server in this release.

Note: If you are not familiar with the new features provided in version 9.0 of WebLogic Server, see the What's New in WebLogic Server 9.0 section of the WebLogic Server Release Notes, which is available here: What's New in WebLogic Server 9.0.

XACML 2.0 Authorization and Role Mapping Providers Are Now Supported

As of version 9.1, WebLogic Server has implementations of a set of authorization and role mapping providers that support the eXtensible Access Control Markup Language (XACML) 2.0 standard from OASIS. WebLogic Server includes two new security providers, the XACML Authorization provider and the XACML Role Mapping provider.

These providers can import, export, persist and execute policy expressed using all standard XACML 2.0 functions, attributes, and schema elements.

New domains created using 9.1 will default to using the XACML authorization and role mapping providers. Existing domains, upgraded to 9.1, will continue to use the authorization and role mapping providers currently specified, such as third-party partner providers or the original WebLogic Server proprietary providers. Customers who want to migrate existing domains from using WebLogic Server proprietary providers to the XACML providers can do so, including performing bulk moves of existing policy.

If you use the WebLogic Server Administration Console to add a new Authorization or Role Mapping provider, you can add the new provider as a DefaultAuthorizer or DefaultRoleMapper provider, or as a XACML provider.

Custom XACML providers are not supported in this release.

The XACML 2.0 specification is available at (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml).

SAML New Features

This section describes new and changed features for SAML in WebLogic Server 9.1.

Provider and Services Configuration

In WebLogic Server 9.0, all SAML configuration was done by means of configuration attributes on the SAML provider MBeans. In WebLogic Server 9.1, configuration of the SAML providers and services has been enhanced as follows:

New versions of the SAMLCredentialMapper and SAMLIdentityAsserter providers have been added. The SAML V1 providers are deprecated; you should use the V2 versions of the SAMLCredentialMapper and SAMLIdentityAsserter providers.

Although the version number of the providers has been incremented to V2, both providers are SAML 1.1 providers.
Configuration for SAML partners (asserting and relying parties) has been moved out of the providers and into a SAML Partner Registry in the embedded LDAP server.
Configuration for SAML services (SSO protocol responders) has been moved out of the providers and into a new Federation Services MBean as a child of the Server MBean.
Several new configuration options have been added, primarily related to configuration of keys, trusted certificates, and query parameters for use with the SSO profiles.

Enhanced Key Management

In WebLogic Server 9.0, SAML used the server's SSL server identity credentials (private key and certificate chain) for signing assertions and SAML protocol elements, and for connecting to external SAML services when SSL client credentials were required.

In WebLogic Server 9.1, SAML still relies on the server's keystore and requires that SSL be configured to use keystores, but it is now possible to configure separate aliases and passphrases for three distinct credentials: an assertion signing key, a protocol signing key, and an SSL client identity. Each of these credentials defaults to the server's SSL identity if not specified. These changes are implemented only in the new versions of the providers.

In addition, the SAML key management code has been enhanced to listen for changes to the relevant MBeans and respond to keystore/alias configuration changes dynamically.

Enhanced Trust Management

WebLogic Server 9.1 improves trust management by requiring that each partner configuration specify the aliases of the certificates trusted for particular purposes - assertion signing, SAML protocol element signing, and SSL client authentication.

As in WebLogic Server 9.0, certificates must be present in the SAML certificate registry to be trusted. However, registration is a necessary but insufficient condition for trust. Unlike WebLogic Server 9.0, which trusts any registered certificate for any purpose, WebLogic Server 9.1 trusts only the specific certificate configured, on a per-partner basis, for the particular purpose at hand.

WebLogic Server 9.1 removes the requirement that signatures include a <ds:keyinfo> element containing a certificate that can be used to verify the signature. Because the certificate trusted for a given signature is known through configuration, the SAML runtime does not need <ds:keyinfo> for signature verification.

Destination Site Verification

During execution of the Browser/Artifact profile, which specifies a method of conveying an SSO assertion to an ACS service by passing an identifying "artifact" as a query parameter, a destination site that has received a SAML artifact contacts the source site that issued the artifact to retrieve the corresponding assertion.

The SAML specification requires the source site to verify that the destination site requesting the assertion is the site to which the artifact was originally sent.

The WebLogic Server 9.0 Assertion Retrieval Service (ARS) can verify trust in destination sites when two-way SSL is used, but cannot verify that the destination site requesting an assertion is the one to which an artifact was sent.

In WebLogic Server 9.1, the ARS supports multiple authentication methods for destination sites (SSL client certificate, username/password), and verifies that the site requesting an assertion is the site to which the corresponding artifact was sent.

These changes require that a SAMLAssertionStoreV2 assertion store plugin be configured. The default assertion store plugin supports this feature.

Query Parameter/Form Variable Support

SAML partner configuration in WebLogic Server 9.1 includes the ability to specify parameters that are appended as query parameters when redirecting, or included as form variables when POSTing, during execution of the of SSO profiles. In addition, the implementation ensures that any query parameters/form variables received on a SAML service URL are propagated end-to-end during execution of the SSO profiles.

One important use of this feature is to include partner IDs as request parameters. (Many SAML implementations require that a partner ID be specified as a query parameter on an incoming SSO profile request.) WebLogic Server 9.1 also requires that partner IDs be present, and uses them to look up partner configuration information.

Conditional Deployment of SAML Applications

WebLogic Server provides several application WAR files that are deployed by default to provide application contexts for the SAML services. These WAR files contain no displayable files or executable code; they exist only to provide application contexts and deployment descriptors appropriate to the SAML services.

In WebLogic Server 9.0, these applications are always deployed on every server. In WebLogic Server 9.1, the applications are individually deployed only when actually needed; that is, when one or more SAML services are configured to run in that application context on the server where the application is deployed.