Page Comparison

...

Note
This feature will be deprecated in Identity Server 5.4.0 release onwards and the recommended approach is using database level table partitioning. Since all commercial databases support table partitioning as a first class feature, it is recommended to use table partitioning to partition required table including IDN_ACCESS_TOKEN table.

You can configure the Identity Server 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 user stores other than the default one, see Configuring Secondary User Stores.

...

Element Description

<EnableAssertions>

Assertions are used to embed parameters into tokens in order to generate a strong access token. You can also use these parameters later for various other processing functionality. At the moment, the Identity Server only supports UserName as an assertion. By default, assertions are set to false in identity.xml file.

Code Block

language	html/xml

<EnableAssertions>
        <UserName>false</UserName>
</EnableAssertions>

You can enable it by setting 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 for 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 <IS_HOME>/repository/conf/identity/identity.xml to store the keys in different tables.

Code Block

language	html/xml

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

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

Code Block

language	html/xml

<AccessTokenPartitioningDomains>A:FOO.COM, B:BAR.COM</AccessTokenPartitioningDomains>

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

Code Block

language	html/xml
title	identity.xml

<!-- Assertions can be used to embedd parameters into access token.-->
<EnableAssertions>
     <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>
     <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. --> 
     <AccessTokenPartitioningDomains>A:foo.com, B:bar.com</AccessTokenPartitioningDomains>
</AccessTokenPartitioning>

Note that, it cannot add mapping for primary user store. So tokens for primary userstore will always stored in IDN_OAUTH2_ACCESS_TOKEN table. And if there there is a secondary user store which don't have a mapping, it use the domain name itself as it mapped alias.

Table creation

Once you configure the file for enable access token partitioning, you can create separate tables to store access tokens. These tables should be created in the database which is pointed in <DataSource> element under <JDBCPersistenceManager> in the identity.xml.

Since the IDN_OAUTH2_ACCESS_TOKEN_SCOPE has a foreign key reference to the IDN_OAUTH2_ACCESS_TOKEN table, when using access token partitioning feature, not only IDN_OAUTH2_ACCESS_TOKEN but also IDN_OAUTH2_ACCESS_TOKEN_SCOPE table should be created per each domain mapping configured in <AccessTokenPartitioningDomains> element.

Suppose, for the user store domain 'foo.com' it has defined the mapping as 'A', then it is needed to create IDN_OAUTH2_ACCESS_TOKEN_A table and IDN_OAUTH2_ACCESS_TOKEN_SCOPE_A table. Refer below example for the mysql script which creates two tables, indexes and relevant constraints:

...

If you are using any other database server, you can use the sql script related to your database server, from sql scripts located at <IS_HOME>/dbscripts/identity/directory. These scripts contains all the tables related to identity data (not specific to this feature). You need to extract queries creating detault IDN_OAUTH2_ACCESS_TOKEN table and IDN_OAUTH2_ACCESS_TOKEN_SCOPE tables and indexes and relevant constraints. Then update table names of two tables, relavent indexes, and relevant constraints to append user store domain mapping as in the above example.

Expand

title	Click here to see how to test this feature,

The following example describes how to test this feature.

Limitations

Since the user store to table mapping is configured as a static mapping in identity.xml, this feature cannot used if you have more user stores getting created at runtime.
All tenants use the same mapping configured as per above configurations, it cannot define mappings differenly for each tenants.

Versions Compared

Old Version 13

New Version 14

Key

<EnableAssertions>

<AccessTokenPartitioning>

Table creation

Limitations