By default, assertions are set to
false in the
<APIM_HOME>/repository/conf/identity/identity.xml. 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 encoding the retrieved access token with Base64.
<EnableAssertions> <UserName>true</UserName> </EnableAssertions>
<UserName>assertion is enabled, set the
true. It determines whether you want to store the keys in different tables or not.
Code Block language xml
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 the '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 table names when lengthy domain names are used. You must manually create the tables you are going to use to store the access tokens in each user store (i.e., manually create the tables
IDN_OAUTH2_ACCESS_TOKEN_Baccording to the following defined domain mapping). This table structure is similar to the
IDN_OAUTH2_ACCESS_TOKENtable defined in the api-manager dbscript, which is inside the
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
According to the information given above, change the
<OAuth>element in the
<APIM_HOME>/repository/conf/identity/identity.xmlfile as shown in the following example:
Code Block language xml title <APIM_HOME>/repository/conf/identity/identity.xml
<!-- Assertions can be used to embed 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>