3-2 Understanding Security for Oracle WebLogic Server
identity information available to various components of a system via 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.
The following sections describe authentication concepts and functionality.
■
Section 3.2.1, Subjects and Principals
■
Section 3.2.2, Java Authentication and Authorization Service JAAS
■
Section 3.2.3, CallbackHandlers
■
Section 3.2.4, Mutual Authentication
■
Section 3.2.8, Servlet Authentication Filters
■
Section 3.2.5, Identity Assertion Providers and LoginModules
■
Section 3.2.6, Identity Assertion and Tokens
■
Section 3.2.9, Types of Authentication
3.2.1 Subjects and Principals
Subjects and principals are closely related. A
principal is an identity assigned to a user or group as a result of authentication.
Both users and groups can be used as principals by application servers such as WebLogic Server. The Java Authentication and Authorization Service JAAS requires
that subjects be used as containers for authentication information, including principals.
Figure 3–1 illustrates the relationships among users, groups, principals, and subjects.
Figure 3–1 Relationships Among Users, Groups, Principals, and Subjects
As part of a successful authentication, principals are signed and stored in a subject for future use. A Principal Validation provider signs principals, and an Authentication
providers LoginModule actually stores the principals in the subject. Later, when a caller attempts to access a principal stored within a subject, a Principal Validation
provider verifies that the principal has not been altered since it was signed, and the principal is returned to the caller assuming all other security conditions are met.
Any principal that is going to represent a WebLogic Server user or group needs to implement the WLSUser and WLSGroup interfaces, which are available in the
weblogic.security.spi package.
Security Fundamentals 3-3
3.2.2 Java Authentication and Authorization Service JAAS
Whether the client is an application, applet, Enterprise JavaBean EJB, or servlet that requires authentication, WebLogic Server uses the Java Authentication and
Authorization Service JAAS classes to reliably and securely authenticate to the client. JAAS implements a Java version of the Pluggable Authentication Module PAM
framework, which permits applications to remain independent from underlying authentication technologies. Therefore, the PAM framework allows the use of new or
updated authentication technologies without requiring modifications to your application.
WebLogic Server uses JAAS for remote fat-client authentication, and internally for authentication. Therefore, only developers of custom Authentication providers and
developers of remote fat client applications need to be involved with JAAS directly. Users of thin clients or developers of within-container fat client applications for
example, those calling an Enterprise JavaBean EJB from a servlet do not require the direct use or knowledge of JAAS.
3.2.2.1 JAAS LoginModules
A LoginModule
is the work-horse of authentication: all LoginModules are responsible for authenticating users within the security realm and for populating a subject with
the necessary principals usersgroups. LoginModules that are not used for perimeter authentication also verify the proof material submitted for example, a users
password.
If there are multiple Authentication providers configured in a security realm, each of the Authentication providers LoginModules will store principals within the same
subject. Therefore, if a principal that represents a WebLogic Server user that is, an implementation of the WLSUser interface named Joe is added to the subject by one
Authentication providers LoginModule, any other Authentication provider in the security realm should be referring to the same person when they encounter Joe. In
other words, the other Authentication providers LoginModules should not attempt to add another principal to the subject that represents a WebLogic Server user for
example, named Joseph to refer to the same person. However, it is acceptable for another Authentication providers LoginModule to add a principal of a type other than
WLSUser
with the name Joseph.
3.2.2.2 JAAS Control Flags
If a security realm has multiple Authentication providers configured, the Control Flag attribute on the Authenticator provider determines the ordered execution of the
Authentication providers. The values for the Control Flag attribute are as follows:
■
REQUIRED - This LoginModule must succeed. Even if it fails, authentication proceeds down the list of LoginModules for the configured Authentication
providers. This setting is the default.
■
REQUISITE - This LoginModule must succeed. If other Authentication providers are configured and this LoginModule succeeds, authentication proceeds down the
list of LoginModules. Otherwise, return control to the application.
■
SUFFICIENT - This LoginModule needs not succeed. If it does succeed, return control to the application. If it fails and other Authentication providers are
configured, authentication proceeds down the LoginModule list.
■
OPTIONAL - The user is allowed to pass or fail the authentication test of this Authentication providers. However, if all Authentication providers configured in
a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the configured providers.
3-4 Understanding Security for Oracle WebLogic Server
3.2.3 CallbackHandlers
A CallbackHandler is a highly-flexible JAAS standard that allows a variable number of arguments to be passed as complex objects to a method. There are three types of
CallbackHandlers: NameCallback, PasswordCallback, and TextInputCallback
, all of which are part of the javax.security.auth.callback
package. The NameCallback and PasswordCallback
return the username and password, respectively. TextInputCallback
can be used to access the data users enter into any additional fields on a login form that is, fields other than those for obtaining the username and
password. When used, there should be one TextInputCallback per additional form field, and the prompt string of each TextInputCallback must match the field
name in the form. WebLogic Server only uses the TextInputCallback for form-based Web application login.
An application implements a CallbackHandler and passes it to underlying security services so that they may interact with the application to retrieve specific
authentication data, such as usernames and passwords, or to display certain information, such as error and warning messages.
CallbackHandlers are implemented in an application-dependent fashion. For
example, implementations for an application with a graphical user interface GUI may pop up windows to prompt for requested information or to display error
messages. An implementation may also choose to obtain requested information from an alternate source without asking the user.
Underlying security services make requests for different types of information by passing individual Callbacks to the CallbackHandler. The CallbackHandler
implementation decides how to retrieve and display information depending on the Callbacks
passed to it. For example, if the underlying service needs a username and password to authenticate a user, it uses a NameCallback and PasswordCallback.
The CallbackHandler can then choose to prompt for a username and password serially, or to prompt for both in a single window.
3.2.4 Mutual Authentication
