O'Reilly Book Excerpts: WebLogic: The Definitive Guide
Java and Security, Part 2by Avinash Chugh, Jon Mountjoy
Editor's note: Last week's excerpt from Chapter 17 of WebLogic: The Definitive Guide examined WebLogic's security mechanisms, including the Java Security Manager. In this week's second and final excerpt from the book, authors Avinash Chugh and Jon Mountjoy cover WebLogic's various security providers and their default implementations, along with a look at how to authenticate using JAAS, and examples of Authentication and Identity Assertion Providers.
Now we'll take a closer look at the different SSPIs that constitute a security realm. We'll learn about WebLogic's default implementation of these security providers and how to configure them. The default implementation provides the authentication architecture (and much more) that we have just seen. You can replace one or more of the providers with your own code if you want to change its behavior. Once again, the Administration Console lets you view and modify the configuration of these security providers. All of the security providers available to your realm can be found under the Security/Realms/myrealm/Providers node in the left pane of the Administration Console, where "myrealm" refers to the name of the security realm. Finally, we'll learn about the embedded LDAP server that holds all of the security data for the domain on behalf of the default security providers.
Authentication refers to the server's ability to reliably verify the identity of a user or system. We generally refer to a user or system being authenticated as simply a user. A user requires some proof of identity before it can establish trust with the server. WebLogic supports Authentication Providers that can validate user credentials based on a username-password combination or a digital certificate. The security provider repository, which stores the user and group information, can be implemented in the following ways:
- As an embedded LDAP server, which is the default used by WebLogic's security providers
- As an external LDAP store, such as Open LDAP, Active Directory, Novell, or NDS
- As a DBMS, which you may already be using to host the data for your enterprise applications
- As a text file, which is used by WebLogic's sample security providers
WebLogic's authentication provider architecture closely follows the authentication
part of the standard JAAS. Following the JAAS terminology, a subject represents the
source of a security request—it represents a user or system that is trying to be
authenticated. The point of authentication is to assign principals to a subject. Principals
are identities that represent the result of a successful authorization. As we have
seen, when the
system user authenticates successfully, the subject representing this
user is assigned a principal recording the fact that he is in the
and another recording that he is a WebLogic user with the name
system. Therefore, a
subject is a standard container for authentication information, including principals.
A client can use a subject to query its identity and other attributes. Figure 17-2 illustrates
this client authentication process.
Figure 17-2. The client authentication process
The Authentication Provider adheres to the standard JAAS framework by structuring the authentication sequence on top of a number of configurable JAAS LoginModules. LoginModules are critical components of an Authentication Provider, as they are responsible for authenticating users within a security realm and populating the subject with the required principals (existing users and groups).
WebLogic demands that you have at least one authentication provider configured in your security realm.
Principal Validation Providers
Once a (possibly remote) client has established trust with WebLogic, the authenticated subject is retained on the client between server invocations. The Principal Validation Provider ensures that no hanky-panky has taken place with the subject's principals at any time between these invocations. It does this by signing and verifying the authenticity of the principals held by the subject. Once the principals have been validated, they can be used by an Authorization Provider for access control checks or by the Role Mapping Provider for role-mapping decisions. A security realm must define a Principal Validation Provider for each Authentication Provider.
Identity Assertion Providers
Identity Assertion Providers help secure access to the entry points of a WebLogic deployment. Instead of using usernames and passwords, an external client may use tokens to establish trust with a WebLogic Server. The Identity Assertion Provider verifies a token and, if successful, maps it to a valid WebLogic user. Once the token is mapped to a valid user, an Authentication Provider can then generate the principals for the user. This mechanism is called perimeter authentication, so you can consider an Identity Assertion Provider a special type of Authentication Provider. The key point here is that an external agent is responsible for authenticating the user, and then for conveying the user data to WebLogic.
As a side effect, perimeter authentication also enables single sign-on. For instance, an Identity Assertion Provider could supply an X.509 digital certificate as an identity token, and these credentials then could be used across multiple systems. WebLogic supports Identity Assertion Providers that can handle different token types (X.509, IIOP-CSIv2). Alternatively, you can create an Identity Assertion Provider that supports custom token types (e.g. Kerberos tickets). An Identity Assertion Provider can have multiple active token types. However, a token type can be active only in a single provider. Of course, a security realm may support multiple Identity Assertion Providers, though none is required. Figure 17-3 illustrates perimeter authentication.
Figure 17-3. Identity assertion during perimeter authentication
The Default Authentication Providers
WebLogic supports authentication based on username-password combinations, authentication using digital certificates transmitted either directly to WebLogic or via an HTTP server, and perimeter-based authentication based on security tokens. WebLogic lets you use the Authentication Providers described next.
- Default Authenticator
- This is WebLogic's default Authentication Provider, which relies on the embedded LDAP server to persist all security information.
- Realm Adapter Authentication Provider
- This provides backward compatibility with user and group information held in old WebLogic 6.x realms.
- Default Identity Asserter
- This is WebLogic's default Identity Assertion Provider, which verifies the authenticity of X.509 and IIOP-CSIv2 tokens and maps them to valid WebLogic users.
- LDAP Authentication Providers
- These providers use external LDAP stores to persist all security information about users and groups. WebLogic lets you configure Authenticators that can access various LDAP stores, including Open LDAP, Sun's iPlanet, Microsoft's Active Directory, and Novell NDS.
In addition, you may assign custom-built Authenticators and Identity Asserters to the security realm.
In order to access the Authentication Providers assigned to a realm, select the Authentication node from the left pane of the Administration Console. The right pane then lets you select one of the configured Authenticators, or configure a new Authenticator.
A security realm can have a sequence of Authentication Providers (and hence JAAS
LoginModules) working in unison. Each Authentication Provider has a JAAS control
flag setting that determines how the overall login sequence behaves with respect to
that particular Authentication Provider. This is no different from how you configure
LoginModules within a J2SE application. To order the Authentication Providers
within a security realm, select the Authentication node from the left pane and
choose the Re-order the Configured Authentication Providers option. The control
flag of each authentication provider can take the following values:
- This option is the default setting for any Authentication Provider. A required
Authentication Provider is always invoked, irrespective of the control flag settings
on other providers. The overall authentication cannot succeed if any
REQUIREDprovider fails. Thus,
REQUIREDproviders are always invoked, and overall authentication fails if any one of them fails.
- This option also requires the Authentication Provider to succeed during the
login sequence. However, all of the
REQUISITEproviders need not be invoked for the overall authentication to succeed. If a
REQUISITEprovider succeeds, the authentication proceeds as normal to other providers in the sequence. However, if it fails, the overall authentication cannot succeed, and control is immediately passed back to the application once all
REQUIREDproviders in the login sequence have been invoked.
- This option does not require the Authentication Provider to succeed during the
login sequence. If a
SUFFICIENTprovider does succeed, the overall authentication proceeds to ensure that only the remaining
REQUIREDproviders in the login sequence are executed. However, if it fails, the overall authentication proceeds as normal to the other providers in the login sequence.
- This option does not require the Authentication Provider to succeed during the
login sequence. Regardless of whether an
OPTIONALprovider succeeds, the authentication proceeds to other providers that have been configured as part of the login sequence.
LoginModules are used to authenticate a user, the authentication
occurs in two phases. During the first phase, the modules are asked to attempt to
authenticate the user. Only if the modules pass this phase is the second phase
invoked. During the second phase, each module commits the login and assigns the
relevant principals to the subject. The control flags influence how this two-phase
commit occurs. Thus, for the overall authentication to succeed, the following rules
must be met:
REQUIREDmodules must be invoked, and each must successfully validate the user.
REQUISITEmodule that gets invoked must successfully validate the user.
- If a
SUFFICIENTmodule successfully validates the user, the overall success depends on the success of all
REQUIREDmodules, and any
REQUISITEmodules invoked before the
- If the login sequence consists only of
OPTIONALmodules, at least one module must successfully validate the user.
Though you can write your own Authenticators, WebLogic's default implementation of the SSPIs comes with a number of built-in authenticators that you can use. Let's look at these authenticators in more detail.