Forgerock WAMulator

The WAM infrastructure has moved away from Oracle Access Manager and is being replaced with Forgerock OpenAM. The WAMulator has been rewritten to work with this new infrastructure.

Previous versions of the WAMulator really were simulators for policy evaluation. The new version is really just a reverse proxy installed on the developer's local machine. This allows for the actual policy evaluation engine in OpenAM to perform evaluation, allowing for the same code to evaluate policies throughout the development and operations cycle.

One wrinkle with this approach is that because exposee uses unique domains and paths to differentiate policies, it is very likely that developers will need to edit their host file to add a unique host for their app (the policies in the wamulator lane can't all be pointed to "localhost").


wamulator.jar allows for the following parameters:

-u Deletes any temp files created by the wamulator and exits
-c config-file Creates the necessary temp files and configuration and starts up the wamulator

Sample call

java -jar wamulator.jar -c my-config.json


The required configuration file has three main sections: wamulator, apps, and users. Below is a sample config file:
	"wamulator": {
		"port": "8081",
		"sslPort": "8443",
		"consolePort": "1776",
		"trafficLogCount": "50"
	"apps": [
			"host": "",
			"target": "http://localhost:9480"
			"host": "",
			"target": ""
	"users": [
			"username": "myTestUser",
			"password": "Th3Password"
			"username": "bobTestUser"


The wamulator section describes some basic configuration options for the wamulator tool--primarily ports. All of these values have defaults and should only be adjusted if needed (e.g. to avoid port conflicts).

Name Description Default Value
port Defines the port that wamulator will listen on. 8081
sslPort Defines the SSL port that wamulator will listen on (typically unused). 8443
consolePort Defines the port of the wamulator console (showing sessions and traffic) 1776
trafficLogCount Specify the number of requests that the wamulator console will record 50


The apps section describes the applications to be protected by wam policies that you will be testing with the wamulator. It is a list of objects, each one of which describes a separate app.

Name Description Default
host The host name that will be protected
target The host name (including port) that the request will be forwarded to after policy evaluation occurs (typically the same as the host with a different port) http://localhost:8080
cookieDomain The domain of the authentication cookie derived from host

Note that you may have to edit your hosts file to add a host that is unique and resolves to localhost.


The users section describes a list of user credentials that will be listed at the bottom of the login screen. Clicking on one of these users will automatically log in as that user. These users must exist in the STAGE lane of IDV and GDIR (There is a process already in place that will automatically sync users that are created in IDV into GDIR).

Name Default
password password1

Note that this WAMulator does not at this time provide a way for generating users that do not exist in DGIR. Additional test users can be generated fairly easily , and future updates to this tool will provide functionality for searching for existing test users, and creating new ones.

Sample WAMulator interaction

This sample assumes the sample config file defined above, and a corresponding policy created through Policy Exposee. Also, there must be an entry in the hosts file for:
url entered into browser:

Since the WAMulator is listening on port 8081, OpenIG intercepts the request and forwards to the OpenAM Wamulator lane, where your policy is evaluated, and a response is returned to your local instance of OpenIG. If the user is authorized based on the policies you have defined, then the request is forwarded to your app.

If the request requires authentication, the user will be redirected to the sign-in page. If the wamulator has been setup with usernames, those will appear below the login button:


Clicking on any of the usernames listed will trigger a login for that user. The user can also use the username and password fields to sign in to an account normally.

Once the user has successfully authenticated, the request is checked against the policy (as configured in the wamulator lane of exposee). If that succeeds, the request will be forwarded to the application and appropriate headers will be injected.

Traffic logs detailing these intermediate requests and responses are generated and available on your local WAMulator console page (


Clicking on the "Requested path" will actually bring up the corresponding log file showing the entire request and response, with associated headers.

This page was last modified on 21 December 2016, at 12:45.

Note: Content found in this wiki may not always reflect official Church information. See Terms of Use.