Developing Security Providers

Developing Custom Security Providers

If the security providers that ship with the AquaLogic Enterprise Security product do not meet your needs, you can develop custom security providers by following the steps outlined in Overview of the Development Process on page 2-1.

This section covers the following topics:

Types of Custom Security Providers Supported

This section described the most common security provider types.

You can create and use any of the security provider types described in the WebLogic Server-specific version of Developing WebLogic Security Providers, but you must then manage these providers from the WebLogic Administration Console, as described in Security Provider Management Concepts.

The types of custom security providers you can develop include the following:

Authentication Provider

An Authentication provider is used to prove the identity of users or system processes. Authentication providers also remember, transport, and make that identity information available to various components of a system through subjects when needed. During the authentication process, a Principal Validation provider provides additional security protections for the principals (users and groups) contained within the subject by signing and verifying the authenticity of those principals.

Identity Assertion Provider

An Identity Assertion provider is a specific form of Authentication provider that allows users or system processes to assert their identity using tokens (in other words, perimeter authentication). You can use an Identity Assertion provider in place of an Authentication provider if you create a LoginModule for the Identity Assertion provider, or in addition to an Authentication provider if you want to use the Authentication provider LoginModule. Identity Assertion providers enable perimeter authentication and support single sign-on.

Principal Validation Provider

Authentication providers rely on Principal Validation providers to sign and verify the authenticity of principals (users and groups) contained within a subject. Such verification provides an additional level of trust and may reduce the likelihood of malicious principal tampering. The authenticity of the principal is verified when making authorization decisions.

Role Mapping Provider

Role mapping is the process whereby principals (users or groups) are dynamically mapped to security roles at runtime. A Role Mapping provider determines which security roles apply to the principals stored a subject when the subject is attempting to perform an operation on a resource. Because this operation usually involves gaining access to the resource, Role Mapping providers are typically used with Authorization providers.

Authorization Provider

Authorization is the process whereby the interactions between users and resources are controlled, based on user identity or other information. In other words, authorization answers the question, What can you access? An Authorization provider is used to limit the interactions between users and resources to ensure integrity, confidentiality, and availability.

Adjudication Provider

Adjudication involves resolving any authorization conflicts that may occur when more than one Authorization provider is configured, by weighing the result of each Access Decision. An Adjudication provider tallies the results that multiple Access Decisions return, and determines the final PERMIT or DENY decision. An Adjudication provider may also specify what should be done when an answer of ABSTAIN is returned from a single Authentication provider.

Auditing Provider

An Auditing Provider processes information about operating requests and the outcome of those requests are collected, stored, and distributed for the purposes of non-repudiation. An Auditing provider provides this electronic trail of computer activity.

Credential Mapping Provider

A Credential Mapping Provider uses a legacy system database to obtain an appropriate set of credentials to use to authenticate users to a target resource. A Credential Mapping provider employs credential mapping services and bring new types of credentials into the environment.

Writing an MBean Definition File

The MDF for the sample Authentication provider is called SampleAuthenticator.xml.

To create an MBean Definition File (MDF), follow these steps:

Copy the MDF for the sample Authentication provider to a text file.

Listing 5-1 SampleAuthenticator.xml MDF File

<?xml version="1.0" ?>

<!DOCTYPE MBeanType SYSTEM "commo.dtd">

<!-- MBean Definition File (MDF) for the Sample Authenticator.

     Copyright (c) 2003 by BEA Systems, Inc. All Rights Reserved.

-->

<!-- Declare your mbean.

     Since it is for an authenticator, it must extend the

     weblogic.management.security.authentication.Authenticator mbean.

     The Name and DisplayName cannot be the same.

     They specify the name to appear on the

     console for this provider.

     Because this is an xml document, you can't use double

     quotes directly. Instead you need to use &quot;

     Note that setting "Writeable" to "false" on an attribute

     makes the attribute read-only. The default is read-write.

-->

<MBeanType

 Name          = "SampleAuthenticator"

 DisplayName   = "SampleAuthenticator"

 Package       = "examples.security.providers.authentication"

 Extends       = "weblogic.management.security.authentication.Authenticator"

 <!-- You must set the value of the ProviderClassName attribute

      (inherited from the weblogic.management.security.Provider mbean)

      to the name of the java class you wrote that implements the

      weblogic.security.spi.AuthenticationProvider interface.

      You can think of the provider's mbean as the factory

      for your provider's runtime implementation.

-->

 <MBeanAttribute

  Name          = "ProviderClassName"

  Type          = "java.lang.String"

  Writeable     = "false"

  Default       = "&quot;examples.security.providers.authentication.SampleAuthenticationProviderImpl&quot;"

/>

 <!-- You must set the value of the Description attribute

      (inherited from the weblogic.management.security.Provider mbean)

      to a brief description of your provider.

      It is displayed in the console.

-->

 <MBeanAttribute

  Name          = "Description"

  Type          = "java.lang.String"

  Writeable     = "false"

  Default       = "&quot;ALES Sample Authentication Provider&quot;"

/>

 <!-- You must set the value of the Version attribute

      (inherited from the weblogic.management.security.Provider mbean)

      to your version of the provider. There is no required format.

-->

 <MBeanAttribute

  Name          = "Version"

  Type          = "java.lang.String"

  Writeable     = "false"

  Default       = "&quot;1.0&quot;"

/>

 <!-- Add any custom attributes for your provider here.

      The sample authenticator does not have any custom attributes.

-->

</MBeanType>

Modify the content of the <MBeanType> and <MBeanAttribute> elements in your MDF so that they are appropriate for the type of custom security provider you are developing.
Add any custom attributes. (that is, additional <MBeanAttribute> elements) to your MDF.
Save the file.

Note:

A complete reference of MDF element syntax is available in MBean Definition File Element Syntax on page A-1 .

Using the WebLogic MBeanMaker to Generate the MBean Type

After you create your MDF, you are ready to run it through the WebLogic MBeanMaker. The WebLogic MBeanMaker is a command-line utility that takes an MDF and outputs some intermediate Java files, including an MBean interface, an MBean implementation, and an associated MBean information file. Together, these intermediate files form the MBean type for your custom security provider.

To generate the MBean type, follow these steps:

Create a new DOS shell.
Set the AquaLogic Enterprise Security environment variable by calling ALES_HOME/bin/set-env.bat.
Type the following command:

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

where:

-DMDF is a flag that instructs the WebLogic MBeanMaker to translate the MDF into code.

xmlFile is the MDF (the XML MBean Description File).

filesdir is the location where the WebLogic MBeanMaker places the intermediate files for the MBean type.

Whenever xmlfile is provided, a new set of output files is generated. If files already exist in the location specified by filesdir, the existing files are overwritten.

Each time you use the -DcreateStubs=true flag, the MBeanMaker overwrites any existing MBean implementation file.

Note:

As of version 9.0 of WebLogic Server, you can also provide a directory that contains multiple MDF's by using the -DMDFDIR <MDF directory name> option. In prior versions of WebLogic Server, the WebLogic MBeanMaker processed only one MDF at a time. Therefore, you had to repeat this process if you had multiple MDFs (in other words, multiple providers).

Proceed to Creating an MBean JAR File on page 5-22.

About the Generated MBean Interface File

The MBean interface file is the client-side API to the MBean that your runtime class uses to obtain configuration data. The initialize method uses the MBean interface file. Because the WebLogic MBeanMaker generates MBean types from the MDF you created, the generated MBean interface file has the same name as the MDF, appended with MBean. For example, the result of running the SampleAuthenticator MDF through the WebLogic MBeanMaker yields an MBean interface file called SampleAuthenticatorMBean.java.

Creating Security Provider Runtime Classes

This section describes how to create runtime classes for each type of provider. For more information about the SSPI and the methods described, see the Javadocs for Security Service Provider Interfaces.

Creating Authentication Provider Runtime Classes

To create the runtime classes for your custom Authentication provider, perform the following tasks:

For an example of how to create a runtime class for a custom Authentication provider, see Example: Creating the Runtime Classes for the Sample Authentication Provider on page 7-1.

Implementing the AuthenticationProvider SSPI

To implement the AuthenticationProvider SSPI, provide implementations for the methods described in Table 4-1 and the weblogic.security.spi.AuthenticationProvider interface methods, described in Table 5-1.

Table 5-1 AuthenticationProvider Interface Methods
Method	Description
`getLoginModule Configuration()`	The `getLoginModuleConfiguration` method obtains information about the LoginModule associated with the Authentication provider, which is returned as an `AppConfigurationEntry`. The `AppConfigurationEntry` is a Java Authentication and Authorization Service (JAAS) class that contains the classname of the LoginModule; the LoginModule control flag (passed in through the MBean associated with the Authentication provider); and a configuration options map for the LoginModule (which allows other configuration information to be passed into the LoginModule). For more information about the `AppConfigurationEntry` class (located in the `javax.security.auth.login` package) and the control flag options for LoginModules, see the Java API Specification Javadoc AppConfigurationEntry class and the Configuration class. For more information about LoginModules, see Writing a JAAS LoginModule on page 3-5.
`getAssertionModule Configuration()`	The `getAssertionModuleConfiguration` method obtains information about the LoginModule associated with the Identity Assertion provider, which is returned as an `AppConfigurationEntry`. The `AppConfigurationEntry` is a JAAS class that contains the classname of the LoginModule; the LoginModule control flag (passed in through the MBean associated with the Authentication provider); and a configuration options map for the LoginModule (which allows other configuration information to be passed into the LoginModule). The implementation of the `getAssertionModuleConfiguration` method can be to return `null`, if you want the Identity Assertion provider to use the same LoginModule as the Authentication provider.
`getPrincipalValidator()`	The `getPrincipalValidator` method obtains a reference to the Principal Validation provider runtime class (that is, the Principal Validator SSPI implementation). In most cases, the Principal Validation provider supplied with the product can be used (see SampleAuthenticationProviderImpl.java on page 7-2 for an example of how to return the Principal Validation provider). For more information about Principal Validation providers, see Creating Identity Assertion Runtime Classes on page 5-12 .
`getIdentityAsserter()`	The `getIdentityAsserter` method obtains a reference to the Identity Assertion provider runtime class (that is, the Identity Asserter SSPI implementation). In most cases, the return value for this method is `null` (see Listing 7-1 for an example). For more information about Identity Assertion providers, see Creating Identity Assertion Runtime Classes on page 5-12.

Implementing the JAAS LoginModule Interface

To implement the JAAS javax.security.auth.spi.LoginModule interface, provide implementations for the method described in Table 5-2.

Table 5-2 LoginInterface Methods
Method	Description
`initialize()`	The `initialize` method initializes the LoginModule. It takes as arguments a subject in which to store the resulting principals, a CallbackHandler that the Authentication provider uses to call back to the container for authentication information, a map of any shared state information, and a map of configuration options (that is, any additional information you want to pass to the LoginModule). A CallbackHandler is a highly-flexible JAAS standard that allows a variable number of arguments to be passed as complex objects to a method. For more information about CallbackHandlers, see the Java 2 Enterprise Edition, v1.4.2 API Specification Javadoc for the CallbackHandler interface.
`login()`	The `login` method attempts to authenticate the user and create principals for the user by calling back to the container for authentication information. If multiple LoginModules are configured (as part of multiple Authentication providers), this method is called for each LoginModule in the order that they are configured. Information about whether the login was successful (that is, whether principals were created) is stored for each LoginModule.
`commit()`	The `commit` method attempts to add the principals created in the `login` method to the subject. This method is also called for each configured LoginModule (as part of the configured Authentication providers), and executed in order. Information about whether the commit was successful is stored for each LoginModule.
`abort()`	The `abort` method is called for each configured LoginModule (as part of the configured Authentication providers), if any commits for the LoginModules failed; in other words, the relevant `REQUIRED`, `REQUISITE`, `SUFFICIENT` and `OPTIONAL` LoginModules did not succeed. The `abort` method removes those principals from the subject, effectively rolling back the actions performed.
`logout()`	The `logout` method attempts to log the user out of the system. It also resets the subject so that its associated principals are no longer stored.

For more information about the JAAS LoginModule interface and the methods described above, see the Java Authentication and Authorization Service (JAAS) 1.0 Developer's Guide, and the Java 2 Enterprise Edition, v1.4.2 API Specification Javadoc for the LoginModule interface.

Implementing Custom Exceptions for LoginModules

Optionally, you may want LoginModule that you write to throw a custom exception. The custom exception can be caught by your application and the appropriate action taken. For example, if the LoginModule throws a PasswordChangeRequiredException, you can catch that exception within your application, and use it to forward users to a page that allows them to change their password.

You must make your custom exception available to both the Authentication provider (at build, compile, and runtime) and to your application at compile time. You can do this using either of the following two methods.

Method 1: Make Custom Exceptions Available through the System Classpath

Write an exception class that extends LoginException.
Use the custom exception class in your classes that implement the LoginModule and Authentication Provider interfaces.
Put the custom exception class in the system classpath and the compiler path when compiling the security provider runtime class.
See Using the WebLogic MBeanMaker to Generate the MBean Type on page 5-6 for additional instructions.

Method 2: Make Custom Exceptions Available through the System Classpath and the Authentication Provider

Write an exception class that extends LoginException.
Use the custom exception class in your classes that implement the LoginModule and Authentication Provider interfaces.
Put the custom exception class in the compiler path when compiling the security provider runtime class.
See Using the WebLogic MBeanMaker to Generate the MBean Type on page 5-6 for additional instructions.
Add the custom exception class to the MJF (MBean JAR File) generated by the WebLogic MBeanMaker.
Include the MJF in the compiler and system classpath when compiling and running your application.

Creating Identity Assertion Runtime Classes

After creating any custom exceptions, you must create the runtime classes for your custom Identity Assertion provider. If you want to create a separate LoginModule for your custom Identity Assertion provider (that is, not use the LoginModule from your Authentication provider), you need to implement the JAAS LoginModule interface, as described in Implementing the JAAS LoginModule Interface on page 5-9.

For an example of how to create a runtime classes for a custom Identity Assertion provider, see Example: Creating the Runtime Class for the Sample Identity Assertion Provider on page 7-9.

Implementing the AuthenticationProvider SSPI

To implement the AuthenticationProvider SSPI, provide implementations for the Security Provider interface methods described in Table 4-1 and the weblogic.security.spi.AuthenticationProvider interface methods described in Table 5-1.

Note: When the LoginModule used for the Identity Assertion provider is the same as that used for an existing Authentication provider, implementations for the methods in the Authentication Provider SSPI (excluding the getIdentityAsserter method) for Identity Assertion providers can just return null. An example of this is shown in Listing 7-3.

Implementing the IdentityAsserter SSPI

To implement the IdentityAsserter SSPI, provide an implementation of the weblogic.security.spi.IdentityAsserter.assertIdentity() method, described in Table 5-3.

Note: The ActiveTypes MBeanAttribute contains the subset of your MBean's SupportedTypes that are active in the security realm. If you define the ActiveTypes MBeanAttribute, you must also define SupportedTypes.

Table 5-3 IdentityAsserter SSPI Method
Method	Description
`assertIdentity()`	The `assertIdentity` method asserts an identity based on the token identity information that is supplied. In other words, the purpose of this method is to validate any tokens that are not currently trusted against trusted client principals. The `type` parameter represents the token type to be used for the identity assertion. Note that identity assertion types are case insensitive. The `token` parameter contains the actual identity information. The `CallbackHandler` returned from the `assertIdentity` method is passed to all configured Authentication provider LoginModules to perform principal mapping, and should contain the asserted username. If the `CallbackHandler` is `null`, this signifies that the anonymous user should be used. A CallbackHandler is a highly-flexible JAAS standard that allows a variable number of arguments to be passed as complex objects to a method. For more information about CallbackHandlers, see the Java 2 Enterprise Edition, v1.4.2 API Specification Javadoc for the CallbackHandler interface.

Creating Principal Validation Provider Runtime Classes

To develop a custom Principal Validation provider:

Write your own UserImpl and GroupImpl classes by:

Implementing the weblogic.security.spi.WLSUser and weblogic.security.spi.WLSGroup interfaces.
Implementing the java.io.Serializable interfaces.

Write your own PrincipalValidationImpl class by implementing the weblogic.security.spi.PrincipalValidator SSPI. For instructions, see Implementing the PrincipalValidator SSPI.

Implementing the PrincipalValidator SSPI

To implement the PrincipalValidator SSPI, provide implementations of the Principal Validator methods described in Table 5-4.

Table 5-4 PrincipalValidator SSPI Methods
Method	Description
`validate`	The `validate` method takes a principal as an argument and attempts to validate it. In other words, this method verifies that the principal was not altered since it was signed.
`sign`	The `sign` method takes a principal as an argument and signs it to assure trust. This allows the principal to later be verified using the `validate` method. Your implementation of the `sign` method should be a secret algorithm that malicious individuals cannot easily recreate. You can include that algorithm within the `sign` method itself, have the `sign` method call out to a server for a token it should use to sign the principal, or implement some other way of signing the principal.
`getPrincipalBaseClass`	The `getPrincipalBaseClass` method returns the base class of principals that this Principal Validation provider knows how to validate and sign.

Creating Role Mapping Provider Runtime Classes

To create the runtime classes for your custom Role Mapping provider, perform the following tasks:

For an example of how to create a runtime class for a custom Role Mapping provider, see Example: Creating the Runtime Class for the Sample Role Mapping Provider on page 7-15.

Implement the RoleProvider SSPI

To implement the RoleProvider SSPI, provide implementations for the methods described in Table 4-1 and the weblogic.security.spi.RoleProvider.getRoleMapper method described in Table 5-5.

Table 5-5 RoleProvider SSPI Method
Method	Description
`getRoleMapper`	The `getRoleMapper` method obtains the implementation of the Role Mapper SSPI. For a single runtime class called `MyRoleProviderImpl`.`java`, the implementation of the `getRoleMapper` method is: `return this;` If there are two runtime classes, then the implementation of the `getRoleMapper` method is: `return new MyRoleMapperImpl();` This is because the runtime class that implements the Role Provider SSPI is used as a factory to obtain classes that implement the Role Mapper SSPI.

Implement the RoleMapper SSPI

To implement the RoleMapper SSPI, provide implementations for the weblogic.security.spi.RoleMapper.getRoles method described in Table 5-6.

Table 5-6 RoleMapper SSPI Method
Method	Description
`getRoles`	The `getRoles` method returns the security roles associated with a given subject for a specified resource, possibly using the optional information specified in the `ContextHandler`. For more information about Context Handlers, see ContextHandler Object on page 6-8.

Implement the SecurityRole Interface

The methods on the SecurityRole interface allow you to obtain basic information about a security role or to compare it to another security role. These methods are designed for the convenience of security providers.

Note: Security Role implementations are returned as a Map by the getRoles() method, keyed by role name.

To implement the Security Role interface, provide implementations for the weblogic.security.service.SecurityRole interface methods described in Table 5-7.

Table 5-7 SecurityRole Interface Methods
Method	Description
`equals`	The `equals` method returns `TRUE` if the security role passed in matches the security role represented by the implementation of this interface; otherwise it returns `FALSE`.
`toString`	The `toString` method returns the security role, represented as a String.
`hashCode`	The `hashCode` method returns a hashcode for the security role, represented as an integer.
`getName`	The `getName` method returns the name of the security role, represented as a String.
`getDescription`	The `getDescription` method returns a description of the security role, represented as a String. The description should describe the purpose of this security role.

Creating AuthorizationProvider Runtime Classes

To create the runtime classes for your custom Authorization provider, perform the following tasks:

For an example of how to create a runtime class for a custom Authorization provider, see Example: Creating the Runtime Class for the Sample Authorization Provider on page 7-12.

Implement the AuthorizationProvider SSPI

To implement the AuthorizationProvider SSPI, provide implementations for the methods described in Table 4-1 and the method described in Table 5-8.

Table 5-8 AuthorizationProvider SSPI Method
Method	Description
`getAccessDecision`	The `getAccessDecision` method obtains the implementation of the Access Decision SSPI. For a single runtime class called `MyAuthorizationProviderImpl`.`java`, the implementation of the `getAccessDecision` method is: `return this;` If there are two runtime classes, then the implementation of the `getAccessDecision` method is `return new MyAccessDecisionImpl();` This is because the runtime class that implements the Authorization Provider SSPI is used as a factory to obtain classes that implement the Access Decision SSPI.

Implement the AccessDecision SSPI

When you implement the AccessDecision SSPI, you must provide implementations for the methods described in Table 5-9.

Table 5-9 AccessDecision SSPI Methods
Method	Description
`isAccessAllowed`	The `isAccessAllowed` method uses information contained within the subject to determine if the requestor is allowed to access a protected resource. The `isAccessAllowed` method can be called prior to or after a request, and returns values of `PERMIT`, `DENY`, or `ABSTAIN`. If multiple Access Decisions are configured and return conflicting values, an Adjudication provider is needed to determine a final result. For more information, see Creating AdjudicationProvider Runtime Classes on page 5-18.
`isProtectedResource`	The `isProtectedResource` method determines if the specified resource is protected, without incurring the cost of an actual access check. It is only a lightweight mechanism because it does not compute a set of security roles that can be granted to the subject.

Creating AdjudicationProvider Runtime Classes

To create the runtime classes for your custom Adjudication provider, perform the following tasks:

Implement the AdjudicationProvider SSPI

To implement the AdjudicationProvider SSPI, provide implementations for the methods described in Table 4-1 and the weblogic.security.spi.AdjudicationProvider.getAdjudicator method described in Table 5-10.

Table 5-10 AdjudicationProvider SSPI Method
Method	Description
`getAdjudicator`	The `getAdjudicator` method obtains the implementation of the Adjudicator SSPI. For a single runtime class called `MyAdjudicationProviderImpl`.`java`, the implementation of the `getAdjudicator` method is: `return this;` If there are two runtime classes, then the implementation of the `getAdjudicator` method is: `return new MyAdjudicatorImpl();` This is because the runtime class that implements the Adjudication Provider SSPI is used as a factory to obtain classes that implement the `Adjudicator` SSPI.

Implement the Adjudicator SSPI

To implement the Adjudicator SSPI, provide implementations for the methods described in Table 5-11.

Table 5-11 Adjudicator SSPI Method
Method	Description
`initialize`	The `initialize` method initializes the names of all the configured Authorization provider Access Decisions called to supply a result for the "Is access allowed?" The `accessDecisionClassNames` parameter can be used by an Adjudication provider in its `adjudicate` method to favor a result from a particular Access Decision.
`adjudicate`	The `adjudicate` method determines the answer to the "Is access allowed?" given all the results from the configured Authorization provider Access Decisions.

Creating Auditing Provider Runtime Classes

To create the runtime classes for your custom Auditing provider, perform the following tasks:

For an example of how to create a runtime class for a custom Auditing provider, see Example: Creating the Runtime Class for the Sample Auditing Provider.

Implement the AuditProvider SSPI

To implement the AuditProvider SSPI, provide implementations for the methods described in Table 4-1 and the weblogic.security.spi.AuditProvider.getAuditChannel method described in Table 5-12.

Table 5-12 AuditProvider SSPI Method
Method	Description
`getAuditChannel`	The `getAuditChannel` method obtains the implementation of the Audit Channel SSPI. For a single runtime class called `MyAuditProviderImpl`.`java`, the implementation of the `getAuditChannel` method is: `return this;` If there are two runtime classes, then the implementation of the `getAuditChannel` method is `return new MyAuditChannelImpl();` This is because the runtime class that implements the Audit Provider SSPI is used as a factory to obtain classes that implement the Audit Channel SSPI.

Implement the AuditChannel SSPI

To implement the AuditChannel SSPI, provide an implementation for the weblogic.security.spi.AuditChannel.writeEvent method described in Table 5-13.

Table 5-13 AuditChannel SSPI Method
Method	Description
`writeEvent`	The `writeEvent` method writes an audit record based on the information specified in the `AuditEvent` object that is passed in. For more information about `AuditEvent` objects, see Creating an Audit Event on page 6-3.

Creating Credential Mapping Provider Runtime Classes

To create the runtime classes for your custom Credential Mapping provider, perform the following tasks:

Implement the CredentialProvider SSPI

To implement the CredentialProvider SSPI, provide implementations for the methods described in Table 4-1 and the weblogic.security.spi.CredentialProvider.getCredentialProvider method described in Table 5-14.

Table 5-14 CredentialProvider SSPI Method
Method	Description
`getCredentialProvider`	The `getCredentialProvider` method obtains the implementation of the Credential Mapper SSPI. For a single runtime class called `MyCredentialMapperProviderImpl`.`java` (as in Figure 4-3), the implementation of the `getCredentialProvider` method is: `return this;` If there are two runtime classes, then the implementation of the `getCredentialProvider` method is: `return new MyCredentialMapperImpl();` This is because the runtime class that implements the Credential Provider SSPI is used as a factory to obtain classes that implement the Credential Mapper SSPI.

Implement the Credential Mapper SSPI

To implement the Credential Mapper SSPI, you must provide implementations for the weblogic.security.spi.CredentialMapper methods described in Table 5-15.

Table 5-15 Credential Mapper SSPI Methods
Method	Description
`getCredentials()`	Format: `public java.util.Vector getCredentials(Subject requestor, Subject initiator, Resource resource, String[] credentialTypes);` The `getCredentials` method obtains the appropriate set of credentials for the target resource, based on the identity of the initiator. This version of the method returns a list of matching credentials for all of the principals within the subject (as a vector) by consulting the database for the remote system.
`getCredentials()`	Format: `public java.lang.Object getCredentials(Subject requestor, String initiator, Resource resource, String[] credentialTypes);` The `getCredentials` method obtains the appropriate set of credentials for the target resource, based on the identity of the initiator. This version of the method returns one credential for the specified subject (as an object) by consulting the database for the remote system.

Creating an MBean JAR File

After you run your MDF through the WebLogic MBeanMaker to generate your custom MBean files, you need to package the MBean files and the runtime classes for the custom security provider into an MBean JAR file. The WebLogic MBeanMaker automates this process.

To create an MJF for your custom security provider, follow these steps:

Create a new DOS shell.
Set the AquaLogic Enterprise Security environment variable by calling ALES_HOME/bin/set-env.bat.
Type the following command:

java -DMJF=jarfile -DFiles=filesdir weblogic.management.commo.WebLogicMBeanMaker

where:

-DMJF is a flag instructing the WebLogic MBeanMaker to build an MBean JAR file containing the new provider.

jarfile is the name for the MBean JAR file.

filesdir is the location where the WebLogic MBeanMaker looks for the files to JAR into the MBean JAR file.

Compilation occurs at this point, so errors are possible. If jarfile is provided and no errors occur, an MBean JAR file is created with the specified name.

Notes: If you want to update an existing MBean JAR file, simply delete the MBean JAR file and regenerate it. The WebLogic MBeanMaker also has a -DIncludeSource option that controls whether to include source files in the resulting MBean JAR file. Source files include both the generated source and the MBean definition file itself. The default is false. This option is ignored when -DMJF is not used.

The resulting MBean JAR file can be deployed into your AquaLogic Enterprise Security environment or distributed for installation into other AquaLogic Enterprise Security environments.

Deploying a Security Provider MJF File

As described in Security Provider Management Concepts, before you create a custom security provider, you need to understand how that provider will be managed by BEA AquaLogic Enterprise Security.

If you used the version 8.1 WebLogic MBeanMaker to create the custom security provider, copy the MJF file into the following directory:

PRODUCT_HOME\lib\providers

where:

PRODUCT_HOME is the top-level installation directory for BEA AquaLogic Enterprise Security product.

Note:

You must copy the file to both the machine on which the Security Service Module is installed and to the Administration Server. You must copy the file to any and all instances of Security Service Modules that use the new provider.

This deploys your custom security provider—that is, you can configure the custom security provider from the Administration Application and us it with your Security Service Module instance.

If you used the version 8.1 WebLogic MBeanMaker to create the custom security provider, copy the MJF into the WL_HOME\server\lib\mbeantypes directory, where WL_HOME is the top-level installation directory for WebLogic Server. This makes the custom provider manageable from the WebLogic Server Administration Console and WLST.

WL_HOME\server\lib\mbeantypes is the default directory for installing MBean types. Beginning with 9.0, security providers can be loaded from ...\domaindir\lib\mbeantypes as well. If you want WebLogic Server to look for MBean types in additional directories, use the -Dweblogic.alternateTypesDirectory=<dir> command-line flag when starting your server, where <dir> is a comma-separated list of directory names.