Securing WebLogic Server 12c

Java standard security is implemented with the security manager and policy files, and is extended by the Java Enterprise Edition in a completely transparent way for the developer; like every other service offered by the platform.

If you are an Enterprise Bean developer, you can develop knowing that the container will take care of the sensitive task of securing your data in the same way it takes care of remoting, translating from HTTP protocol to servlet method call, and transaction management. Obviously, it is impossible for the container to be aware of the infrastructure in which it will be deployed, so there are a lot of standard ways to extend it in order to let it work with a new RDBMS: installing the Java Database Connectivity (JDBC) driver JAR files or a new transactional resource that implements the resource adapter contract.

This principle applies to security as well; but until Java EE 6 there were no standard methods of implementing a new Authentication Provider, or whatever is inherent to security. As we'll see, this new version makes it mandatory that containers implement JASPIC 1.0, but many of them implement it in parallel and WebLogic 12c is no exception. If you need to implement something that is not "simple", custom Providers with custom API are required.

In Java EE, the developer interacts with the container using declarative annotations or XML descriptors. When you need to secure a URL managed by a servlet, all you need to do is annotate that servlet with the @ServletSecurity annotation along with a list of allowed roles, as shown in the following code snippet:

@WebServlet("/mysecuredurl")
@ServletSecurity(@HttpConstraint(rolesAllowed={"myrole"}))
public class MySecuredServlet extends HttpServlet {
...
}

This single line of meta-code opens up the magic world of Java EE security, as explained in the following points:

Every single step described here involves a bunch of very complex tasks, and all of them are free for the Java EE developer; they are made behind the curtain by the container.

type=<ejb>, app=SecuredApp, module=EJBModule, ejb=VeryImportantEJB, method=callItSecure, methodInterface=Home, methodParams={String, int}

@MXBean
public interface MyManagedProperties {
    public int getCached();
    public void callOperation();
}

@Singleton
@Startup
public class MyManagedPropertiesBean implements MyManagedProperties {
   private MBeanServer platformMBeanServer;
   private ObjectName objectName = null;
   @PostConstruct
   public void registerInJMX() {
      try {
        objectName = new ObjectName("MyMXBean :type=" + this.getClass().getName());
        InitialContext ctx = new InitialContext();
        platformMBeanServer = (MBeanServer) ctx.lookup("java:comp/env/jmx/runtime");
        ctx.close();
        platformMBeanServer.registerMBean(this, objectName);
        } catch (Exception e) {
        throw new IllegalStateException("Problem during registration of Monitoring into JMX:" + e);
      }
   }
   public int getCached() {//doSomething}
   public void callOperation() {//doSomething}

   @PreDestroy
   public void unregisterFromJMX() {
      try {
        platformMBeanServer.unregisterMBean(this.objectName);
        } catch (Exception e) {
        throw new IllegalStateException("Problem during unregistration of Monitoring into JMX:" + e);
      }
   }
}

Developing an Authentication Provider is a fairly complex task with many concepts that need to be understood. Here, we will introduce the concepts regarding the composing parts of a provider and different kinds of authentication.

Authentication under WebLogic

Authentication is completely delegated to entities called Authentication Providers, which are a set of classes and configuration files that incorporate an MBean and a LoginModule interface. Every time you request a protected resource, every configured Provider is requested to add the principals extracted from the credentials provided.

This mechanism is very similar to the one configurable on the client with only JAAS (and jaas.config); the main difference is that it's done with the administration console. This console allows us to configure parameters visually, through the automatically-generated JSP page, without touching any XML file, as shown in the following screenshot:

A lot of organizations have heterogeneous systems that need security services, and many of these systems interact with users that have already declared who they are, for example, during the login phase of their workstation at the beginning of their working day.

This is the basis to introduce the concept of a Perimeter, where authentication is made once and then always trusted during the day. The same happens when you use your badge to enter into your company; you are trusted to be allowed into the buildings, with the need to expose the badge to express that you are an employee. In case of Perimeter Authentication, a token released by a third party is used to extract who the user is, by performing an Identity Assertion and not full authentication.

This means that when developing LoginModule interfaces for Identity Assertion providers, Credentials are used not to decide if the user is authenticated, but simply to populate the Subject with the Principals that can be found using the token.

Prior to Java EE 6 and the introduction of the SecurityContext interface in Java EE Connector Architecture (JCA) 1.6 specification (see the SecurityContext interface in JCA 1.6 specifications at http://jcp.org/en/jsr/detail?id=322), there were no standard ways to map the current SecurityContext security object to the ConnectionSpec interface of a resource adapter.

This could mean the following two things:

WebLogic Security Framework supports the mapping of credentials from the current authenticated user to a format that can be understood by the resource adapter/EIS.

The implementation is really straightforward. Before calling the execute()method on the interaction in the ConnectionSpec interface, the Mapper is asked to convert the current Credentials stored into the Subject into one or more Credentials valid for the remote system.

Currently, if BasicPassword is the current authentication mechanism type and PasswordCredential is the interface that has to be used for the communication, it's sufficient for the developer of the custom Credentials Mapping provider to write a function that maps the local security space to that of the called EIS.

Conceptually, this is not much different from what is done with Identity Assertion and Perimeter Authentication; but this time the trust is between WebLogic and an external system, with the former responsible for security. Of course, there may also be Mappings that are able to make full authentication, but in both cases the weak link is the Java Application Server that has the chance to authenticate users to a remote system.

After so many pages talking about security and how to implement it in WebLogic, the question is: why is all this custom-made and not regulated by Java EE?

Java EE 6 has the correct answer to this question: the JASPIC 1.0 specification, a message processing framework that is protocol-independent and that can do what an Authentication Provider does for us; that is, populate Subjects with Principals and therefore authenticate a remote user agent.

In a manner that is different from WebLogic Security Framework, where everything is inside a secure framework API because the message and the protocol are managed by the application server, this is done at the message level. In this way, it enforces the concept that security is something related to the protocol and the way information is exchanged.

In fact, currently we have three profiles that are part of the standard specification, one that is able to authenticate HTTP clients, another that works with SOAP messages, and a third profile that tries to bridge the new specification with the existing JAAS login module on the market.

This is the first implementation in WebLogic and its immaturity is apparent from the total lack of documentation and the fact that the configuration is not integrated into the custom deployment descriptors. So, consider using it only on noncritical systems.

Java Authorization Contract for Containers (JACC) is an extension of the standard policy-based security of the JVM for role mapping and authorization of servlets and EJBs. The working of this policy-based security is shown in the following screenshot:

Although it is implemented by WebLogic, Oracle itself discourages its use because of the lack of features and flexibility compared to custom providers, and also because of performance issues. For these reasons, JACC will not be covered in this book.

This chapter was a quick introduction to WebLogic security fundamentals learning theory that will be used later when a custom provider will be developed or configured inside our domain using the WebLogic console.

It started from Java EE security and then declined to the WebLogic Security Framework, from MBeans to resources.

Finally, two Java Specification Requests (JSR) specs were covered, JASPIC and JACC, to show how limited they are compared to custom providers.