Customizing Policies

All OAuth Toolkit features are implemented using policies in the Policy Manager, making it possible to customize the entire OAuth process.
otk40
All OAuth Toolkit features are implemented using policies in the Policy Manager, making it possible to customize the entire OAuth process.
Understanding Customization 
The CA OAuth Toolkit is installed with default settings. Customization is your configuration of these settings. Some customization is required while other customization is optional. Starting in version 4.0, all customization is performed in the #policies and the extensions located in the Customizations folder.
#Policies
Each editable #policy in the Customizations folder has a target read-only policy in the Policy Fragments folder.
For example, the 
#OTK Variable Configuration
 policy contains customizations for the 
OTK Variable Configuration
 target policy. Customizations are included by reference in the target policy.
Values set in the #policy override default values in the corresponding target policy.
Extensions
Extensions handle more complex configuration. They contain policy logic overrides and are not prefixed with the # character. They may contain assertions to double-click, disabled code to enable, and require flags to be set in the #policy. Open the extension and read the comments for instructions specific to each extension.
For example, the 
OTK User Authentication Extension
 contains both logic and disabled assertions. The extension targets the read-only
 OTK User Authentication
 policy.
Some extensions, such as the 
OTK CORS extension
 contain no code. Configure the extension as described by the documentation within this site.
 
How to Migrate Your Existing Policy Customizations
In previous versions, you configured OTK by editing the default installed policies directly. Custom values for required and optional configuration became part of the installed policies. Performing an upgrade required overwriting your existing policies with new policies containing default configuration. Any customization was lost, unless you installed the latest version with an instance modifier, compared the old and new policies, and manually copied over your customizations.
Starting in version 4.0, your customizations are stored safely outside of the installed default policies and are not overwritten by upgrades.
To migrate your existing pre-4.0 policy configuration into the 4.0 workflow, consider the following strategies:
  • Read through your existing policies and record any custom settings. Install version 4.0 and transfer your custom settings to the #policies and extensions in the new Customizations folder. The documentation on this site provides instructions on how to configure functionality within the Customizations folder. 
  • Consider installing version 4.0 using an index modifier. Your new 4.0 policies will differ considerably from your old. Locate any Context Variables with custom values. For each policy, set these values in the corresponding #policy. 
Upgrading After 4.0
After migrating your customizations to the 4.0 framework, upgrade is easier. When policies in the Policy Fragments folder are replaced to support new features, your customizations remain intact. Your custom values still override default values in the newly upgraded policies. You no longer have to re-enter your hostname and database type, for example.
New features inevitably come with new context variables set to default values. Certain context variables may be deprecated. New logic maybe introduced. You will need to maintain your #policies and extensions to accommodate these changes and provide custom configuration. As always, instructions for configuring new features is documented.