WebLogic security architecture is based on a set of classes in the weblogic.security.* package in the WebLogic Security Framework (WSF), which are used to develop Security Providers that run under the auspices of WebLogic Security Service.

This runtime is the orchestrator that allows application components such as EJBs and servlets to communicate with server resources, with the intermediation of the Security Provider.

Here, we will review some basic concepts of WSF that we need to understand to develop custom providers.

WebLogic follows the JAAS architecture of Java SE for its security infrastructure: Subjects, Principals, and Credentials. These are explained as follows:

In JAAS, when the login() method is called on the current LoginContext class, a new Subject object is created and the configured LoginModule is called in sequence to enrich that object with principals.

So, for instance, it is possible to configure a LoginModule interface that adds Kerberos credentials, another LoginModule, like WebLogic's UsernamePasswordLoginModule, that adds PasswordCredential. These are then used by WebLogic to access restricted resources.

Java EE 6 defines the security of components such as an EJB or a connection to an Enterprise Information System (EIS); WebLogic resources extend this level of security. The following is a quote defining resources from the official WebLogic 12c documentation:

This means that a DataSource object can't be accessed directly but only through a JDBCResource object, and every resource is also represented as a hierarchy; if security is not specified for the leaf, its single parent can be inspected until a suitable configuration is found.

Suppose, for example, the container is checking if the user is allowed to access a certain method of an EJB, whose resource representation is as follows:

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

If the EJBResource class can't find a suitable policy for that method, it will ask its parent, the Enterprise Bean, which can verify if the user is allowed or not.

Java Management Extensions (JMX) is a mandatory part of the Java EE 6 specification that defines standards for the monitoring and management of Enterprise applications in a dynamic and nonintrusive way. Using JMX, it is possible to query an arbitrary application for diagnostic information without knowing anything about the way it is being implemented, but only using a standard tool like JConsole or VisualVM. This is implemented in a structured way, where JMX defines the runtime, the way Management Beans are developed, and how to access that information. Implementation is straightforward; you only need to define what you want to, as follows:

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

And the implementation—in Java EE 6 it's really a few lines of code—is as follows:

@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);
      }
   }
}

An MXBean interface is implemented in the previous code; it is a Managed Bean that can be accessed by a JMX client, which doesn't need to know anything about our application. It is the duty of the agent to convert every domain-specific class to simple properties.

Unfortunately, developing MBeans for WebLogic is not that easy, because of a custom way to generate the MBeans that execute in the MBeanServer interface. It is necessary to write a custom XML file, called MBean Definition File (MDF), and then generate a JAR file that can be installed on the WebLogic server using WebLogic's MBeanMaker tool.