Developing Security Providers for WebLogic Server
|
 |
 |
|
|
 |
 |
Introduction to Developing Security Providers for WebLogic Server
The following sections prepare you to learn more about developing security providers:
- Audience for This Guide
- Prerequisites for This Guide
- Overview of the Development Process
- New and Changed Features in This Release
Audience for This Guide
Developing Security Providers for WebLogic Server is designed 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)).
Prerequisites for This Guide
Prior to reading this guide, you should review the following sections in Understanding WebLogic Security:
Additionally, WebLogic Server security includes many unique terms and concepts that you need to understand. These terms and concepts—which you will encounter throughout the WebLogic Server security documentation—are defined in the Terminology and the Security Fundamentals sections of Understanding WebLogic Security, respectively.
Overview of the Development Process
This section is a high-level overview of the process for developing new security providers, so you know what to expect. Details for each step are discussed later in this guide.
The main steps for developing a custom security provider are:
- Designing the Custom Security Provider
- Creating Runtime Classes for the Custom Security Provider by Implementing SSPIs
- Generating an MBean Type to Configure and Manage the Custom Security Provider
- Writing Console Extensions
- Configuring the Custom Security Provider
- Providing Management Mechanisms for Security Policies, Security Roles, and Credential Maps
Designing the Custom Security Provider
The design process includes the following steps:
- Review the descriptions of the WebLogic security providers to determine whether you need to create a custom security provider.
Descriptions of the WebLogic security providers are available under The WebLogic Security Providers in Understanding WebLogic Security and in later sections of this guide under the "Do You Need to Create a Custom <Provider_Type> Provider?" headings.
The type may be Authentication, Identity Assertion, Principal Validation, Authorization, Adjudication, Role Mapping, Auditing, Credential Mapping, Versionable Application, or CertPath, as described in Types of Security Providers in Understanding WebLogic Security. Your custom security provider can augment or replace the WebLogic security providers that are already supplied with WebLogic Server.
- Identify which security service provider interfaces (SSPIs) you must implement to create the runtime classes for your custom security provider, based on the type of security provider you want to create.
The SSPIs for the different security provider types are described in Security Services Provider Interfaces (SSPIs) and summarized in SSPI Quick Reference.
These options are discussed in Understand the SSPI Hierarchy and Determine Whether You Will Create One or Two Runtime Classes.
- Identify which required SSPI MBeans you must extend to generate an MBean type through which your custom security provider can be managed. If you want to provide additional management functionality for your custom security provider (such as handling of users, groups, security roles, and security policies), you also need to identify which optional SSPI MBeans to implement.
The SSPI MBeans are described in Security Service Provider Interface (SSPI) MBeans and summarized in SSPI MBean Quick Reference.
- Determine how you will initialize the database that your custom security provider requires. You can have your custom security provider create a simple database, or configure your custom security provider to use an existing, fully-populated database.
These two database initialization options are explained in Initialization of the Security Provider Database.
- Identify any database "seeding" that your custom security provider will need to do as part of its interaction with security policies on WebLogic resources. This seeding may involve creating default groups, security roles, or security policies.
For more information, see Security Providers and WebLogic Resources.
Creating Runtime Classes for the Custom Security Provider by Implementing SSPIs
In one or two runtime classes, implement the SSPIs you have identified by providing implementations for each of their methods. The methods should contain the specific algorithms for the security services offered by the custom security provider. The content of these methods describe how the service should behave.
Procedures for this task are dependent on the type of security provider you want to create, and are provided under the "Create Runtime Classes Using the Appropriate SSPIs" heading in the sections that discuss each security provider in detail.
Generating an MBean Type to Configure and Manage the Custom Security Provider
Generating an MBean type includes the following steps:
- Create an MBean Definition File (MDF) for the custom security provider that extends the required SSPI MBean, implements any optional SSPI MBeans, and adds any custom attributes and operations that will be required to configure and manage the custom security provider.
Information about MDFs is available in Understand the Basic Elements of an MBean Definition File (MDF), and procedures for this task are provided under the "Create an MBean Definition File (MDF)" heading in the sections that discuss each security provider in detail.
- Run the MDF through the WebLogic MBeanMaker to generate intermediate files (including the MBean interface, MBean implementation, and MBean information files) for the custom security provider's MBean type.
Information about the WebLogic MBeanMaker and how it uses the MDF to generate Java files is provided in Understand What the WebLogic MBeanMaker Provides, and procedures for this task are provided under the "Use the WebLogic MBeanMaker to Generate the MBean Type" heading in the sections that discuss each security provider in detail.
- Edit the MBean implementation file to supply content for any methods inherited from implementing optional SSPI MBeans, as well as content for the method stubs generated as a result of custom attributes and operations added to the MDF.
- Run the modified intermediate files (for the MBean type) and the runtime classes for your custom security provider through the WebLogic MBeanMaker to generate a JAR file, called an MBean JAR File (MJF).
Writing Console Extensions
Console extensions allow you to add JavaServer Pages (JSPs) to the WebLogic Server Administration Console to support additional management and configuration of custom security providers. Console extensions allow you to include Administration Console support where that support does not yet exist, as well as to customize administrative interactions as you see fit.
To get complete configuration and management support through the WebLogic Server Administration Console for a custom security provider, you need to write a console extension when:
- You decide not to implement an optional SSPI MBean when you generate an MBean type for your custom security provider, but still want to configure and manage your custom security provider via the Administration Console. (That is, you do not want to use the WebLogic Server Command-Line Interface instead.)
Generating an MBean type (as described in Generating an MBean Type to Configure and Manage the Custom Security Provider) is the BEA-recommended way for configuring and managing custom security providers. However, you may want to configure and manage your custom security provider completely through a console extension that you write.
- You implement optional SSPI MBeans for custom security providers that are not custom Authentication providers.
When you implement optional SSPI MBeans to develop a custom Authentication provider, you automatically receive support in the Administration Console for the MBean type's attributes (inherited from the optional SSPI MBean). Other types of custom security providers, such as custom Authorization providers, do not receive this support.
- You add a custom attribute that cannot be represented as a simple data type to your MBean Definition File (MDF), which is used to generate the custom security provider's MBean type.
The Details tab for a custom security provider will automatically display custom attributes, but only if they are represented as a simple data type, such as a string, MBean, boolean or integer value. If you have custom attributes that are represented as atypical data types (for example, an image of a fingerprint), the Administration Console cannot visualize the custom attribute without customization.
- You add a custom operation to your MBean Definition File (MDF), which is used to generate the custom security provider's MBean type.
Because of the potential variety involved with custom operations, the Administration Console does not know how to automatically display or process them. Examples of custom operations might be a microphone for a voice print, or import/export buttons. The Administration Console cannot visualize and process these operations without customization.
Some other (optional) reasons for extending the Administration Console include:
- Corporate branding—when, for example, you want your organization's logo or look and feel on the pages used to configure and manage a custom security provider.
- Consolidation—when, for example, you want all the fields used to configure and manage a custom security provider on one page, rather than in separate tabs or locations.
For more information about console extensions, see Extending the Administration Console.
Configuring the Custom Security Provider
Note: The configuration process can be completed by the same person who developed the custom security provider, or by a designated administrator.
The configuration process consists of using the WebLogic Server Administration Console to supply the custom security provider with configuration information. If you generated an MBean type for managing the custom security provider, "configuring" the custom security provider in the Administration Console also means that you are creating a specific instance of the MBean type.
For more information about configuring security providers using the Administration Console, see Securing WebLogic Server.
Providing Management Mechanisms for Security Policies, Security Roles, and Credential Maps
Certain types of security providers need to provide administrators with a way to manage the security data associated with them. For example, an Authorization provider needs to supply administrators with a way to manage security policies. Similarly, a Role Mapping provider needs to supply administrators with a way to manage security roles, and a Credential Mapping provider needs to supply administrators with a way to manage credential maps.
For the WebLogic Authorization, Role Mapping, and Credential Mapping providers, there are already management mechanisms available for administrators in the WebLogic Server Administration Console. However, do you not inherit these mechanisms when you develop a custom version of one of these security providers; you need to provide your own mechanisms to manage security policies, security roles, and credential maps. These mechanisms must read and write the appropriate security data to and from the custom security provider's database, but may or may not be integrated with the Administration Console.
For more information, refer to one of the following sections:
- Provide a Mechanism for Security Policy Management (for custom Authorization providers)
- Provide a Mechanism for Security Role Management (for custom Role Mapping providers)
- Provide a Mechanism for Credential Map Management (for custom Credential Mapping providers)
New and Changed Features in This Release
The following features have been added to the WebLogic Security Service in this release.
Support for Certificate Lookup and Validation
The WebLogic Security service provides a framework that finds and validates X509 certificate chains for inbound 2-way SSL, outbound SSL, application code, and WebLogic Web services. The Certificate Lookup and Validation (CLV) framework is a new security plug-in framework that finds and validates certificate chains. The framework extends and completes the JDK CertPath functionality, and allows you to create a custom CertPath provider.
Servlet Authentication Filters
Servlet authentication filters are a new provider type that perform pre and post processing for identity assertion and authentication functions. Filters provide the ability to encapsulate recurring tasks in reusable units and can be used to transform the response from a servlet or JSP page.
Versionable Applications
The Versionable Application provider SSPI enables all security providers that support application versioning to be notified when versions are created and deleted. It also enables all security providers that support application versioning to be notified when non-versioned applications are removed
Challenge Identity Assertion
The Challenge Identity Asserter interface supports challenge response schemes in which multiple challenges, responses messages, and state are required. The Challenge Identity Asserter interface allows Identity Assertion providers to support authentication protocols such as Microsoft's Windows NT Challenge/Response (NTLM), Simple and Protected GSS-API Negotiation Mechanism (SPNEGO), and other challenge/response authentication mechanisms.
The weblogic.security.services.Authentication class has been extended to allow multiple challenge/response identity assertion from a servlet authentication filter. The new methods and interface provide a wrapper for the ChallengeIdentityAsserterV2 and ProviderChallengeContext interfaces so that you can invoke them from a servlet authentication filter.
Auditing enhancements
Auditors can now implement the AuditorMBean and the mixin interface ContextHandlerMBean. The ContextHandlerMBean provides a set of attributes for ContextHandler support. You use this interface to manage audit providers that support context handler entries in a standard way. An Auditor provider MBean can optionally implement the ContextHandlerMBean MBean. The Auditor provider can then use the MBean to determine the supported and active ContextHandler entries.
The ApplicationInfo Interface
The ApplicationInfo interface passes data about an application deployment to a security provider. You can use this data to uniquely identity the application. The Security Framework implements the ApplicationInfo interface for your convenience. You do not need to implement any methods for this interface. The DeployableAuthorizationProviderV2 and DeployableRoleProviderV2 interfaces use ApplicationInfo.
New V2 Providers
The following providers are new in this release of WebLogic Server:
AdjudicationProviderV2AdjudicatorV2AuditAtnEventV2AuthenticationProviderV2CertPathProviderChallengeIdentityAsserterV2CredentialMapperV2CredentialProviderV2DeployableAuthorizationProviderV2DeployableRoleProviderV2IdentityAsserterV2VersionableApplicationProvider
New Provider Interfaces
ApplicationInfoServletAuthenticationFilterCertPathBuilderParametersCertPathValidatorParametersChallengeIdentityAsserterV2AppChallengeContext
Additional Context Handler Support
A context handler contains additional context and container-specific information from the resource container, and provides that information to the security provider making the access or role mapping decision. Context handler support is now available for the following methods:
