Oracle WebLogic supports and fully implements both Java SE and EE security models using JDK APIs such as JASPIC, JAAS, JSSE, or JCE for remote and even internal authentication. So, if the client is an EJB, a servlet, or an applet, the same mechanisms will be used to authenticate and authorize its execution.
The authentication can be performed through these models:
The Java Authentication Service Provider Interface for Containers (JASPIC) specification (JSR 196) defines a model or a Service Provider Interface (SPI) through authentication providers for Java EE application servers, which is applicable for protocols (SOAP, JMS, and HTTP) and processing runtimes, extending the JAAS model. The authentication provider model will be explained with further details in the next section.
Authentication can be performed using the methods described in the previous section, and we can even combine them; for instance, using a digital certificate to establish an SSL connection and passing a valid username/password credential through it. An authentication provider can be configured based on these types:
As already mentioned, WebLogic follows the JAAS security model and as a result of a successful authentication on any of these providers, the return will be a Subject with the appropriate principals according to what is set on the user profile in the data store (an LDAP or database server, for instance).
Authentication providers have a special and very important attribute named Control Flag
. WebLogic uses this attribute in case it has multiple authentication providers, which loads permissions from different stores (so it can check if, for example, a user exists in all providers and give it the appropriate identity and permissions). Another common scenario is when we have multiple stores and they can act as redundant options. So WebLogic will attempt to load the permissions using the default provider and then, if it's not available, move to the second on the list. The possible values for this attribute are:
REQUIRED
: This value is always called, irrespective of the authentication passing or failing; the authentication process will continue down the list of providers.REQUISITE
: The authentication must pass this provider, irrespective of the authentication passing or failing; the next providers will be executed, but they can fail if this one succeeds.SUFFICIENT
: This value is not always required, but if it succeeds, other providers will not be executed. If it fails, authentication will continue down the list of providers.OPTIONAL
: The user can fail on this provider without further implications. However, if all providers are set to OPTIONAL
, at least one of the providers must succeed.WebLogic can have multiple security realms; however, you can have only one realm active for a domain. In the security realm, you can specify multiple authentication providers, and at least one of them must be active. Each authentication provider holds a LoginModule that performs the actual authentication, and if the realm uses multiple authentication providers, they will store multiple principals for the same subject.
It's also possible to implement custom authentication providers (with LoginModule
) when the default authentication providers of WebLogic don't meet the security requirements of your application. Such custom providers are out of the scope of this book, but a link with an example can be found in the Web resources section of this chapter.