Developing Security Providers for WebLogic Server

Introduction and Roadmap

The following sections describe the content and organization of this document:

Document Scope

This document provides security vendors and application developers with the information needed to develop new security providers for use with the BEA WebLogic Server.

Documentation Audience

This document is written for independent software vendors (ISVs) who want to write their own security providers for use with WebLogic Server. It is assumed that most ISVs reading this documentation are sophisticated application developers who have a solid understanding of security concepts, and that no basic security concepts require explanation. It is also assumed that security vendors and application developers are familiar with BEA WebLogic Server and with Java (including Java Management eXtensions (JMX)).

Guide to this Document

This document provides security vendors and application developers with the information needed to develop new security providers for use with the BEA WebLogic Server.

The document is organized as follows:

Introduction to Developing Security Providers for WebLogic Server,which prepares you to learn more about developing security providers for use with WebLogic Server. It specifies the audience and prerequisites for this guide, and provides an overview of the development process.
Design Considerations,which explains the general architecture of a security provider and provides background information you should understand about implementing SSPIs and generating MBean types. This section also includes information about using optional management utilities and discusses how security providers interact with WebLogic resources. Lastly, this section suggests ways in which your custom security providers might work with databases that contain information security providers require.
Authentication Providers,which explains the authentication process (for simple logins) and provides instructions about how to implement each type of security service provider interface (SSPI) associated with custom Authentication providers. This topic also includes a discussion about JAAS LoginModules.
Identity Assertion Providers,which explains the authentication process (for perimeter authentication using tokens) and provides instructions about how to implement each type of security service provider interface (SSPI) associated with custom Identity Assertion providers.
Principal Validation Providers,which explains how Principal Validation providers assist Authentication providers by signing and verifying the authenticity of principals stored in a subject, and provides instructions about how to develop custom Principal Validation providers.
Authorization Providers,which explains the authorization process and provides instructions about how to implement each type of security service provider interface (SSPI) associated with custom Authorization providers.
Adjudication Providers,which explains the adjudication process and provides instructions about how to implement each type of security service provider interface (SSPI) associated with custom Adjudication providers.
Role Mapping Providers,which explains the role mapping process and provides instructions about how to implement each type of security service provider interface (SSPI) associated with custom Role Mapping providers.
Auditing Providers,which explains the auditing process and provides instructions about how to implement each type of security service provider interface (SSPI) associated with custom Auditing providers. This topic also includes information about how to audit from other types of security providers.
Credential Mapping Providers,which explains the credential mapping process and provides instructions about how to implement each type of security service provider interface (SSPI) associated with custom Credential Mapping providers.
Auditing Events From Custom Security Providers,which explains how to add auditing capabilities to the custom security providers you develop.
Servlet Authentication Filters,which explains the Servlet authentication filter process and provides instructions about how to implement each type of security service provider interface (SSPI) associated with Servlet authentication filters.
Versionable Application Providers,which explains the concept of versionable applications and provides instructions about how to implement each type of security service provider interface (SSPI) associated with custom Versionable Application providers.
CertPath Providers,which explains the certificate lookup and validation process and provides instructions about how to implement each type of security service provider interface (SSPI) associated with custom CertPath provider.
MBean Definition File (MDF) Element Syntax,which describes all the elements and attributes that are available for use in a valid MDF. An MDF is an XML file used to generate the MBean types, which enable the management of your custom security providers.

Related Information

The BEA corporate Web site provides all documentation for WebLogic Server. Other WebLogic Server documents that may be of interest to security vendors and application developers working with security providers are:

Additional resources include:

JavaDocs for WebLogic Classes

New and Changed Features in this Release

The following features have been added to the WebLogic Security Service 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 WLS proprietary providers. Customers who wish to migrate existing domains from using WLS proprietary providers to the XACML providers will be able to 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.