12-12 Developing Security Providers for Oracle WebLogic Server
try { we dont support descriptions so just ignore it
database.checkDoesntExistuser; database.getUseruser.createpassword;
database.updatePersistentState; auditOperationSucceededdetails;
} catch AlreadyExistsException e { auditOperationFaileddetails, e; throw e; }
catch IllegalArgumentException e { auditOperationFaileddetails, e; throw e; } }
... private void auditOperationSucceededString details
{ if auditor = null {
auditor.providerAuditWriteEvent new ManageableSampleAuthenticatorManagementEventrealm, provider, details, null
; }
} ...
private void auditOperationFailedString details, Exception failureException {
if auditor = null {
auditor.providerAuditWriteEvent new ManageableSampleAuthenticatorManagementEventrealm, provider, details, failureException
; }
} }
12.2.3 Best Practice: Posting Audit Events from a Providers MBean
Providers management operations that do writes for example, create user, delete user, remove data should post audit events, regardless of whether or not the operation
succeeds.
If your provider audits MBean operations, you should keep the following Best Practice guidelines in mind.
■
If the write operation succeeds, post an INFORMATION audit event.
■
If the write operation fails because of a bad parameter for example, because the user already exists, or due to a bad import format name, a non-existent file name,
or the wrong file format, do not post an audit event.
■
If the write operation fails because of an error for example, LDAPException, RuntimeException, post a FAILURE audit event.
■
Import operations can partially succeed. For example, some of the users are imported, but others are skipped because there are already users with that name in
the provider.
■
If you can easily detect that the data you are skipping is identical to the data already in the provider for example, the username, description, and password are
the same then consider posting a WARNING event.
■
If you are skipping data because there is a partial collision for example, the username is the same but the password is different, you should post a FAILURE
event.
Auditing Events From Custom Security Providers 12-13
■
If it is too difficult to distinguish the import data from the data already stored in the provider, post a FAILURE event.
12-14 Developing Security Providers for Oracle WebLogic Server
13
Servlet Authentication Filters 13-1
13
Servlet Authentication Filters
A Servlet Authentication Filter is a provider type that performs pre- and post-processing for authentication functions, including identity assertion. A Servlet
Authentication Filter is a special type of security provider that primarily acts as a helper to an Authentication provider.
The ServletAuthenticationFilter interface defines the security service provider interface SSPI for authentication filters that can be plugged in to WebLogic
Server. You implement the ServletAuthenticationFilter interface as part of an Authentication provider, and typically as part of the Identity Assertion form of
Authentication provider, to signal that the Authentication provider has authentication filters that it wants the servlet container to invoke during the authentication process.
The following sections describe Servlet Authentication Filter interface concepts and functionality, and provide step-by-step instructions for developing a Servlet
Authentication Filter:
■
Section 13.1, Authentication Filter Concepts
■
Section 13.2, How Filters Are Invoked
■
Section 13.3, Example of a Provider that Implements a Filter
■
Section 13.4, How to Develop a Custom Servlet Authentication Filter
13.1 Authentication Filter Concepts
Filters, as defined by the Java Servlet API 2.3 specification, are preprocessors of the request before it reaches the servlet, andor postprocessors of the response leaving the
servlet. Filters provide the ability to encapsulate recurring tasks in reusable units and can be used to transform the response from a servlet or JSP page.
Servlet Authentication filters are an extension to of the filter object that allows filters to replace or extend container-based authentication.
13.1.1 Why Filters are Needed
The WebLogic Security Framework allows you to provide a custom Authentication provider. However, due to the nature of the Java Servlet API 2.3 specification, the
interaction between the Authentication provider and the client or other servers is architecturally limited during the authentication process. This restricts authentication
mechanisms to those that are compatible with the authentication mechanisms the Servlet container offers: basic, form, and certificate.
Filters have fewer architecturally-dependence limitations; that is, they are not dependent on the authentication mechanisms offered by the Servlet container. By
