The oeablSecurity.properties file can exist in three-tiered hierarchy so that you can:
1. Configure properties that are used for all ABL applications deployed on the instance by setting properties in instance-name/conf/oeablSecurity.properties. The defaults established in this file can be overridden by properties set in an ABL application ( #2) or a web application (#3).
2. Configure properties that are used for ABL applications by setting properties in instance-name/ablapps/abl-app-name/oeablSecurity.properties. Property settings in this file override the server instance defaults (#1).
Note: This level is optional. It is useful when you have more than one ABL application deployed on an instance and when those ABL applications require different security configurations.
3. Configure properties for a specific web application in an ABL application by setting properties in instance-name/webapps/web-app-name/WEB-INF/oeablSecurity.properties. Property settings in this file override the server instance defaults (#1) and the ABL application defaults (#2).
The Spring Security properties and their values are documented in the oeablSecurity.properties.README file.
For some properties, the oeablSecurity.properties file employs a naming convention (bean-name.property=value) that simplifies the identification of a bean and its properties. For example:
OEClientPrincipalFilter.sealAnonymous=false
Beginning with the OpenEdge 11.7 release, property=value pairs replace references to specific XML security model configuration files. For example, if you want to specify basic HTTP authentication using a local users file you would specify this set of properties in oeablSecurity.properties:
Prior to the OpenEdge 11.7 release, you would have to have to sort through a number XML templates to find one that matches the required security model, update it, and reference it from the web.xml file.
