You can configure the API Manager instances to store access tokens in different tables according to their user store domain. This is referred to as user token partitioning and it ensures better security when there are multiple user stores configured in the system. For information on configuring multiple user stores, refer to section Multiple User Store Configuration.
To enable user token partitioning, the <EnableAssertions> and <AccessTokenPartitioning> elements need to be changed in $AM_HOME/repository/conf/identity.xml file.
<EnableAssertions>
Assertions are used to embed parameters into access tokens, so that a strong access token can be generated. Also, those parameters can be used later for further processing functionality. Currently we only have the UserName as assertion as follows.
<EnableAssertions>
<UserName>false</UserName>
</EnableAssertions>
By default assertions are set to false. By setting <UserName> assertion to true, you can add a user name to an access token when generating the key. This can be verified by Base64 decoding the retrieved access token.
<AccessTokenPartitioning>
This parameter implies whether we need to store the keys in different tables or not. It can be used only if <UserName> assertion is enabled. Next, set <EnableAccessTokenPartitioning> to true to store the keys in different tables.
<EnableAccessTokenPartitioning>false</EnableAccessTokenPartitioning>
Also set the user store domain names and mappings to new table names. For example, if userId = foo.com/admin where 'foo.com' is the user store domain name, then a 'mapping:domain' combo can be defined as 'A:foo.com'. 'A' is the mapping for the table which stores tokens relevant to users coming from 'foo.com' user store. In this case, the actual table name is 'IDN_OAUTH2_ACCESS_TOKEN_A'. We use a mapping simply to prevent any issues caused by lengthy tables names when lengthy domain names are used. You need to manually create the tables that going to use for store the access tokens in each user-store (i.e. Tables 'IDN_OAUTH2_ACCESS_TOKEN_A' and 'IDN_OAUTH2_ACCESS_TOKEN_B' should be manually created according to the following defined domain mapping). This table structure is similar to the 'IDN_OAUTH2_ACCESS_TOKEN' table defined in api-manager dbscript (Relevant DB script can be found inside "{AM_HOME}/dbscripts/apimgt" directory).
You can provide multiple mappings separated by commas as follows:
<AccessTokenPartitioningDomains>A:foo.com, B:bar.com</AccessTokenPartitioningDomains>
According to the information given above, change the following section under <APIKeyManager> element in the identity.xml file.
<!-- Assertions can be used to embedd parameters into access token.-->
<EnableAssertions>
<UserName>false</UserName>
</EnableAssertions>
<!-- This should be set to true when using multiple user stores and keys should saved into different tables according to the user store. By default all the application keys are saved in to the same table. UserName Assertion should be 'true' to use this.-->
<AccessTokenPartitioning>
<EnableAccessTokenPartitioning>false</EnableAccessTokenPartitioning>
<!-- user store domain names and mappings to new table names. eg: if you provide 'A:foo.com', foo.com should be the user store domain
name and 'A' represent the relavant mapping of token storing table, i.e. tokens relevant to the users comming from foo.com user store
will be added to a table called IDN_OAUTH2_ACCESS_TOKEN_A. -->
<AccessTokenPartitioningDomains><!-- A:foo.com, B:bar.com --></AccessTokenPartitioningDomains>
</AccessTokenPartitioning>