3-4 Developing Security Providers for Oracle WebLogic Server
■
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.
3.2.3 Understand the Purpose of the Bulk Access Providers
This release of WebLogic Server includes bulk access versions of the following Authorization, Adjudication, and Role Mapping provider SSPI interfaces:
■
BulkAuthorizationProvider
■
BulkAccessDecision
■
BulkAdjudicationProvider
■
BulkAdjudicator
■
BulkRoleProvider
■
BulkRoleMapper The bulk access SSPI interfaces allow Authorization, Adjudication, and Role Mapping
providers to receive multiple decision requests in one call rather than through multiple calls, typically in a for loop. The intent of the bulk SSPI variants is to allow
provider implementations to take advantage of internal performance optimizations, such as detecting that many of the passed-in Resource objects are protected by the
same policy and will generate the same decision result.
See Section 7.5.4, Bulk Authorization Providers,
Section 8.3.2, Bulk Adjudication Providers,
and Section 9.5.4, Bulk Role Mapping Providers
for additional information.
3.2.4 Determine Which Provider Interface You Will Implement
Implementations of SSPIs that begin with the prefix Deployable and end with the suffix Provider for example, DeployableRoleProviderV2 expose the services of
a custom security provider into the WebLogic Security Framework as explained in Section 3.2.2, Understand the Purpose of the Provider SSPIs.
However, implementations of these SSPIs also perform additional tasks. These SSPIs also
provide support for security in deployment descriptors, including the servlet deployment descriptors web.xml, weblogic.xml, the EJB deployment descriptors
ejb-jar.xml, weblogic-ejb.jar.xml and the EAR deployment descriptors application.xml, weblogic-application.xml.
Authorization providers, Role Mapping providers, and Credential Mapping providers have deployable versions of their Provider SSPIs.
Note: If your security provider database which stores security
policies, security 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.
Design Considerations 3-5
3.2.4.1 The DeployableAuthorizationProviderV2 SSPI
An Authorization provider that supports deploying security policies on behalf of Web application or Enterprise JavaBean EJB deployments needs to implement the
DeployableAuthorizationProviderV2 SSPI instead of the AuthorizationProvider SSPI. However, because the
DeployableAuthorizationProviderV2 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 security policies. In a security realm, at least one Authorization provider must support the DeployableAuthorizationProviderV2 SSPI, or else it will be
impossible to deploy Web applications and EJBs.
3.2.4.2 The DeployableRoleProviderV2 SSPI
A Role Mapping provider that supports deploying security roles on behalf of Web application or Enterprise JavaBean EJB deployments needs to implement the
DeployableRoleProviderV2 SSPI instead of the RoleProvider SSPI. However, because the DeployableRoleProviderV2 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 security 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.
3.2.4.3 The DeployableCredentialProvider SSPI
A Credential Mapping provider that supports deploying security 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 security policies, see Security
Policies in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
Note: For more information about security roles, see Users, Groups,
and Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
Note: The DeployableCredentialProvider interface is deprecated in
this release of WebLogic Server.
3-6 Developing Security Providers for Oracle WebLogic Server
3.2.5 Understand the SSPI Hierarchy and Determine Whether You Will Create One or Two Runtime Classes
