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.2 vs v.3) - API Manager 1.4.0 - WSO2 Documentation

Versions Compared

Key

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

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, you should change the <EnableAssertions> and <AccessTokenPartitioning> elements need to be changed in $AM<APIM_HOMEHOME>/repository/conf/identity.xml file.

<EnableAssertions>
Anchor
EnableAssertions
EnableAssertions

Assertions are used to embed parameters into access tokens, so that tokens in order to generate 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. You can also use these parameters later for various other processing functionality. At the moment, API Manager only supports UserName as an assertion.

By default, assertions are set to false in <APIM_HOME>/repository/conf/identity.xml.

Code Block
languagehtml/xml
<EnableAssertions>
        <UserName>false</UserName>
</EnableAssertions>

By default assertions are set to false. By setting <UserName> assertion to true, you You can make it true by setting <UserName> element to true. You can add a user name to an access token when generating the key. This can be verified , and verify it by Base64-decoding the retrieved access token.

...

This parameter implies whether we you need to store the keys in different tables or not. It can be used only if <UserName> assertion is enabled. NextIf it is, set the <EnableAccessTokenPartitioning> element to true in <APIM_HOME>/repository/conf/identity.xml to store the keys in different tables.

Code Block
languagehtml/xml
<EnableAccessTokenPartitioning>false<<EnableAccessTokenPartitioning>true</EnableAccessTokenPartitioning>

Also set the user store domain names and mappings to new table names. For example,

...

  • 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.

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 you are going to use for to store the access tokens in each user-store (i.e. Tables , 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}, which is inside <AMIM_HOME>/dbscripts/apimgt " directory)

You can provide multiple mappings separated by commas as follows:

...