Try OpenEdge Now
skip to main content
New and Revised Features
11.7 Feature Comparisons : Spring Security Configuration Changes in PAS for OpenEdge
 

Spring Security Configuration Changes in PAS for OpenEdge

The changes in Spring Security configuration in PAS for OpenEdge in the 11.7 release are designed to make the framework more extensible, easier to configure, easier to administer, and easier to maintain from release to release.
These design goals are achieved by the implementation of a new security properties file (oeablSecurity.properties), and a new URL access control file oeablSecurity.csv), Basically, these new files replace configuration of the bean constructor and property settings that you would need to search for in multiple Spring Security XML files. These new "external" properties files are designed to be release independent, to be open to external management, and to provide access to all of the security process functionality in the Spring Security framework.

The security properties file

For some configurations, the new 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
In other cases, a property=value pair replaces a reference to a specific XML configuration file. For example, in 11.6 you would reference the configuration template, /WEB-INF/oeablSecurity-basic-local.xml, in the web.xml file if you wanted to specify basic HTTP authentication using a local users file.
In 11.7, you don't edit the web.xml file, nor do you reference or edit a specific XML file. Instead, basic authentication with a local source for user information is specified by this set of properties in the oeablSecurity.properties file:
http.all.authmanager=local
client.login.model=basic
Note: Some Spring Security XML configuration files have been changed for the 11.7 release. However, the functionality that existed in 11.6 also can be found in 11.7. (The Spring Security XML files have been moved to the WEB-INF/spring directory on the server.) The goal was to refactor the XML files to eliminate the need to edit them directly.
In addition, you should be aware that 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).

URL access control file

The instance-name/webapps/web-app-name/WEB-INF/oeablSecurity.csv file is added in 11.7 to implement URL access controls for web applications. In releases prior to 11.7, URL access controls were defined as intercept-url elements in oeablSecurity-XXXX-XXXX.xml configuration files.
Access control lists, since they are ordered sets of three values, do not lend themselves well to the format of a properties file with its name/value pairs. Therefore, URL access controls were not included in the oeablSecurity.properties file. CSV files are more suitable for access control lists, and they are easily maintainable by many external administrative tools.
The three fields in oeablSecurity.csv file correspond directly with the three attributes of an 11.6 intercept-url element, which are:
*pattern — the URL pattern which can include wildcards and regular expressions
*method — the HTTP access method (optional in 11.6, but required in 11.7)
*access — role[s] that are allowed access to the resource
For example, an intercept-url element would be specified like the following snippet from an 11.6 oeablSecurity-basic-local.xml configuration file:
<intercept-url
pattern="/web/sales/**"
method="GET"
access="hasAnyRole('ROLE_PSCAdmin','ROLE_PSCUser')"/>
The snippet above grants access to any user who has either ROLE_PSCAdmin or ROLE_PSCUser privileges to data from a resource whose URL begins with /web/sales/.
An equivalent entry in the new 11.7 oeablSecurity.csv file looks like the following:
"/web/sales/**", "GET", "hasAnyRole('ROLE_PSCAdmin','ROLE_PSCUser')"
Note: The method (GET in this case) must be specified in the 11.7 oeablSecurity.csv file. Specifying the method was optional in the 11.6 intercept-url elements in the oeablSecurity-XXXX-XXXX.xml files.

See Also

*If you are updating from a previous release, you must migrate your Spring Security configurations to the new properties and CSV files before you can run on 11.7. The process is done after the 11.7 installation, and is automated in the Progress Developer Studio. See OpenEdge Getting Started: Migrating to OpenEdge 11.7 for more information.
*For information about individual properties, see the oeablSecurity.properties.README file.
*For more configuration information, see Progress Application Server for OpenEdge: Administration Guide.