![]() |
![]() |
e-docs > WebLogic Server > Developing Security Providers for WebLogic Server > Writing Console Extensions for Custom Security Providers |
Developing Security Providers for WebLogic Server
|
Writing Console Extensions for Custom Security Providers
Console extensions allow you to provide functionality that is not included in the standard WebLogic Server Administration Console, or provide an alternate interface for existing functionality. You provide this functionality by adding nodes to the navigation tree, and/or by adding or replacing tabbed dialogs and dialog screens.
Note: Detailed information about how to write console extensions is provided in Extending the Administration Console, and should be reviewed before proceeding.
The following sections provide information about writing console extensions specifically for use with custom security providers:
When Should I Write a Console Extension?
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:
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.
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.
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.
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:
When In the Development Process Should I Write a Console Extension?
The various programmatic elements that comprise a console extension are packaged into a Web application and deployed in your WebLogic Server domain. The point in the development process when you develop the Web application is completely up to you.
However, before you or an administrator can use the console extension to configure and manage a custom security provider, the MBean type for the custom security provider must have been generated (as described in Generating an MBean Type to Configure and Manage the Custom Security Provider) and the console extension Web application properly packaged and deployed.
Note: For instructions about how to develop, package, and deploy a console extension as a Web application, see Main Steps for Writing an Administration Console Extension.
How Writing a Console Extension for a Custom Security Provider Differs From a Basic Console Extension
While basic console extensions (described in Extending the Administration Console) provide a great deal of flexibility and capability, the additional mechanisms that are available for writing security provider-specific console extensions enable:
Main Steps for Writing an Administration Console Extension
Although security provider-specific console extensions provide the additional features described in How Writing a Console Extension for a Custom Security Provider Differs From a Basic Console Extension, the main process for writing console extensions is the same:
Replacing Custom Security Provider-Related Administration Console Dialog Screens Using the SecurityExtension Interface
The SecurityExtension interface provides methods that allow you to replace various custom security provider-related Administration Console dialog screens. The Java class you create to define your console extension can implement the SecurityExtension interface in addition to (or in place of) extending the Extension class. (The Extension class is used for basic console extensions, and its use is described in "Implementing the NavTreeExtension Interface" in Extending the Administration Console.).
Note: You must implement all the methods in this interface. Simply return null for the pages you choose not to replace.
Table 12-1 shows the security provider-related dialog screens that you are most likely to replace, as well as the methods in the SecurityExtension interface that you need to implement to replace them.
Note: For more detailed information, see the WebLogic Server 7.0 API Reference Javadoc for the SecurityExtension interface and the Extension class.
How a Console Extension Affects the Administration Console
Whether you write a console extension that is meant is to replace the BEA-provided dialog screens for configuring a custom security provider, or the dialog screens for creating and editing users, groups, roles, or security policies that are associated with security providers, the WebLogic Server Administration Console will be affected in the same way.
As an example, the following process will occur when you or an administrator attempt to configure a custom security provider using the WebLogic Server Administration Console:
Figure 12-1 Configuring the Sample Authentication Provider
If you or an administrator are editing a custom security provider's configuration (rather than adding it as step 1 describes), the Administration Console attempts to locate a console extension when you click the hyperlinked name of the custom security provider (examples of which are shown in the bottom portion of Figure 12-1).
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |