Free trial

Automated installation and configuration of OpenAM

This blog is about automation of OpenAM architecture installation and configuration. As I recently automated architecture from my previous article [1] (simplified without using SSL), I would like to say something about issues I met.

All automation I did was in shell script, using also some basic tools like sed. As I wanted to keep it simple, I avoided usage of any non-standard tools like expect, that would have to be installed explicitly. This article is not step-by-step cookbook, how to automate complete OpenAM deployments. Instead, it provides tips and points out challenges for the automation.


For JDK there are two things to point out – one is that Sun JDK is unpacked to directory from which you run it, so you have to first go to this directory and then call installer binary. Second thing is that you need to press enter at the end of installation, this can be done by redirecting echo command without any parameters:

echo | ${INST_DIR}/jdk-6u26-linux-x64.bin


For OpenDJ, the same as for graphical installation, you first have to copy OpenDJ to a directory, where you want to have it installed. There is no installation, setup command would only configure it. When you call setup without parameters, GUI setup is launched. To use CLI setup, there is also option to use –cli parameter, then you will be asked for every settings on console. And there is another way, most suitable for automation, to pass all setup value as parameters:

./setup -n -h -p 1389 --adminConnectorPort 4444 
  -D "cn=Directory Manager" -w "dsmanager" -b dc=example,dc=com -a -i


For GlassFish setup, you have to accept CDDL license, to automate this you can also use echo command, echoing A as accept:

echo A | ${JAVA_HOME}/bin/java -Xmx256m -jar 
  ${PKG_DIR}/glassfish-installer-v2.1.1-b31g-linux.jar -console

Setup part running ant script is trivial (setting executable permision on ant and running ant script).

Next thing to do in GlassFish is to create domain. One non-trivial thing there is, how to pass password to asadmin command. There is a special password file for this, containing 2 lines, on one is a domain admin password and on other a master password:


When password file is ready, you can create domain just by running asadmin create-domain command with correct parameters:

./asadmin create-domain --domaindir ${INST_DIR}/glassfish/domains 
  --adminport 8989 --instanceport 1080 --user domain2adm 
  --passwordfile /tmp/domain.pwd oamdomain

Domain setup (modifying domain.xml) can be done easily using sed command:

sed "s/-client/-server/" -i domain.xml
sed "s/-Xmx512m/-Xmx1024m/" -i domain.xml


To deploy OpenAM to GlassFish you have to use asadmin deploy command, you just need to pass correct parameters, including password file that you already used to create a domain:

./asadmin deploy --user domain2adm --host --port=8989 
  --contextroot opensso --name opensso --target server --passwordfile 
  /tmp/domain.pwd ${PKG_DIR}/opensso/deployable-war/opensso.war

To setup OpenAM, you have to use ssoConfiguratorTools. They are provided as part of OpenAM, however they are not installed by default. You need to unzip file to a place, from where you want to run it later. All the setup should be prepared in one config file first, you can find more details here [3]. In my case, configuration file is:


DS_DIRMGRDN=cn=Directory Manager

USERSTORE_MGRDN=cn=Directory Manager

When you have your configuration file prepared, you have to pass it to configurator:

java -jar configurator.jar -f /tmp/oam.conf

OpenAM Configuration

Now when OpenAM setup is done, there comes most important part of this article – OpenAM configuration. In this part, I try to explain how to configure parts that you typically do via web browser using Admin Console. One option here is to simulate web browser using various tools, however this is not what I wanted. OpenAM brings ssoAdminTools package, that gives you command line tool to work with OpenAM configuration. I already shown some example how to use it in my article How to upgrade OpenAM [2].

As I explained in upgrade article, installation of Admin Tools is a bit tricky. First you have to unzip to directory where you want to have it installed, and then run setup script and pass there your existing OpenAM configuration directory. Also you have to provide log and debug directory (that would be created):

./setup -p /opt/oam-config -d /opt/oam-debug -l /opt/oam-log

One more thing for ssoadm to prepare is password for amadmin user, this password should be stored in a file, that should not be readable by other users:

echo oamadmin > /tmp/amadmin.pwd
chmod 400 /tmp/amadmin.pwd

Now all important settings to use ssoadm command are done. Usage of this command is not trivial, I found 3 usefull pages related to this, one is ssoadm command line reference [4] that contain list of all ssoadm commands and parameters (without any explanation of usage), and other is about Scripting an OpenAM deployment [5], that contains some simple example of usage, however it is not usable as a general guide. A list of attributes [6] is also helpful.

For many things I had just to use Google to find how other people solve issues that I had.

Now I would proceed with settings that I did manually in [1], explaining step-by-step how to do it using ssoadm.

Access Control -> / (Top Level Realm)

  • Realm Attributes -> New Value:

There are two subcommands of ssoadm, to get realm settings, one is get-realm to get realm property values, and other is get-realm-svc-attrs to get realm’s service attribute values. Both of them require from you to know exactly which property/attribute you would like to get.

I haven’t found any command how to list realm property values, and this is just what I needed to add this setting. Only what I found was listing of realm’s services:

./ssoadm show-realm-svcs -u amadmin -f /tmp/amadmin.pwd -e /


It didn’t  help me much, but I found some help in OpenAM mailing list archive [8]. Command to add this new value to Sun Organization Aliases is:

./ssoadm set-realm-attrs -u amadmin -f /tmp/amadmin.pwd -e / 
  -s sunIdentityRepositoryService 
  -p -a

Attribute -a means, that value is appended to existing aliases, and old values are not lost.

Access Control -> / (Top Level Realm) -> Data Stores -> OpenDS

  • LDAP Groups container Naming Attribute : ou
  • LDAP Groups Container Value: groups
  • LDAP People Container Naming Attribute : ou
  • LDAP People Container Value: users

There is one easy and recommended way how to do it, however this way would not work correctly. This way is to use show-datastore subcommand to get data store configuration file, then modify this file and update it back, or as in [5] to create new data store based on original one.

Command to get existing configuration is:

./ssoadm show-datastore -u amadmin -f /tmp/amadmin.pwd -e / -m OpenDS > 

And why this wouldn’t work – because of a simple reason, one of property in this file is:


If I modify this configuration file and run ssoadm update-datastore, it would modify also password and OpenAM would not be able to connect to a directory server.

However, from a file that I get, I am able to get properties that I need and modify them to values I want. Then it is enough to update only those values. So in my case I prepared datastore configuration file with these values:


And then I called ssoadm update-datastore with this configuration file:

./ssoadm update-datastore -u amadmin -f /tmp/amadmin.pwd -e / -m OpenDS 
  -D /tmp/datastore.conf

Access Control -> / (Top Level Realm) -> Subjects

  • Test User1 is displayed

This part is easy:

./ssoadm list-identities -u amadmin -f /tmp/amadmin.pwd -e / -t User 
  -x TestUser1

testuser1 (id=testuser1,ou=user,dc=example,dc=com)
Search of Identities of type User in realm, / succeeded.

However I haven’t found any simple way how to list all accessible users, it only works when I know users name. Also, difficult part there was that at first I was not able to find any user there, because of rewritten password in data store, that I mentioned above. But when I updated only selected properties (from original configuration), user is listed.

Access Control -> / (Top Level Realm) -> Authentication -> All Core Settigns…

  • User Profile: Ignored

For this setting, there is needed to set a correct attribute for correct service. Name of service and attribute can be found here [7]:

So the final command is:

./ssoadm set-realm-svc-attrs -u amadmin -f /tmp/amadmin.pwd -e / 
  -s iPlanetAMAuthService 
  -a iplanet-am-auth-dynamic-profile-creation=ignore

Access Control -> / (Top Level Realm) -> Agents -> Web -> Agent -> New…

  • Name: webagent
  • Password: webagent
  • Re-Enter Password: webagent
  • Configuration: Centralized
  • Server URL:
  • Agent URL:
  • Create

To create a Web Agent, there is a subcommand create-agent, with all required parameters:

./ssoadm create-agent -u amadmin -f /tmp/amadmin.pwd -e / -b webagent 
  -t WebAgent -a userpassword=webagent 
  -s -g

Parameter -b is to set webagent name, -a userpassword is to set its password (see that -a means attribute, and value is added there using = character), -s is to set OpenAM Server URL and -g is to set Agent URL. One special parameter is -t and it is used to set a type of an agent. However, I was not able to find the list of values that can be used there, and for example for 2.2 agent, I was not able to find a way how to create it.

You can also verify whether agent is created correctly using subcommand show-agent:

./ssoadm show-agent -u amadmin -f /tmp/amadmin.pwd -e / -b webagent

Access Control -> / (Top Level Realm) -> Policies -> New Policy…

  • Name: Protected Resource 1

Rules -> New…

Step 1 of 2: Select Service Type for the Rule

  • Service Type: URL Policy Agent (with resource name)
  • Next

Step 2 of 2: New Rule

  • Name: URL Rule – HTTPS
  • Resource Name:*
  • GET: check, Allow
  • POST: check, Allow
  • Finish

Rules -> New…

Step 1 of 2: Select Service Type for the Rule

  • Service Type: URL Policy Agent (with resource name)
  • Next

Step 2 of 2: New Rule

  • Name: URL Rule – HTTP
  • Resource Name:*
  • GET: check, Allow
  • POST: check, Allow
  • Finish

Subjects -> New…

Step 1 of 2: Select Subject Type

  • Type: OpenAM Identity Subject
  • Next

Step 2 of 2: New Subject – OpenAM Identity Subject

  • Name: Test Subject
  • Filter: User
  • Search
  • In available list you should see available user, Add testuser1.
  • Finish

Policies are a bit tricky to create. There are too many properties to set and settings are structured, so there is used XML format for that. The easiest way how to get this its structure is to create some policy manually using Admin Console (via web browser), and then export this policy using ssoadm – this part is not to automate, it’s just preparation for automation.

./ssoadm list-policies -u amadmin -f /opt/oam.pwd -e / -o /tmp/policies

In my case, output looks like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Policies
PUBLIC "-//OpenSSO Policy Administration DTD//EN"

<!-- extracted from realm, / -->
<Policy name="Protected Resource 1" 
  creationdate="1325829744460" lastmodifieddate="1325829744460" 
  referralPolicy="false" active="true" >
<Rule name="HTTP">
<ServiceName name="iPlanetAMWebAgentService" />
<ResourceName name="*" />
<Attribute name="POST" />
<Attribute name="GET" />
<Rule name="HTTPS">
<ServiceName name="iPlanetAMWebAgentService" />
<ResourceName name="*" />
<Attribute name="POST" />
<Attribute name="GET" />
<Subjects name="Subjects:1325829665266Qs738aE=" description="">
<Subject name="Test Subject" type="AMIdentitySubject" includeType="inclusive">
<AttributeValuePair><Attribute name="Values"/>

The structure is easy to read, and when you know the format, you can easily prepare your own policies. In this case I kept there also link to SSL Web Server instance, to show how there can be 2 rules in one policy. When you have your policies prepared in XML file, you just need to import them to OpenAM using create-policies subcommand:

./ssoadm create-policies -u amadmin -f /opt/oam.pwd -e / -X /tmp/policies

Sun Web Server

For Sun Web Server, there is possible to use silent install, but you need to have prepared a state file containing the configuration, and pass this file to an installer. One way how to get this file is to do manual installation first, using savestate parameter:

./setup --savestate

In my case, state file looks like this:

[STATE_BEGIN Sun Java System Web Server cd1882504a4a1bc91210ec402c269d9e7ded29b4]
defaultInstallDirectory = /sun/webserver7
currentInstallDirectory = /opt/ws7
UPGRADE = false
SELECTED_COMPONENTS = svrcore,admincli
ADMIN_UID = profiq
ADMIN_NAME = admin
ADMIN_PASSWD = web4dmin
WEB_PORT = 8080
WEB_UID = profiq
[STATE_DONE Sun Java System Web Server cd1882504a4a1bc91210ec402c269d9e7ded29b4]

You can intuitively find out, which property means what, so if you know the format, you can just take existing state file, edit it to your values and use it, without doing manual installation to get it.

Installation with state file is simple:

./setup --silent /tmp/wsstatefile

OpenAM Web Agent

As I used Sun Web Server, I used also OpenAM Web Agent for Sun Web Server. This web agent is provided in a zip file, that is again not directly installable, it should be just unzipped and then called agentadmin to set it up.

There is one little trick for an automation. Before installation starts, you are asked to answer yes on an license agreement. I tried to send there yes using echo and pipe, however it didn’t work for me, so I used small workaround. I found out, that this license is checked using file web_agents/sjsws_agent/data/license.log, so before installation started, I prepared content of this file to look as license was already agreed:

echo "profiq=01/15/2012 04:52:07 CET" > 

When this is set, I’m not asked to confirm license agreement anymore and installation can be automated.

Silent installation of OpenAM Web Agent is very similar to silent installation of Web Server, you need a state file and you can get it by proceeding manual installation with saveResponse parameter, or you can create it by yourself when you know the format.

To get a state file using manual installation use this command:

${INST_DIR}/web_agents/sjsws_agent/bin/agentadmin --install 
  --saveResponse /tmp/wastatefile

In my case, state file looks like this:

CONFIG_DIR= /opt/ws7/
AGENT_PASSWORD_FILE= /tmp/webadmin.pwd

With state file, silent installation is proceeded by this command:

${INST_DIR}/web_agents/sjsws_agent/bin/agentadmin --install 
  --useResponse /tmp/wastatefile

And that’s all, when you automated all steps from [1] correctly, you can try to connect to Web Server, and you should get OpenAM login page, and after successful login Web Server default page – the same results as if all was installed and configured manually.
[1] How to install and configure OpenAM Web Policy Agent

[2] How to upgrade OpenAM

[3] OpenAM – Configurator Parameters

[4] ssoadm command line reference

[5] Scripting an OpenAM deployment

[6] Authentication Attributes

[7] Authentication Attributes – Core

[8] [OpenAM] New DNS Alias for Top Level realm

agent automation forgerock openam

7 Responses to “Automated installation and configuration of OpenAM”

  1. rubendob says:


    I don’t know if I double post the same question, excuse me!

    I want to automate my openam setup. I have a weird problem when I try to backup the policies with ssoadm

    ./ssoadm list-policies -u amAdmin -f /tmp/pwd.txt -e / -o /tmp/policies.txt


    this is the only error that ssoadm gives to me, then If I check the error log of ssoadm I see:

    “”2014-07-21 09:10:22” /|com.miimetiq.identity.policy.RoleCondition id=amAdmin,ou=user,dc=openam 5753f489d4161201 “Not Available” INFO dc=openam “cn=dsameuser,ou=DSAME Users,dc=openam” AMCLI-2442 ssoadm.error”Not Available”″

    Do you have any idea what is this error? anything related with dns settings of the domain maybe?

    output of /etc/hosts localhost
    # test test

    Domain of openam is in my scenario:

    Any help will be appreciated.


    • N4A L says:


      It’s not easy to tell without having a better look into the setup, however we can provide some pointers where to look for the cause of the problem. The first place I’d look is the debug directory of ssoadm tool. It should be located in the same directory where you unzipped the (as the matter of fact, once you execute setup script, it will ask you for the location where you want to place your debug directory). Another place to look is OpenAM debug directory which is usually: $BASEDIR/openam/openam/debug. Note that you might have to increase the debug level for OpenAM to get more information.
      Another aspect to have in mind is that you should use the ssoadm tool which came in your OpenAM zip. That is, versions of ssoadm and OpenAM should match otherwise you might get strange results.

      • rubendob says:

        Hi N4A L

        Firstable thanks for reply!

        After two days of debug and making test finally I know what’s going on. One partner of the team, the chief developer is the owner of the openam rules. He design the policies and in some of them he needs a “Condition”. Can be Role Condition, URL Condition, etc.

        Then, if any of these policies contains some of Condition, ssoadm returns and error.

        I double check that. At the beginning I thought was a permission problem but later I have noticied even with

        URL Condition

        it is the same behaviour.

        So by now I have recreated all policies without conditions and export to xml file to be able to advance a little the automation. Anyway it’s weird. Do you have any idea?

        About version of ssodam tool yes, there are the same version. (11.0)

        Best Regards,


        • N4A L says:

          I have tried to reproduce this issue as you described, but in my environment (OpenAM 11.0.0 with default configuration and embedded OpenDJ) it works fine even for policies with conditions. Since your configuration could have some additional customisations I can suggest that you drop an e-mail to OpenAM mailing list with as many details as possible such as:
          – OpenAM version, where do you have configuration store and where data store;
          – LDAP directory that you use (ODSEE, OpenDJ, AD, etc.);
          – the exceptions reported by OpenAM and ssoadm;
          – steps to reproduce.

          The reason why I am mentioning the mailing list is first because in order to troubleshoot your problem we need more information and blog comments are not really the most apropriate place to share this kind of information, so I am basically saying to continue this chat over there; and second on the mailing list there are more people which might have a good guess what the problem is and jump in to help. In case this is a real problem (and not an configuration issue), that is, a bug, it will be properly addressed by OpenAM developers if they get to evaluate it through the list.

  2. rubendob says:


    I was finally able to resolve the problem. If you are interested:

    I have continued reading your tutorial and I have one question. How difficult is to create a user under Subject Tab with ssoadm? I have been revising parameters but… I did not find just how to set up the password of the user.


  3. rubendob says:


    I did it 🙂

    ./ssoadm create-identity -u amadmin -f /tmp/pwd.txt -e / -i Test -t User –attributevalues “userpassword=mysecret”


  4. OpenAM: some ssoadm commands for reference | says:

    […] Automated installation and configuration of OpenAM […]

Leave a Reply

Related articles


Let’s make LLMs generate JSON!

In this article, we are going to talk about three tools that can, at least in theory, force any local LLM to produce structured output: LM Format Enforcer, Outlines, and Guidance. After a short description of each tool, we will evaluate their performance on a few test cases ranging from book recommendations to extracting information from HTML. And the best for the end, we will show you how forcing LLMs to produce a structured output can be used to solve a very common problem in many businesses: extracting structured records from free-form text.

Notiondipity: What I learned about browser extension development

Me and many of my colleagues at profiq use Notion for note-taking and work organization. Our workspaces contain a lot of knowledge about our work, plans, or the articles or books we read. At some point, a thought came to my mind: couldn’t we use all this knowledge to come up with project ideas suited to our skills and interests?

From ChatGPT to Smart Agents: The Next Frontier in App Integration

It has been over a year since OpenAI introduced ChatGPT and brought the power of AI and large language models (LLMs) to the average consumer. But we could argue that introducing APIs for seamlessly integrating large language models into apps developed by companies and independent hackers all over the world can be the true game changer in the long term. Developers are having heated discussions about how we can utilize this technology to develop truly useful apps that provide real value instead of just copying what OpenAI does. We want to contribute to this discussion by showing you how we think about developing autonomous agents at profiq. But first a bit of background.