This documentation is for WSO2 API Manager 1.4.0 View documentation for the latest release.
Page Comparison - Saving Access Tokens in Separate Tables (v.3 vs v.4) - API Manager 1.4.0 - WSO2 Documentation

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 that stores tokens relevant to users coming from 'foo.com' user store.

...

According to the information given above, change the following section under the <APIKeyManager> element in the identity.xml file .as shown in the following example:

Code Block
languagehtml/xml
titleidentity.xml
<!-- 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>

...