WebLogic Security

The increase in transactions over the Web has resulted in more interaction between the WebLogic Server and EJBs, Web applications, and its components. Often, this interaction involves the exchange of sensitive information. Preventing this sensitive information from being hacked or misused and maintaining its integrity is of great importance. This makes it imperative that as an application developer or Web server administrator, you become aware of the important security features built in to the WebLogic Server and how you can use them to secure your applications.

WebLogic Security Architecture

WebLogic Server 7.0 has built-in support for Java Authentication and Authorization Service (JAAS). Therefore you can use the JAAS API in your application for authentication services.

If you already have third-party security services for any of your application components, such as EJBs, JSPs, servlets, or WebLogic components like RMI objects and JMS destinations, their integration with the WebLogic Server can be done.

Also, integration of Public Key Infrastructures (PKIs) supporting the use of Certificate Revocation Lists (CRLs) and Online Certificate Status Protocols (OCSPs) with the WebLogic Server is encouraged.

Microsoft Passport and other authentication services based on Security Assertion Markup Language (SAML) are also supported by the WebLogic Server.

Figure 18.8 shows you the architecture of the Weblogic Server Security Service.

Figure 18.8. Architecture of the WebLogic Server Security Service.

As you can see, WebLogic provides its security services for rich clients and thin clients. Also, an application developer or a security vendor can seamlessly integrate its services with WebLogic's Security Services by using the weblogic.security package APIs. When WebLogic Server is acting like a client, WebLogic Security Service Provider Interfaces (SSPIs) can be used. SSPIs are used for developing applications for authentication, authorization, auditing, role mapping, key store (PKI), and credential mapping.

Tip

The WebLogic Server also has support for the SDK classes. So, you can use your code with the JSSE packages, implementing SSL and TLS v1 protocols, the JAAS package and the Java Security Manager for the JVM through the java.lang.SecurityManager class.

Note

JAAS mainly provides API for Authentication and Authorization services. The authentication component is meant to protect the resources irrespective of the way it is being accessed, that is, either through an applet, a Java application, and so on. The Authorization component prevents the application code from performing any sensitive tasks, depending on the access rights of the user and the code source. Authentication in JAAS is performed by using the LoginContext object and the Configuration object or a LoginModule. The authentication may be done either by a user ID and password verification, fingerprinting, or voice recognition. The other noticeable feature of JAAS is that it is implemented as pluggable modules. In the case of any new security service required to be plugged in, this can be performed easily without having to alter the existing application code.

The main concepts of WebLogic Security Service are based on these points. The following sections describe them in more detail.

Authentication

When the identity of the user is verified, the user is said to be authenticated. Authentication helps in guarding not only the people who access the system, but also the resources that they access. There are various ways a user can be authenticated:

• Using user ID and password

• Using certificates directly via the WebLogic Server

• HTTP certification routed through an external Web server

• Through a firewall, Web server and VPN(Virtual Private Network), also called perimeter-based authentication

• Through multiple security token types, like SOAP and IIOO-CSIv2

Tip

Generally, to safeguard systems, a network is placed inside a logical security perimeter. Any access to resources within this perimeter must go through a single point of entry, like a gate in the firewall or the Web server. Hence, this kind of security is called perimeter-based authentication.

Point to Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol are inherently supported by your computer. Resources can be securely accessed through these protocols by connecting through private or public networks via a remote access server or the Internet. This use of networks is called a Virtual Private Network, or VPN.

The authentication system is made up of three common layers:

• Authentication Provider

• Login Module

• Principal Validation Provider

A fourth layer comes into the picture when perimeter-based authentication is used. This is the Identity Assertion provider.

Any authentication provider must implement the AuthenticationProvider SSPI so that the services of the authentication provider are exposed to the WebLogic security framework.

The Login Module, the principal validation provider, and the identity assertion provider use the JAAS. This authenticates the users within the security realm.

Note

All security providers must exist inside a logical area called a security realm. Each of the services offered in security exists inside a distinct realm.

Authorization

Allowing access to authenticated users on basis of their access rights is carried out by the Authorization provider of the WebLogic Server Security Service. This is controlled by the Access Control List (ACL). In a security realm, whether or not a user can access a resource is governed by the ACL. For every resource, an ACL is created. Permissions are then created for this resource, and the ACL is then granted the user name or a logical group of users (for example, all users falling under the category of developers have access to the development database but not to the production database, whereas all project managers have access to the production database, and so on).

The Authorization model, described here, divides the users of a system, as illustrated in Figure 18.9:

• A user is a single person or utilizer of resources.

• A group is a set of users logically grouped together to make management of resources and the roles of these users easier.

• After authentication a user or group is allocated an identity. This identity is called a principal.

• Authentication information and principals, as per JAAS, have to be contained in subjects.

Figure 18.9. Users, groups, principals, and subjects.

Authorization mainly consists of the following components:

• Authorization provider

• Access Decision provider

• Adjudication provider

• Role-Mapping provider

Of these, the Access Decision provider layer actually checks whether the user has permission to access a particular resource. The Adjudication provider takes the decision of what is to be done depending on the reply from the Access Decision layer. The Role-Mapping provider has the duty of performing a dynamic role mapping of the user type in a role-based security system.

Auditing

Auditing is the process of logging in a WebLogic Server system the activity of users or the trail of resources used by each of the users. These logs or records can be used later to backtrack if some error occurs. This auditing can be done on different security criteria or audit criteria.

The auditing service has to be configured and enabled. If it has been configured, the WebLogic Server framework routes each request through the audit provider. This means that every time a resource is requested, authorized, and access granted, (and the information is actually passed on), the WebLogic Server goes through the audit provider to log each of these requests. It may even page security personnel if some sensitive resources have been marked for it. This information can be written later onto logging repositories, such as a flat file, a database, or even an LDAP server.

The Audit provider is made of the following components:

• Audit Provider

• Audit Channel

• Audit Event

The combination of these three components contributes to the functionality of an audit service provider.

Confidentiality

The ability to hide information or data in terms of its visibility while being exchanged or transferred during a transaction is called confidentiality. Confidentiality in the WebLogic Server is provided through two different mechanisms:

• Keystore providers

• Credential mapping providers

A keystore is a technique specially developed for managing password-protected databases that store their private and public key certificates. These private and public key certificates may be needed to authenticate the user. Keystores are used at this time. A keystore provider enables the use of SSL, keys, and certificates.

One point to be noted about keystore providers is that they have specific meanings in J2EE. Furthermore, they are meant to be standalone providers; that is, keystore providers do not access any other security providers, and vice versa.

Every source of a request resource or a subject is attached to a set of credentials. This information is used to authenticate the user for any further request of resources. Now such credentials exist on remote systems and WebLogic Server, too. The mapping of these two, so that the WebLogic Server knows how to use the credentials of the remote server, is known as credential mapping.

Single Sign-On

In any application, it is possible that a user may need to access many types of resources, each requiring separate authentication. If each one of these accesses were to be authenticated, it would get rather tedious. To resolve this problem, a single sign-on concept was introduced.

Single sign on is the process by which the information from a single authentication process can be used repeatedly to authenticate the user onto any further resources to be accessed. The WebLogic Server 7.0 provides a component called security providers that enables plugging in of any single sign on solution into the WebLogic framework. WebLogic Server 7.0 supports cross-domain single sign on, a perimeter authentication required in any such process.