IT-Security: WebLogic Server and Authentication – Part 4
As I mentioned, JAAS is able for two important tasks: authentication and authorization of users. Now, let us see more about them.
Authentication: Who are you?
Authentication verifies that the user is who she/he claims to be. But user is also an entity and could be a person, a software entity or other instances of WebLogic Server (so called “resources”). WLS performs proof material typically through a JAAS LoginModule and JAAS authentication is implemented in a pluggable method. A user’s identity is confirmed through the credentials presented by that user, such as:
- something one has, e.g. credentials issued by a trusted authority such as a passport or a smart card
- something one knows, e.g. a shared secret such as a password,
- something one is, e.g. biometric information
A combination of several types of credentials is known as „strong“ authentication; e.g. using an ATM card (credential 1) with a PIN or password (credential 2).[1]
Types of Authentication
WebLogic Server is able to perform the different types of authentication, because it can use the WebLogic Authentication provider or custom security providers. Administrators are able to define a user and password with WebLogic Authentication provider. The all passwords will be encrypted. Users may be placed into groups or be related with security roles.
Basic Authentication: Username/Password
Basic authentication is defined via The Internet Engineering Task Force (IETF®) so: “The „basic“ authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms on that server. The server will service the request only if it can validate the user-ID and password for the protection space of the Request-URI. There are no optional authentication parameters.”[2]
In this type of authentication will be user/password requested. WebLogic scenario looks like this: the user and sent ID/PW to WebLogic Server. It checks them and if it is reliable, gives access to the protected WebLogic resource. In background, WebLogic Server checks the security policy of the WebLogic resource and the principal (that the user has been assigned) to make sure that the user has the obligatory permissions to continue.
In addition, you can use https. User/password will be encrypted between client and server through SSL communication. It is an extra advantage that the transaction between client and server will not be performed in clear text.
Certificate Authentication
We are going to discuss about Secure Sockets Layer (SSL) in the next articles. SSL delivers protected connections. The SSL-communicating authenticate identity of two entity and/or application that communicate through a network connection. In addition, the whole SSL-communication is encrypted. WebLogic Server provides a pure-Java implementation of SSL and supports One-Way- and Two-Way- SSL authentication.
Simple to say, if a WLS to authenticate to a client, then we have a One-Way SSL. If a client to authenticate to a WLS, then we have Two-Way SSL. One-Way SSL is obligatory but Two-Way SSL is optional. During “handshaking” exchange the applications and/ or entities digital certificates. The digital certificate is supplied by an entity, which authenticates the identity of WebLogic Server.
Afterwards, the both sides, also WebLogic Server and client, decide on the encryption algorithms to be used. As third step, SSL-connection generates the encryption keys to be used for the remainder of the session. The encryption keys is a hybrid encryption approach that it uses advantages of asymmetric and symmetric encryption therefore, it is known as a good combination between better performance and security in network communication.
Digest Authentication
We are going back to this topic for deeper discussion. As an introduction, we can start with the definition of The Internet Engineering Task Force (IETF®): “Like Basic Access Authentication, the Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value. A valid response contains a checksum (by default, the MD5 checksum) of the username, the password, the given nonce value, the HTTP method, and the requested URI. In this way, the password is never sent in the clear. Just as with the Basic scheme, the username and password must be prearranged in some fashion not addressed by this document.”[3]
Weblogic Server supports digest authentication and is resistant to replay attacks. “The implementation maintains a cache of used nonces/timestamps for a specified period of time. All requests with a timestamp older than the specified timestamp are rejected as well as any requests that use the same timestamp/nonce pair as the most recent timestamp/nonce pair still in the cache. WebLogic Server stores this cache in a database.”[4]
I’m going to continue with Authentication’s topic in next part of IT-Secrutity and WebLogic Server.
[1] See Oracle Fusion Middleware Security Overview http://docs.oracle.com/cd/E23943_01/core.1111/e12889.pdf
Oracle Fusion Middleware 11.1.1.5, Security Guides http://docs.oracle.com/cd/E21764_01/security.htm
Oracle® Fusion Middleware Securing Oracle WebLogic Server http://docs.oracle.com/cd/E21764_01/web.1111/e13707/toc.htm
Oracle Platform Security Services 11gR1 (White Paper)
http://www.oracle.com/technetwork/middleware/id-mgmt/opss-tech-wp-131775.pdf
[2] Request for Comments: 2617: The Internet Engineering Task Force (IETF®): https://datatracker.ietf.org/doc/rfc2617/
[3] Request for Comments: 2617: The Internet Engineering Task Force (IETF®): https://datatracker.ietf.org/doc/rfc2617/
[4] Oracle® Fusion Middleware Understanding Security for Oracle WebLogic Server 11g Release 1 (10.3.5) http://docs.oracle.com/cd/E21764_01/web.1111/e13710/toc.htm