Design Considerations

Careful planning of development activities can greatly reduce the time and effort you spend creating custom security providers. The following sections describe general security provider concepts and functionality to help you get started:

• Overview of the Development Process
• General Architecture of a Security Provider
• Security Services Provider Interfaces (SSPIs)
• Security Service Provider Interface (SSPI) MBeans
• Initializing the Security Provider Database

 

---

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

Designing the Custom Security Provider

The design process includes the following steps:

1. 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 in Introduction to WebLogic Security and in later sections of this guide under the "Do You Need to Create a Custom <Provider_Type> Provider?" headings. <Provider_Type> can be Authentication, Identity Assertion, Principal Validation, Authorization, Adjudication, Role Mapping, Auditing, or Credential Mapping.

2. Determine which type of custom security provider you want to create.

   The type may be Authentication, Identity Assertion, Principal Validation, Authorization, Adjudication, Role Mapping, Auditing, or Credential Mapping, as described in Types of Security Providers. Your custom security provider can augment or replace the WebLogic security providers that are already supplied with WebLogic Server.

3. 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.

4. Decide whether you will implement the SSPIs in one or two runtime classes.

   These options are discussed in Understand the SSPI Hierarchy and Determine Whether You Will Create One or Two Runtime Classes.

5. 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, roles, and 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.

6. 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 Initializing the Security Provider Database.

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:

1. 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.

2. 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.

3. 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.
4. 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).

   Procedures for this task are provided under the "Use the WebLogic MBeanMaker to Create the MBean JAR File (MJF)" heading in the sections that discuss each security provider in detail.

5. Install the MBean JAR File (MJF) into the WebLogic Server environment.

   Procedures for this task are provided under the "Install the MBean Type into the WebLogic Server Environment" heading in the sections that discuss each security provider in detail.

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.

In any of the preceding situations, if you do not want to write a console extension that allows you to use the WebLogic Server Administration Console, you can use the WebLogic Server Command-Line Interface to manage and configure your custom security providers instead. For more information about the WebLogic Server Command-Line Interface, see "WebLogic Server Command-Line Interface Reference" in the BEA WebLogic Server Administration Guide.

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 and Writing Console Extensions for Custom Security Providers.

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 (or the WebLogic Server Command-Line Interface) 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 "Customizing the Default Security Configuration" in Managing WebLogic Security. For instructions about how to use the WebLogic Server Command-Line Interface, see "WebLogic Server Command-Line Interface Reference" in the BEA WebLogic Server Administration Guide.

 

---

General Architecture of a Security Provider

Although there are different types of security providers you can create (see Types of Security Providers), all security providers follow the same general architecture. Figure 2-1 illustrates the general architecture of a security provider, and an explanation follows.

Figure 2-1 Security Provider Architecture

 

Note: The SSPIs and the runtime classes (that is, implementations) you will create using the SSPIs are shown on the left side of Figure 2-1 and are .java files.

Like the other files on the right side of Figure 2-1, MyFooMBean begins as a .xml file, in which you will extend (and optionally implement) SSPI MBeans. When this MBean Definition File (MDF) is run through the WebLogic MBeanMaker utility, the utility generates the .java files for the MBean type, as described in Generating an MBean Type to Configure and Manage the Custom Security Provider.

Figure 2-1 shows the relationship between a single runtime class (MyFooProviderImpl) and an MBean type (MyFooMBean) you create when developing a custom security provider. The process begins when a WebLogic Server instance starts, and the WebLogic Security Framework:

1. Locates the MBean type associated with the security provider in the security realm.
2. Obtains the name of the security provider's runtime class (the one that implements the "Provider" SSPI, if there are two runtime classes) from the MBean type.
3. Passes in the appropriate MBean instance, which the security provider uses to initialize (read configuration data).

Therefore, both the runtime class (or classes) and the MBean type form what is called the "security provider."

 

---

Security Services Provider Interfaces (SSPIs)

As described in Overview of the Development Process, you develop a custom security provider by first implementing a number of security services provider interfaces (SSPIs) to create runtime classes. This section helps you:

• Understand the Purpose of the "Provider" SSPIs
• Determine Which "Provider" Interface You Will Implement
• Understand the SSPI Hierarchy and Determine Whether You Will Create One or Two Runtime Classes

Additionally, this section provides an SSPI Quick Reference that indicates which SSPIs can be implemented for each type of security provider.

Understand the Purpose of the "Provider" SSPIs

Each SSPI that ends in the suffix "Provider" (for example, CredentialProvider) exposes the services of a security provider to the WebLogic Security Framework. This allows the security provider to be manipulated (initialized, started, stopped, and so on).

Figure 2-2 "Provider" SSPIs

 

As shown in Figure 2-2, the SSPIs exposing security services to the WebLogic Security Framework are provided by WebLogic Server, and all extend the SecurityProvider interface, which includes the following methods:

initialize

public void initialize(ProviderMBean providerMBean, SecurityServices securityServices)

The initialize method takes as an argument a ProviderMBean, which can be narrowed to the security provider's associated MBean instance. The MBean instance is created from the MBean type you generate, and contains configuration data that allows the custom security provider to be managed in the WebLogic Server environment. If this configuration data is available, the initialize method should be used to extract it.

The securityServices argument is an object from which the custom security provider can obtain and use the Auditor Service. For more information about the Auditor Service and auditing, see Auditing Providers.

getDescription

public String getDescription()

This method returns a brief textual description of the custom security provider.

shutdown

public void shutdown()

This method shuts down the custom security provider.

Because they extend SecurityProvider, a runtime class that implements any SSPI ending in "Provider" must provide implementations for these inherited methods.

Determine Which "Provider" Interface You Will Implement

Implementations of SSPIs that begin with the prefix "Deployable" and end with the suffix "Provider" (for example, DeployableCredentialProvider) expose the services of a custom security provider into the WebLogic Security Framework as explained in Understand the Purpose of the "Provider" SSPIs. However, implementations of these SSPIs also perform additional tasks.

Authorization providers, Role Mapping providers, and Credential Mapping providers have deployable versions of their "Provider" SSPIs.

Note: If your security provider database (which stores policies, roles, and credentials) is read-only, you can implement the non-deployable version of the SSPI for your Authorization, Role Mapping, and Credential Mapping security providers. However, you will still need to configure deployable versions of these security provider that do handle deployment.

The DeployableAuthorizationProvider SSPI

An Authorization provider that supports deploying policies on behalf of Web application or Enterprise JavaBean (EJB) deployments needs to implement the DeployableAuthorizationProvider SSPI instead of the AuthorizationProvider SSPI. (However, because the DeployableAuthorizationProvider SSPI extends the AuthorizationProvider SSPI, you actually will need to implement the methods from both SSPIs.) This is because Web application and EJB deployment activities require the Authorization provider to perform additional tasks, such as creating and removing policies. In a security realm, at least one Authorization provider must support the DeployableAuthorizationProvider SSPI, or else it will be impossible to deploy Web applications and EJBs.

Note: For more information about security policies, see "Understanding WebLogic Security Policies" in Managing WebLogic Security.

The DeployableRoleProvider SSPI

A Role Mapping provider that supports deploying roles on behalf of Web application or Enterprise JavaBean (EJB) deployments needs to implement the DeployableRoleProvider SSPI instead of the RoleProvider SSPI. (However, because the DeployableRoleProvider SSPI extends the RoleProvider SSPI, you will actually need to implement the methods from both SSPIs.) This is because Web application and EJB deployment activities require the Role Mapping provider to perform additional tasks, such as creating and removing roles. In a security realm, at least one Role Mapping provider must support this SSPI, or else it will be impossible to deploy Web applications and EJBs.

Note: For more information about roles, see Role Mapping Concepts.

The DeployableCredentialProvider SSPI

A Credential Mapping provider that supports deploying policies on behalf of Resource Adapter (RA) deployments needs to implement the DeployableCredentialProvider SSPI instead of the CredentialProvider SSPI. (However, because the DeployableCredentialProvider SSPI extends the CredentialProvider SSPI, you will actually need to implement the methods from both SSPIs.) This is because Resource Adapter deployment activities require the Credential Mapping provider to perform additional tasks, such as creating and removing credentials and mappings. In a security realm, at least one Credential Mapping provider must support this SSPI, or else it will be impossible to deploy Resource Adapters.

Note: For more information about credentials, see Credential Mapping Concepts.

Understand the SSPI Hierarchy and Determine Whether You Will Create One or Two Runtime Classes

Figure 2-3 uses a Credential Mapping provider to illustrate the inheritance hierarchy that is common to all SSPIs, and shows how a runtime class you supply can implement those interfaces. In this example, BEA supplies the SecurityProvider interface, and the CredentialProvider, DeployableCredentialProvider, and CredentialMapper SSPIs. Figure 2-3 shows a single runtime class called MyCredentialMapperProviderImpl that implements the DeployableCredentialProvider and CredentialMapper SSPIs.

Figure 2-3 Credential Mapping SSPIs and a Single Runtime Class

 

However, Figure 2-3 illustrates only one way you can implement SSPIs: by creating a single runtime class. If you prefer, you can have two runtime classes (as shown in Figure 2-4): one for the implementation of the SSPI ending in "Provider" (for example, CredentialProvider or DeployableCredentialProvider), and one for the implementation of the other SSPI (for example, the CredentialMapper SSPI).

When there are separate runtime classes, the class that implements the SSPI ending in "Provider" acts as a factory for generating the runtime class that implements the other SSPI. For example, in Figure 2-4, MyCredentialMapperProviderImpl acts as a factory for generating MyCredentialMapperImpl.

Figure 2-4 Credential Mapping SSPIs and Two Runtime Classes

 

Note: If you decide to have two runtime implementation classes, you need to remember to include both runtime implementation classes in the MBean JAR File (MJF) when you generate the security provider's MBean type. For more information, see Generating an MBean Type to Configure and Manage the Custom Security Provider.

SSPI Quick Reference

Table 2-1 maps the types of security providers (and their components) with the SSPIs and other interfaces you use to develop them.

Table 2-1 Security Providers, Their Components, and Corresponding SSPIs

Type/Component	SSPIs/Interfaces
Authentication provider	AuthenticationProvider
LoginModule (JAAS)	LoginModule
Identity Assertion provider	AuthenticationProvider
Identity Asserter	IdentityAsserter
Principal Validation provider	PrincipalValidator
Authorization	AuthorizationProvider DeployableAuthorizationProvider
Access Decision	AccessDecision
Adjudication provider	AdjudicationProvider
Adjudicator	Adjudicator
Role Mapping provider	RoleProvider DeployableRoleProvider
Role Mapper	RoleMapper
Auditing provider	AuditProvider
Audit Channel	AuditChannel
Credential Mapping provider	CredentialProvider DeployableCredentialProvider
Credential Mapper	CredentialMapper

 

Note: The SSPIs you use to create runtime classes for custom security providers are located in the weblogic.security.spi package. For more information about this package, see the WebLogic Server 7.0 API Reference Javadoc.

 

---

Security Service Provider Interface (SSPI) MBeans

As described in Overview of the Development Process, the second step in developing a custom security provider is generating an MBean type for the custom security provider. This section helps you:

• Understand Why You Need an MBean Type
• Determine Which SSPI MBeans to Extend and Implement
• Understand the Basic Elements of an MBean Definition File (MDF)
• Understand the SSPI MBean Hierarchy and How It Affects the Administration Console
• Understand What the WebLogic MBeanMaker Provides

Additionally, this section provides an SSPI MBean Quick Reference that indicates which required SSPI MBeans must be extended and which optional SSPI MBeans can be implemented for each type of security provider.

Understand Why You Need an MBean Type

In addition to creating runtime classes for a custom security provider, you must also generate an MBean type. The term MBean is short for managed bean, a Java object that represents a Java Management eXtensions (JMX) manageable resource.

Note: JMX is a specification created by Sun Microsystems that defines a standard management architecture, APIs, and management services. For more information, see the Java Management Extensions White Paper.

An MBean type is a factory for instances of MBeans, the latter of which you or an administrator can create using the WebLogic Server Administration Console. Once they are created, you can configure and manage the custom security provider using the MBean instance, through the Administration Console.

Note: All MBean instances are aware of their parent type, so if you modify the configuration of an MBean type, all instances that you or an administrator may have created using the Administration Console will also update their configurations. (For more information, see Understand the SSPI MBean Hierarchy and How It Affects the Administration Console.)

Determine Which SSPI MBeans to Extend and Implement

You use MBean interfaces called SSPI MBeans to create MBean types. There are two types of SSPI MBeans you can use to create anMBean type for a custom security provider:

• Required SSPI MBeans, which you must extend because they define the basic methods that allow a security provider to be configured and managed within the WebLogic Server environment.
• Optional SSPI MBeans, which you can implement because they define additional methods for managing security providers. Different types of security providers are able to use different optional SSPI MBeans.

For more information, see SSPI MBean Quick Reference.

Understand the Basic Elements of an MBean Definition File (MDF)

An MBean Definition File (MDF) is an XML file used by the WebLogic MBeanMaker utility to generate the Java files that comprise an MBean type. All MDFs must extend a required SSPI MBean that is specific to the type of the security provider you have created, and can implement optional SSPI MBeans.

Listing 2-1 shows a sample MBean Definition File (MDF), and an explanation of its content follows. (Specifically, it is the MDF used to generate an MBean type for the WebLogic Credential Mapping provider.)

Note: A complete reference of MDF element syntax is available in MBean Definition File (MDF) Element Syntax.

Listing 2-1 DefaultCredentialMapper.xml

<?xml version="1.0" ?>
<!DOCTYPE MBeanType SYSTEM "commo.dtd">

<MBeanType
 Name = "DefaultCredentialMapper"
 DisplayName = "DefaultCredentialMapper"
 Package = "weblogic.security.providers.credentials"
 Extends = "weblogic.management.security.credentials. DeployableCredentialMapper"
 Implements = "weblogic.management.security.credentials. UserPasswordCredentialMapEditor"
 PersistPolicy = "OnUpdate"
 Description = "This MBean represents configuration attributes for the WebLogic Credential Mapping provider.&lt;p&gt;"
>

<MBeanAttribute
 Name = "ProviderClassName"
 Type = "java.lang.String"
 Writeable = "false"
 Default = "&quot;weblogic.security.providers.credentials. DefaultCredentialMapperProviderImpl&quot;"
 Description = "The name of the Java class that loads the WebLogic Credential Mapping provider."
/>

<MBeanAttribute
 Name = "Description"
 Type = "java.lang.String"
 Writeable = "false"
 Default = "&quot;Provider that performs Default Credential Mapping&quot;"
 Description = "A short description of the WebLogic Credential Mapping provider."
/>

<MBeanAttribute
 Name = "Version"
 Type = "java.lang.String"
 Writeable = "false"
 Default = "&quot;1.0&quot;"
 Description = "The version of the WebLogic Credential Mapping provider."
/>

</MBeanType>

The bold attributes in the <MBeanType> tag show that this MDF is named DefaultCredentialMapper and that it extends the required SSPI MBean called DeployableCredentialMapper. It also includes additional management capabilities by implementing the UserPasswordCredentialMapEditor optional SSPI MBean.

The ProviderClassName, Description, and Version attributes defined in the <MBeanAttribute> tags are required in any MDF used to generate MBean types for security providers because they define the security provider's basic configuration methods, and are inherited from the base required SSPI MBean called Provider (see Figure 2-6). The ProviderClassName attribute is especially important. The value for the ProviderClassName attribute is the Java filename of the security provider's runtime class (that is, the implementation of the appropriate SSPI ending in "Provider"). The example runtime class shown in Listing 2-1 is DefaultCredentialMapperProviderImpl.java.

While not shown in Listing 2-1, you can include additional attributes and operations in an MDF using the <MBeanAttribute> and <MBeanOperation> tags. Most custom attributes will automatically appear in the Details tab for your custom security provider in the WebLogic Server Administration Console (an example of which is shown in Figure 2-5). To display custom operations, however, you need to write a console extension. (See Writing Console Extensions.)

Figure 2-5 Sample Details Tab

 

Understand the SSPI MBean Hierarchy and How It Affects the Administration Console

All attributes and operations that are specified in the required SSPI MBeans that your MBean Definition File (MDF) extends (all the way up to the Provider base SSPI MBean) automatically appear in a WebLogic Server Administration Console page for the associated security provider. You use these attributes and operatations to configure and manage your custom security providers.

Note: For Authentication security providers only, the attributes and operations that are specified in the optional SSPI MBeans your MDF implements are also automatically supported by the Administration Console. For other types of security providers, you must write a console extension in order to make the attributes and operations inherited from the optional SSPI MBeans available in the Administration Console. For more information, see Writing Console Extensions.

Figure 2-6 illustrates the SSPI MBean hierarchy for security providers (using the WebLogic Credential Mapping MDF as an example), and indicates what attributes and operations will appear in the Administration Console for the WebLogic Credential Mapping provider.

Figure 2-6 SSPI MBean Hierarchy for Credential Mapping Providers

 

Implementing the hierarchy of SSPI MBeans in the DefaultCredentialMapper MDF (shown in Figure 2-6) produces the page in the Administration Console that is shown in Figure 2-7. (The full listing of the DefaultCredentialMapper MDF is shown in Listing 2-1.)

Figure 2-7 DefaultCredentialMapper Administration Console Page

 

The Name, Description, and Version fields come from attributes with these names inherited from the base required SSPI MBean called Provider and specified in the DefaultCredentialMapper MDF. Note that the DisplayName attribute in the DefaultCredentialMapper MDF generates the value for the Name field, and that the Description and Version attributes generate the values for their respective fields as well. The Credential Mapping Deployment Enabled field is displayed because of the CredentialMappingDeploymentEnabled attribute in the DeployableCredentialMapper required SSPI MBean, which the DefaultCredentialMapper MDF extends. Notice that this Administration Console page does not display a field for the DefaultCredentialMapper MDF's implementation of the UserPasswordCredentialMapEditor optional SSPI MBean.

Understand What the WebLogic MBeanMaker Provides

The WebLogic MBeanMaker is a command-line utility that takes an MBean Definition File (MDF) as input and outputs files for an MBean type. When you run the MDF you created through the WebLogic MBeanMaker, the following occurs:

• Any attributes inherited from required SSPI MBeans—as well as any custom attributes you added to the MDF—cause the WebLogic MBeanMaker to generate complete getter/setter methods in the MBean type's information file. (The MBean information file is not shown in Figure 2-8.)

Necessary developer action: None. No further work must be done for these methods.

• Any operations inherited from optional SSPI MBeans cause the MBean implementation file to inherit their methods, whose implementations you must supply from scratch.

Necessary developer action: Currently, the WebLogic MBeanMaker does not generate method stubs for these inherited methods, so you will need to use the "Mapping MDF Operation Declarations to Java Method Signatures Document" (available on the dev2dev Web site) to supply the appropriate implementations.

• Any custom operations you added to the MDF will cause the WebLogic MBeanMaker to generate method stubs.

Necessary developer action: You must provide implementations for these methods. (However, because the WebLogic MBeanMaker generates the stubs, you do not need to look up the Java method signatures.)

This is illustrated in Figure 2-8.

Figure 2-8 What the WebLogic MBeanMaker Provides

 

SSPI MBean Quick Reference

Based on the list of SSPIs you need to implement as part of developing your custom security provider, locate the required SSPI MBeans you need to extend in Table 2-2. Using Table 2-3 through Table 2-5, locate any optional SSPI MBeans you also want to implement for managing your security provider.

Table 2-2 Required SSPI MBeans

Type	Package Name	Required SSPI MBean
Authentication provider	authentication	Authenticator
Identity Assertion provider	authentication	IdentityAsserter
Authorization provider	authorization	Authorizer or DeployableAuthorizer
Adjudication provider	authorization	Adjudicator
Role Mapping provider	authorization	RoleMapper or DeployableRoleMapper
Auditing provider	audit	Auditor
Credential Mapping provider	credentials	CredentialMapper or DeployableCredentialMapper

 

Note: The required SSPI MBeans shown in Table 2-2 are located in the weblogic.management.security.<Package_Name> package.

Table 2-3 Optional Authentication SSPI MBeans 

Optional SSPI MBeans	Purpose
GroupEditor	Create a group. If the group already exists, an exception is thrown.
GroupMemberLister	List a group's members.
GroupReader	Read data about groups.
GroupRemover	Remove groups.
MemberGroupLister	List the groups containing a user or a group.
UserEditor	Create, edit and remove users.
UserPasswordEditor	Change a user's password.
UserReader	Read data about users.
UserRemover	Remove users.

 

Notes: The optional Authentication SSPI MBeans shown in Table 2-3 are located in the weblogic.management.security.authentication package. They are also supported in the WebLogic Server Administration Console.

Table 2-4 Optional Authorization SSPI MBeans

Optional SSPI MBeans	Purpose
PolicyEditor	Create, edit and remove security policies.
PolicyReader	Read data about security policies.
RoleEditor	Create, edit and remove roles.
RoleReader	Read data about roles.

 

Note: The optional Authorization SSPI MBeans shown in Table 2-4 are located in the weblogic.management.security.authorization package.

Table 2-5 Optional Credential Mapping SSPI MBeans

Optional SSPI MBeans	Purpose
UserPasswordCredentialMapEditor	Edit credential maps that map a WebLogic user to a remote username and password.
UserPasswordCredentialMapReader	Read credential maps that map a WebLogic user to a remote username and password.

 

Note: The optional Credential Mapping SSPI MBeans shown in Table 2-5 are located in the weblogic.management.security.credentials package.

 

---

Initializing the Security Provider Database

The following sections explain what a security provider database is, describe how security realms affect the use of security provider databases, and address best practices for initializing a security provider database:

• What Is a Security Provider Database?
• Security Realms and Security Provider Databases
• Best Practice: Create a Simple Database If None Exists
• Best Practice: Configure an Existing Database
• Best Practice: Delegate Database Initialization

What Is a Security Provider Database?

A security provider database contains the users, groups, policies, roles, and credentials used by some types of security providers to provide security services. For example: an Authentication provider requires information about users and groups; an Authorization provider requires information about security policies; a Role Mapping provider requires information about roles, and a Credential Mapping provider requires information about credentials. These security providers need this information to be available in a database in order to function properly.

The security provider database can be the embedded LDAP server (as used by the WebLogic security providers), a properties file (as used by the sample security providers), or a production-quality database that you may already be using.

Note: The sample security providers are available under "Code Direct" on the dev2dev Web site.

The security provider database should be initialized the first time security providers are used. This initialization can be done:

• When the WebLogic Server instance boots.
• When a call is made to one of the security provider's MBeans.

At minimum, you must initialize a security provider database with the default users, groups, policies, roles, or credentials that your Authentication, Authorization, Role Mapping, and Credential Mapping providers expect. For more information, see the following sections in Managing WebLogic Security:

• Default Group Associations
• Default Security Policies
• Default Global Roles and Permissions
• Using WebLogic Server to Authenticate to Remote Systems

Security Realms and Security Provider Databases

If you have multiple security providers of the same type configured in the same security realm, these security providers may use the same security provider database. This behavior holds true for all of the WebLogic security providers and the sample security providers that are available under "Code Direct" on the dev2dev Web site.

For example, if you or an administrator configure two WebLogic Authentication providers in the default security realm (called myrealm), both WebLogic Authentication providers will use the same location in the embedded LDAP server as their security provider database, and thus, will use the same users and groups. Furthermore, if you or an administrator add a user or group to one of the WebLogic Authentication providers, you will see that user or group appear for the other WebLogic Authentication provider as well.

Note: If you have two WebLogic security providers (or two sample security providers) of the same type configured in two different security realms, each will use its own security provider database.

The custom security providers that you develop (or the custom security providers that you obtain from third-party security vendors) can be designed so that each instance of the security provider uses its own database or so that all instances of the security provider in a security realm share the same database. This is a design decision that you need to make based on your existing systems and security requirements.

Best Practice: Create a Simple Database If None Exists

The first time an Authentication, Authorization, Role Mapping, or Credential Mapping provider is used, it attempts to locate a database with the information it needs to provide its security service. If the security provider fails to locate the database, you can have it create one and automatically populate it with the default users, groups, policies, roles, and credentials. This option may be useful for development and testing purposes.

Both the WebLogic security providers and the sample security providers follow this practice. The WebLogic Authentication, Authorization, Role Mapping, and Credential Mapping providers store the user, group, policy, role, and credential information in the embedded LDAP server. If you want to use any of these WebLogic security providers, you will need to follow the "Configuring the Embedded LDAP Server" instructions in Managing WebLogic Security.

Note: The sample security providers simply create and use a properties file as their database. For example, the sample Authentication provider creates a file called SampleAuthenticatorDatabase.java that contains the necessary information about users and groups. The sample security providers are available under "Code Direct" on the dev2dev Web site.

Best Practice: Configure an Existing Database

If you already have a database (such as an external LDAP server), you can populate that database with the users, groups, policies, roles, and credentials that your Authentication, Authorization, Role Mapping, and Credential Mapping providers require. (Populating an existing database is accomplished using whatever tools you already have in place for performing these tasks.)

Once your database contains the necessary information, you must configure the security providers to look in that database. You accomplish this by adding custom attributes in your security provider's MBean Definition File (MDF). Some examples of custom attributes are the database's host, port, password, and so on. After you run the MDF through the WebLogic MBeanMaker and complete a few other steps to generate the MBean type for your custom security provider, you or an administrator use the WebLogic Server Administration Console to set these attributes to point to the database.

Note: For more information about MDFs, MBean types, and the WebLogic MBeanMaker, see Generating an MBean Type to Configure and Manage the Custom Security Provider.

As an example, Listing 2-2 shows some custom attributes that are part of the WebLogic LDAP Authentication provider's MDF. These attributes enable an administrator to specify information about the WebLogic LDAP Authentication provider's database (an external LDAP server), so it can locate information about users and groups.

Listing 2-2 LDAPAuthenticator.xml

...

<MBeanAttribute
 Name = "UserObjectClass"
 Type = "java.lang.String"
 Default = "&quot;person&quot;"
 Description = "The LDAP object class that stores users."
/>

<MBeanAttribute
 Name = "UserNameAttribute"
 Type = "java.lang.String"
 Default = "&quot;uid&quot;"
 Description = "The attribute of an LDAP user object that specifies the name of 
   the user."
/>

<MBeanAttribute
 Name = "UserDynamicGroupDNAttribute"
 Type = "java.lang.String"
 Description = "The attribute of an LDAP user object that specifies the
   distinguished names (DNs) of dynamic groups to which this user belongs.
   If such an attribute does not exist, WebLogic Server determines if a
   user is a member of a group by evaluating the URLs on the dynamic group.
   If a group contains other groups, WebLogic Server evaluates the URLs on
   any of the descendents of the group."
/>

<MBeanAttribute
 Name = "UserBaseDN"
 Type = "java.lang.String"
 Default = "&quot;ou=people, o=example.com&quot;"
 Description = "The base distinguished name (DN) of the tree in the LDAP directory
   that contains users."
/>

<MBeanAttribute
 Name = "UserSearchScope"
 Type = "java.lang.String"
 Default = "&quot;subtree&quot;"
 LegalValues = "subtree,onelevel"
 Description = "Specifies how deep in the LDAP directory tree to search for Users.
   Valid values are &lt;code&gt;subtree&lt;/code&gt;
   and &lt;code&gt;onelevel&lt;/code&gt;."
/>

...

Best Practice: Delegate Database Initialization

If possible, initialization calls between a security provider and the security provider's database should be done by an intermediary class, referred to as a database delegator. The database delegator should interact with the runtime class and the MBean type for the security provider, as shown in Figure 2-9.

Figure 2-9 Positioning of the Database Delegator Class

 

A database delegator is used by the WebLogic Authentication and Credential Mapping providers. The WebLogic Authentication provider, for example, calls into a database delegator to initialize the embedded LDAP server with default users and groups, which it requires to provide authentication services for the default security realm.

Use of a database delegator is suggested as a convenience to application developers and security vendors who are developing custom security providers, because it hides the security provider's database and centralizes calls into the database.