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 under WebLogic Security Providers in Understanding Security for Oracle WebLogic Server and in later sections of this guide under the Do You Need to Create a Custom <Provider_Type> Provider? headings.

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, credential mapping, versionable application, or CertPath, as described in Types of Security Providers in Understanding Security for Oracle WebLogic Server. 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, 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.

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 Initialization of the Security Provider Database.

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

   See Security Providers and WebLogic Resources.

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.

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.

The configuration process consists of using the WebLogic Remote 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 WebLogic Remote Console also means that you are creating a specific instance of the MBean type.

See Administering Security for Oracle WebLogic Server.

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 Remote 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 WebLogic Remote 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)