Content Tags.

The content tags (these are not attributes to a tag) specify what is retained in a store. These are

Name Description Tag
adminClients Administrative client store. If the client management endpoint is active, you must have one of these. <adminClients/>
client Registered clients that the service knows about. These should be persisted <clients/>
clientApprovals Approvals for clients. These should be persisted. <clientApprovals/>
permissions Various permissions, such as admin clients have granted to clients they have created or are granted to admin clients by the system. <permissions/>
transactions Transactions that are pending. These are generally short-lived and should not be persisted for extended periods. <transactions/>
txStore Token eXchange token store. Every token that is exchanged is stored here. If you have enabled the token exchange endpoint, you must specify a txStore. <txStore/>
voStore Virtual Organiztion store. Virtual organizations are now available. These allow an admin to create and manage a separate set of issuers etc. for a given group of users. <voStore/>

There is one optional attribute associated with any content tag and this is "tablename". In cases where the underlying store is an SQL store, you may use this to specify the table name, overriding the default. This attribute is ignored by other stores.

Database scripts

These are stored in github on the release page. If you are going to set up database support, then you need to set up your database(s) accordingly. OA4MP is happy having several store sources, but only one store is active (so you can have a few file stores, mysql and postgres instances but only a single client store, single transactions store, etc.

If you are using CILogon (which is an extension of OA4MP that has user support, among other things) then the corresponding scripts are at

It is highly advisable that you carefully read what is there. These scripts are mostly ready to install but do need some configuration and set up (such as installation of the database(s), creating users that will access the databases, etc.)

Example 1.

This puts the client approvals in a file store

<config>
   <service address="localhost">
      <fileStore path="/var/www/store">
         <clientApprovals/>
      </fileStore>
   </service>
</config>

Example 2.

Specifying the table name:

<service name="postgres-config"
         disableDefaultStores="true">
    <postgresql username="bob" password="mairzydoats"  schema="math" database="oa4mp">
       <transactions tablename="transaction2"/>
       <clients tablename="gateways"/>
       <clientApprovals/>
    </postgresql>
    <!-- other stuff -->
</service>

In this example, the default stores are disabled, so if there is some issue with the database configuration, memory stores won't be used, but starting the server will fail. Two of the tables have been created by the administrator with names different than in the default setup.