The OAAM extension library documentation is good, but if you're changing and deploying the extension frequently it's nice to have a more repeatable process to follow.  Because of that, I've created a maven project and archetype that can be used to quickly create OAAM extensions using maven. The main reason behind this is typically those extensions that are deployed to OAAM need to be kept in SCM, include other libraries, and need to be built using common build tools. Maven provides a great way to manage dependencies, and quickly build projects. This blog post will cover creating an OAAM

The ARM Automator is a testing tool that has been developed exclusively for testing and simulating login and transaction scenarios using OAAM.  The tool has taken what once was a very difficult and time consuming process and turned it into something that can now be accomplished rapidly and with less headache. Unit testing the OAAM rules have their unique challenges.  The concept of User, Device, and Location seems simple from the outside, but when these three core data points are combined together during rules processing, it can prove for some complicated login use cases that can be nearl

Overview Following along side Pauls post on Introducing testing into your OAAM strategy, OAAM, from the point of view of integrated applications, often behaves like a black box so it makes sense to test the functionality of an OAAM deployment by testing the output for a given functions input against an expected result. In this post I will demonstrate how to use JUnit to unit test some basic OAAM functionality. Areas for Testing OAAM Login and fingerprint functionality Checkpoint functionality and returning Action expectations Transaction logging Specific Rule execution and Trigg

This is a simple example of an OAAM 11g UIO Proxy deployment against a sample application using Apache Http Server as a reverse proxy. It also demonstrates some simple customisation that can be performed on the OAAM server. Our Architecture My local machine running Apache HTTP server. The sample application running on a Ruby server on the company intranet at https://rtms-dev.office.443.corp/ A deployment of OAAM 11.1.1.5 on Oracle Enterprise Linux on the company intranet at http://192.168.1.197:7001/oaam_server/ Local hostname alias I have made en entry in my hosts file so the

Many customers in the US have been asking. How does OAAM address the recent supplement from FFIEC. What controls can be applied to address the specific guidelines explained in the supplement. Well, the customers of OAAM are in luck. OAAM developers have shown again the power of an open framework based approach which can be extended with out a "fork-lift" approach. They have also addressed most, if not all, the guidelines described in the FFIEC suppliment. The following is an attempt to address how security mangers and fraud engineers exploit the vast capabilities of OAAM in their environ

Introduction The approach to customising Authenticators in OAAM 11g is very similar to the 10g approach with some minor differences in which files need to be modified. The main difference in this article is that I will be using a development sandbox to quickly test the Authentipad configuration before deployment. For the sandbox I am using Apache Tomcat 6.0.29 with Java EE 5 SDK. I am using the OAAM 11.1.1.5.0 for the installation files and libraries. Setting Up a Development Sandbox The oaam_libs folder contains a number of packages intended for client deployment of OAAM Authe

When importing and exporting policies from the OAAM CLI, it sometimes useful to be able to see what policies and rules are contained in those policy files. For example if you want to see some information about what is contained in the updated 11g R1 oaam_policies.zip file you could import it into one of your OAAM environments and browse through it. However, I find it more useful to take a look at the policies and rules contained in them before importing. Especially if you are promoting policies from environment to environment. I've created a simple ruby script that will print out the per

When explaining OAAM to others, I always go back to the three main pillars of the product: users, devices, and locations. Users and locations are simple, but devices usually trip clients up from an understanding perspective. A device is something a user uses to login from a location. The process of identifying this device and assigning a 'Device ID' to it is the topic of this post. This process can be broken down into three parts: Data Gathering, Data Processing, and Data Storage. Data Gathering During the login process, data is gathered about a users device to form the device fingerprint.

Since 10.1.4.5, OAAM has had the capability of authenticating web service requests. This was an optional feature that could be turned off by modifying the security constraints in the web.xml file of the OARM deployment in 10.1.4.5. With the release of 11.1.1.3, SOAP authentication remains as a feature, but is managed by OWSM. SOAP User The SOAP authentication is implemented using a username and password. This username and password must be associated with a user that is accesible to the application server. In a WebLogic deployment, this user can be stored and managed within the WebLogic secur

An alternate approach to AJAX fingerprinting using the Prototype Javascript library.