This documentation is for WSO2 API Manager 1.5.0 View documentation for the latest release.
Page Comparison - Saving Access Tokens in Separate Tables (v.4 vs v.5) - API Manager 1.5.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 domaindomains. This is referred to as as user token partitioning and  and it ensures better security when there are multiple user stores configured in the system. For information on configuring To configure user stores other than the default one, see Configuring Secondary User Stores.

To The following topics explain how to enable user token partitioning, you should change the <EnableAssertions> and <AccessTokenPartitioning> elements in <APIM_HOME>/repository/conf/identity.xml file.

...

Table of Contents

Enabling assertions
Anchor
EnableAssertions
EnableAssertions

Assertions are used You use assertions to embed parameters into tokens in order to and generate a strong access token. You can also use these parameters later for various other processing functionality. At the moment, the API Manager only supports UserName as an assertion.

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

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

You can make it true by setting <UserName> element to To enable it, set the <UserName> element to true. You can add a user name to an access token when generating the key, and verify it by Base64-decoding encoding the retrieved access token .

<AccessTokenPartitioning>

This parameter implies whether you need to store the keys in different tables or not. It can be used only if <UserName> assertion is enabled. If it is, set the <EnableAccessTokenPartitioning> element to true in with Base64.

Code Block
languagexml
title<APIM_HOME>/repository/conf/identity.xml
<EnableAssertions>
        <UserName>true</UserName>
</EnableAssertions>

Storing keys in different tables

  1. If the <UserName> assertion is enabled, set the <EnableAccessTokenPartitioning> element in <APIM_HOME>/repository/conf/identity.xml file to true. It determines whether you want to store the keys in different tables or not. 

    Code Block
    language

...

  1. xml
    <EnableAccessTokenPartitioning>true</

...

  1. EnableAccessTokenPartitioning> 

...

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

...

  1. is IDN_OAUTH2_ACCESS_TOKEN_A

...

  1. . We use a mapping simply to prevent any issues caused by lengthy

...

  1. table names when lengthy domain names are used. You

...

  1. must manually create the tables you are going to use to store the access tokens in each user

...

  1. store (i.e.,

...

  1. manually create the tables IDN_OAUTH2_ACCESS_TOKEN_A

...

  1.  and IDN_OAUTH2_ACCESS_TOKEN_B

...

  1.  according to the following defined domain mapping). This table structure is similar to

...

  1. the IDN_OAUTH2_ACCESS_TOKEN

...

  1.  table defined in the api-manager dbscript, which is inside

...

  1. the <APIM_HOME>/dbscripts/apimgt

...

  1.  directory

    You can provide multiple mappings separated by commas as follows. Note that the domain names need to be specified in upper case.

    Code Block
    languagehtml/xml
    <AccessTokenPartitioningDomains>A:FOO.COM, B:BAR.COM</AccessTokenPartitioningDomains>
  2. According to the information given above, change the 

...

  1. <OAuth> element in the <APIM_HOME>/repository/conf/identity.xml

...

  1.  file as shown in the following example:

    Code Block
    language

...

  1. xml
    title<APIM_HOME>/repository/conf/identity.xml
    <!-- Assertions can be used to 

...

  1. embed parameters into access token.-->
    <EnableAssertions>
         

...

  1. <UserName>true</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>
         

...

  1. <EnableAccessTokenPartitioning>true</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. --> 
         

...

  1. <AccessTokenPartitioningDomains>A:foo.com, B:bar.

...

  1. com</AccessTokenPartitioningDomains>
    </

...

  1. AccessTokenPartitioning>