This chapter describes the background information you need to understand before adding application versioning capability to your custom security providers, and provides step-by-step instructions for adding application versioning capability to a custom security provider.
A versionable application is an application that has an application archive version specified in the manifest of the application archive (EAR file). Versionable applications can be deployed side-by-side and active simultaneously. Versionable applications allow multiple versions of an application, where security constraints can vary between the application versions.
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.
The following sections provide the background information you need to understand before adding application versioning capability to your custom security providers, and provide step-by-step instructions for adding application versioning capability to a custom security provider:
Redeployment of versionable applications is always done via side-by-side versions, unless the same archive version is specified in the subsequent redeployments. However, a versionable application has to be written in such a way that multiple versions of it can be run side-by-side without conflicts; that is, it does not make any assumption of the uniqueness of the application name, and so forth. For example, in the case where an applications may use the application name as a unique key for global data structures, such as database tables or LDAP stores, the applications would need to change to use the application identifier instead.
Production Redeployment is allowed only if the configured security providers support the application versioning security SSPI. All Authorization, Role Mapping, and Credential Mapping providers for the security realm must support application versioning for an application to be deployed using versions.
See "Developing Applications for Production Redeployment" in Developing Applications for Oracle WebLogic Server for detailed information on how an application assigns an application version.
For a security provider to support application versioning, it must implement the Versionable Application SSPI. The WebLogic Security Framework calls the Versionable Application provider SSPI when an application version is created and deleted so that the provider can take any required actions to create, copy or removed data associated with the application version. It is up to the provider to determine the appropriate action to take, if any.
In addition, the Versionable Application provider SSPI is also called when a non-versioned application is deleted so that the provider can perform cleanup actions.
The WebLogic Security Framework passes the Versionable Application provider the application identifier for the new version and the application identifier of the version used as the source of application data. When the source identifier is not supplied, the initial version of the application is being created.
The WebLogic Server out-of-the-box security providers for Authorization, Role Mapping and Credential Mapping support the application versioning SSPI. When a new version is created, all the customized roles, policies and credential maps are cloned with new resource identifiers representing the new application version. In addition, when an application version is deleted, resources associated with the deleted version are removed.
If you develop a custom security provider for Authorization, Role Mapping, or Credential Mapping and need to support versioned applications, you must implement the Versionable Application SSPI.
If you need to support the Versionable Application SSPI, you can develop a custom Versionable Application provider by following these steps:
Implement your custom Authorization, Role Mapping, or Credential Mapping providers. All Authorization, Role Mapping, or Credential Mapping providers for the security realm must support application versioning for an application to be deployed using versions.
Before you start creating runtime classes, you should first:
When you understand this information and have made your design decisions, create the runtime classes for your custom Versionable Application provider by following these steps:
Implement your custom Authorization, Role Mapping, or Credential Mapping providers.
To implement the VersionableApplication SSPI, provide implementations for the methods described in Understand the Purpose of the "Provider" SSPIs and the following methods:
createApplicationVersion
void createApplicationVersion(String appIdentifier, String sourceAppIdentifier)
Marks the creation of a new application version and is called (only on the Administration Server within a WebLogic Server domain) on one server within a WebLogic Server domain at the time the version is created. The WebLogic Security Framework passes the createApplicationVersion method the application identifier for the new version (appIdentifier) and the application identifier of the version used as the source of application data (sourceAppIdentifier). When the source identifier is not supplied, the initial version of the application is being created.
deleteApplication
void deleteApplication(String appName)
Marks the deletion of a non-versioned application and is called (only on the Administration Server within a WebLogic Server domain) at the time the application is deleted.
deleteApplicationVersion
void deleteApplicationVersion(String appIdentifier)
Marks the deletion of an application version and is only called (only on the Administration Server within a WebLogic Server domain) at the time the version is deleted.
Example 14-1 shows how the Versionable Application SSPI is implemented in the sample Authorization provider.
Example 14-1 SimpleSampleAuthorizationProviderImpl
public final class SimpleSampleAuthorizationProviderImpl
implements DeployableAuthorizationProviderV2, AccessDecision, VersionableApplicationProvider
:
:
public void createApplicationVersion(String appId, String sourceAppId)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.createApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);
System.out.println("\tsource app identifier\t= " + ((sourceAppId != null) ? sourceAppId : "None"));
// create new policies when existing application is specified
if (sourceAppId != null) {
database.clonePoliciesForApplication(sourceAppId,appId);
}
public void deleteApplicationVersion(String appId)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);
// clear out policies for the application
database.removePoliciesForApplication(appId);
}
public void deleteApplication(String appName)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplication");
System.out.println("\tapplication name\t= " + appName);
// clear out policies for the application
database.removePoliciesForApplication(appName);
}
When you generate the MBean type for your custom Authorization, Role Mapping, and Credential Mapping providers, you must also implement the MBean for your Versionable Application provider. The ApplicationVersionerMBean is a marker interface and has no methods.
Example 14-2 shows how the SimpleSampleAuthorizer MBean Definition File (MDF) implements the ApplicationVersionerMBean MBean.
Example 14-2 Implementing the ApplicationVersionerMBean
<MBeanType Name = "SimpleSampleAuthorizer" DisplayName = "SimpleSampleAuthorizer" Package = "examples.security.providers.authorization.simple" Extends = "weblogic.management.security.authorization.DeployableAuthorizer" Implements = "weblogic.management.security.ApplicationVersioner" PersistPolicy = "OnUpdate" >
Once your have run your MDF through the WebLogic MBeanMaker to generate your intermediate files, and you have edited the MBean implementation file to supply implementations for the appropriate methods within it, you need to package the MBean files and the runtime classes for the custom Authorization, Role Mapping, or Credential Mapping provider, including the Versionable Application provider, into an MBean JAR File (MJF).
For a custom Authorization provider, these steps are described in Use the WebLogic MBeanMaker to Create the MBean JAR File (MJF).
For a custom Role Mapping provider, these steps are described in Use the WebLogic MBeanMaker to Create the MBean JAR File (MJF).
For a custom Credential Mapping provider, these steps are described in Use the WebLogic MBeanMaker to Create the MBean JAR File (MJF).
Configuring a custom Versionable Application provider means that you are adding the custom Versionable Application provider to your security realm, where it can be accessed by applications requiring application version services.
Configuring custom security providers is an administrative task, but it is a task that may also be performed by developers of custom security providers.
The steps for configuring a custom Versionable Application provider using the WebLogic Server Administration Console are described under "Configuring WebLogic Security Providers" in Securing Oracle WebLogic Server.