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:
- Username/Password: The most traditional model, which requires a user ID and password to authorize and provide access to a protected resource. It can be enhanced to use a certificate (SSL) or HTTPS to provide transport-level security.
- Certificate: During HTTPS/SSL requests, the client can verify whether the digital certificate is authentic and if the Secure Socket Layer (SSL) connection was established. WebLogic also supports two-way SSL authentication through a specific authentication provider (provided both client and server present a valid certificate).
- Digest: This is a very sophisticated method to authenticate and prevent replay attacks. When the client sends a request to the server, this model will return a token or challenge to inform the client it supports that mechanism. Then, the client must generate a hash that usually is a complement of password, nonce (an arbitrary number that can be used only one time), and timestamp. The server also stores a small cache of used passwords, so older requests are rejected since the hash will not match or would be already used by a successful authentication.
- Perimeter: Perimeter authentication relies on external systems or agents exchanging tokens with a WebLogic domain's Identity Assertion. Common examples of such a mechanism are Simple and Protected GSS-API Negotiation Mechanism (SPNEGO), Security Assertion Markup Language (SAML), or even Virtual Private Networks (VPNs). These authentication methods are much more complex and out of the scope of this book.
Tip
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:
- An embedded LDAP server – this is the default WebLogic authentication provider
- An external LDAP server – this supports any LDAP v2/v3 server, including some proprietary implementations
- An external database system (DBMS) – this supports any database system already supported as a WebLogic JDBC data source
- A simple text file – this is not recommended for a production environment
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).
Note
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 toOPTIONAL, 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.
Tip
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.