There are two remaining components here:

1. aaa-datastore-config.xml things, which specify how the datastore should be set up. There are two parts to this:
   1. The fact we should use H2Datastore. This feels like we should just use whatever advertizes itself as IIDMStore, though.
   2. The lifecycle policy, time-to-live and time-to-wait, which feels like something common to all uses of IIDMStore
2. aaa-app-config.xml things, which relate to the actual policy. There are mutliple parts to this:
   1. ldapRealm configuration, commented out by default
   2. ODLActiveDirectoryRealm, commented out
   3. jdbcRealm, commented out
   4. mdsalRealm, commented out
   5. moonAuthRealm, commented out
   6. keystoneAuthRelam, commented out
   7. tokenAuthRealm, active by default, and the only one referenced
   8. url policy, which has four parts:
      1. global policy, as expressed by /**
      2. (what I suspect is) neutron access policy, as expressed by /**/v1/**
      3. AAA configuration policy, as expressed by /**/config/aaa/**. This I suspect is meant to cover RESTCONF modification of AAA configuration – and that is broken by RFC8040 URL format for a looooong time
      4. Access to controller's sal-cluster-admin, as expressed by /**/operations/cluster-admin**. This also is tightly bound to how RESTCONF URLs work

This points out at least 10 more subtasks to deal with the individual cases.

The 1.* cases seem like an easy first pick.

The 2.* cases really feel like a missing modeling indirection. While the versatility of aaa-app-config:string-pair is awesome for expressing any Shiro configuration the tie-in to what the OpenDaylight components provide/require is lackluster at best. The realms seam to be easy (pending further analysis), but the URL policy part should really follow the whiteboard pattern, which needs to be reflect in code – they clearly are things that plug into AAA.