OIM and Weblogic vulnerability

The vulnerability

Weblogic and OIM are vulnerable to Java deserialization attacks over the network.

This vulnerability was reported to Oracle in 2015 and assigned CVE-2015-4852. Oracle has released a series of patches to address the issue, but many systems continue to be vulnerable. The attack is easy and the steps are publicly available. An attack does not require authentication and can result in complete compromise of your OIM installation. We recommend immediate action to secure your system using the outline below.

  1. Patch Weblogic and Java to the latest versions
  2. Block unneeded network access to the T3 protocol
  3. (Optional) Monitor your logs and network for attack signatures

Weblogic patches

Install the most recent Weblogic patch that is compatible with your OIM installation. As of October 2016, the most recent patch is PSU 161018, which has Patch ID 23743997. We have seen some cosmetic issues with images on OIM's administrative IT Resource and Access Policy screens after patching, but no functional problems. End-user / self service pages do not appear to be affected. Weblogic patches are easy to remove, so there is no risk to installing the patch on a development or QA system.

Java patches

Oracle also routinely publishes Java patches and updates, which you should install. Although JDKs 6 and 7 have reached their public end-of-life, Oracle continues to make new versions available via My Oracle Support. The latest updates of Java include some hardening against this vulnerability. As of 18 October 2016, the latest version of Oracle JDK 7 was 7u111 build 32, which has patch ID 24558841. The latest version of Oracle JDK 6 was 6u121, which has patch ID 23739936. For up to date information, visit MOS Doc ID 1439822.1, which lists all JDK downloads.

Block network traffic

Now that research has begun on deserialization vulnerabilities, it's probable that new variants of the exploits will be discovered in the future. Blocking network access entirely will help defend against those future exploits. Weblogic has a unique feature where various network protocols (like HTTP, T3, and IIOP) all share a single port. It routes the messages based on their content. If someone can access your OIM system in a web browser, they can probably access it via T3, which is natively vulnerable to deserialization attacks.

Weblogic provides a network connection filter feature, which allows you to selectively firewall certain protocols. You should allow T3 traffic only from those hosts which need them. This is typically other servers in the cluster, the local host, and any custom code outside of OIM using its J2EE API. Additionally, the OIM Design Console and LDAP gateway use T3 to communicate.

To set the domain-wide connection filter:

  1. Open the Weblogic Administrative Console (typically at admin-host:7001/console) in a web browser.
  2. Click your domain name in the sidebar.
  3. Click the "Security" tab, then the "Filter" tab.
  4. Type your connection filter (see below) into the "Connection Filter Rules" box. Leave the smaller "Connection Filter" box blank, because you want to use the default.
  5. Save and restart your OIM installation.

The following is an example connection filter for a two-node cluster. It allows T3, T3S, and unencrypted HTTP from the cluster nodes and from localhost, and denies everything except encrypted HTTPS from all other IPs. * * allow t3 t3s http * * allow t3 t3s http * * allow t3 t3s http * * deny t3 t3s http

You can, of course, also use traditional firewalls to narrow the number of people who can access your OIM system on any protocol as much as possible for your organization.


You can proactively monitor your logs and your network for deserialization attacks. Snort rules are available for detecting serialized Java objects. If you want to customize your rules, serialized Java objects will start with the bytes AC ED 00 05. If encoded to Base64, they will start with the text rO0. Note that many applications also communicate legitimately using serialized Java objects. Most deserialization attacks (but not all) will show up in your Weblogic or OIM logs as ClassCastException error messages. If you see AnnotationInvocationHandler in a ClassCastException stack trace, or if java.lang.UNIXProcess is part of the error message, this is almost certainly an attack attempt.

Additional steps

There are more invasive, unsupported ways to defend your system against deserialization attacks, such as JVM agents. While effective, these are beyond the scope of this article. Contact Identity Works LLC for an evaluation of your OIM installation.

Share this post

Getting started with OIM Certifications


Getting set up to do Oracle OIM Certifications:

In OIM, Certifications are now used to drive attestation; for a manager and role owner to review and respond to a list of users and their Roles and Entitlements.  With remediation, these entities can be automatically removed if the access is deemed inappropriate by the reviewers.

Certifications come with an OOTB composite to carry out the workflow for a standard single or two phase Certification campaign.  If you need to have more than one campaign duration, reminder schedule or want to change the emails, you will need to create new SOA composites.

While you can build these composites on the server, I like to have them as part of my Eclipse workspace.


Create Composite Projects in Eclipse

Create a new Java Project. 

Copy the <OIM_HOME>/server/workflows directory to your local drive.

From the local newly created workflows\new-workflow directory, copy the process-template directory and the new_project.xml file to the new project.

Open and explore new_project.xml.

The new_project ant script is, by default, set up to create a new project based on a template. 

<project name="IAM" default="new_project">

            <description>Builds a new BPEL project similar to the template project</description>

<target name="new_project" description="--> Generate structure and sample kernel handler for a new feature">   


An alternate target and the script that is used to generate Certification composites occurs later:

<target name="certification" description="--> Generate a new composite for cert feature">


This is the target we want to use to generate the new Certification composits.

Open new_project with editor and change the default to run the target certifications

<project name="IAM" default="certification">


Run the new_project ant script, Ant Build.


Input new composite name


This builds the soa composite project by expanding a process-template for FlexibleCertificationProcess and creates a new directory structure for the new composite, SingePhase3Month.

Expanding: C:\work\ All WorkSpace\NewCertComposites\process-template\FlexibleCertificationProcess.zip into C:\work\ All WorkSpace\NewCertComposites\process-template

The output project, SinglePhase3Month, is created in the process-template directory.



Moving to JDeveloper

This SinglePhase3Month directory can now be copied into JDeveloper Studio.

(Inmportant: JDeveloper Studio must match the version and patch level as the SOA deployed.  That is a different post.)


Open JDeveloper Studio.

Copy SinglePhase3Month directory and contents to C:\JDeveloper\mywork

From JDeveloper, File> Open> SinglePhase3Month> SinglePhase3Month.jpr


This creates a working Project in JDeveloper

Now we can get to the code that defines the Certification:


Click on SOA Content > composite.xml


Open CertificationTask in diagram


Common configurations will have to do with Deadlines and Notifications.


In Deadlines tab, one can set renewal after duration, expiration duration; or escalation duration, number of escalations and highest Approver title.

In Notifications tab, one can configure notifications in response to a number of Task status states.

For each state, one can configure who it will be sent to and the content.

  • Assign
  • Complete
  • Error
  • Expire
  • Request Info
  • Update Outcome
  • Suspend
  • Withdraw
  • Resume
  • Update
  • Alerted
  • Other actions

Recipients can include    

  • Assignees
  • Initiator
  • Approvers
  • Owner
  • Reviewer


A different email template can be assigned to any combination of status and Recipient. Open Notification Reminder.


Under the Advanced sub Tab, Reminders can be set up as well as other options.


Once configured, the composite is compiled into a jar.


This jar can be deployed directly to the server or can be deployed as a jar.

Let’s do it the old fashioned way and create a jar.


If the composite state is not internally consistent, the validation error will be reported:

Go back and correct omissions.

When all is well:


Deploy using Enterprise Manager

Final step is to Deploy to server using Enterprise Manager.

Log into /em

Click Deploy

Choose File and select SinglePhase3Month> deploy> sca_SinglePhase3Month_rev1.0.jar


Select default




These Composites can now be used to Define Certifications in /sysadmin

Share this post

Automated OIM Configuration Deployments

A majority of organizations implementing Oracle Identity Manager (OIM) struggle with migration and deployment procedures. Migrating a newly developed connector often involves many manual steps, and can result in problems such as a missed deployment steps, importing wrong versions, etc. One solution to those problems is automation, where everything is stored and controlled in a code repository – not just the binaries, but also the configuration files to import, and any setup scripts. In this blog post we will look at the different options available to fully automate a deployment and how to maintain configurations and customizations in a central repository.

Oracle Identity Manager includes a set of tools that allow for the import and export of configurations made in one environment to another. OIM Administrators can use the System Administration interface to achieve this by keeping an inventory of the connectors and the corresponding artifacts such as approvals policies, access policies, lookups, etc. In addition to the deployment manager being available in the web user interface, the deployment manager can also be invoked programmatically to both export configuration from a source environment, and import that configuration into another environment. An organization can write sets of tools to both generate configuration exports (ensuring that no artifacts are missed in the export), and also a set of tools to automate the import of those configuration files. Building custom tools like this allow for a programmatic, repeatable deployment process. An additional benefit of these automated tools is that administrators who are not as familiar with OIM, such as an operations team, can perform deployments.

Readers familiar with OIM’s deployment manager probably know that not everything can be managed using that tool. For example, the deployment manager cannot set parameters within an IT resource, or add members to an OIM role, such as an approver role. However, OIM does make a rich Java API available, which can be used to implement custom tools to handle the import and export of this data.

One way to orchestrate the overall process of exporting and importing the deployment of OIM connectors, corresponding artifacts and OIM configurations is to leverage ANT (http://ant.apache.org). ANT is typically used to manage build process for Java code, however ANT can be easily extended to execute custom tasks, such as ones that call OIM API’s to import a configuration file. An ANT build file will orchestrate the whole process, for example importing a configuration file, then setting up IT resource settings, and possibly running a scheduled task to bring in some initial configuration data. This build file can effectively replace a manual deployment guide with many steps with a single file to run.

Another benefit of an automated approach such as this is that the entire solution can be stored within a code repository such as Subversion or Git. This includes the source code for the connectors and other customizations, the source code for the deployment tools, the configurations files to implement, and the ANT build files used to control the deployment process. This configuration can be treated just like any software development project, and processes such as code review, searching for differences, and migration can be done. Ultimately, a full Software Development Lifecycle (SDLC) process can be implemented around the management of an OIM implementation. Because this deployment process is automated, many if not all of the problems with manually-performed deployments are eliminated.

An automated deployment approach also gives an organization the tools required to make sure their environments are the same. The benefits can be found in small organizations with a lower level and production environments because of the speed of the deployments, to large organizations with multiple lower environments, testing environments and parallel production environments for high availability. Additionally, items deployed via an automated process can easily be replicated to a new environment by simply running the same deployment process. Organizations that have fully automated the deployment process can very easily create a brand new OIM environment.

If you are an organization running into these requirements and the thought of automating these process maybe daunting, work with your implementations partner and ask for any help in implementing such tools. This will allow your staff to spend less time deploying connectors and configurations and reduce the risk of errors that are sometimes found in manual importing and exporting of connectors and configurations. Some implementation partners may have already built such tools, and be able to offer them to you to help jumpstart your efforts. For example, we at Identity Works LLC (http://www.identityworksllc.com) have developed deployment tools that can be used for such implementations.

Share this post