PAS for OpenEdge resolves authentication property settings by loading multiple oeablSecurity.properties files and using the first declared value it finds. The layered Spring Security property files are loaded in the following order:
  1. instance-name/webapps/web-app-name/WEB-INF/oeablSecurity.properties
    • Properties and values applied to the web application
    • Matches the deployment configuration and supersedes the property values defined in instance-name/conf/openedge.properties
    • Can contain all or a subset of Spring Security properties
  2. instance-name/ablapps/abl-app-name/conf/oeablSecurity.properties
    • Defaults applied to all web applications within a single ABL application
    • Matches the deployment configuration and supersedes the property values defined in instance-name/conf/openedge.properties
    • Can contain all or a subset of Spring Security properties
  3. instance-name/conf/oeablSecurity.properties
    • Superset of Spring Security properties
    • Defaults applied to all web applications across all deployed ABL applications

Out of the box, the authentication mode of the production instance is set to anonymous, which is the lowest security level. The security level is set minimally because it is impossible to foresee which authentication implementation you require. Before running and deploying business applications to a production instance, increase the security level by enabling authentication in the staging environment.

The Spring Security framework, which is an integral part of PAS for OpenEdge, is adaptable to a wide variety of authentication models and architecture.

To enable authentication on a production instance:
  1. Open the oeablSecurity.properties file at the security layer that you want to work on:
    • instance-name/webapps/web-app-name/WEB-INF/oeablSecurity.properties
    • instance-name/ablapps/abl-app-name/conf/oeablSecurity.properties
    • instance-name/conf/oeablSecurity.properties
  2. Set the login model for the client.login.model property. The following HTTP client authentication login models are supported:
    Login model Description
    anonymous The default. All clients have public access. No direct logins or single sign-on (SSO) are allowed.
    basic Users authenticate using the HTTP BASIC header direct logins and SSO headers.
    form Users authenticate using a HTTP POST message and form data for direct login and SSO headers.
    container Users authenticate through the Tomcat realm services and authorize URL access using Spring Security.
    sso Users authenticate using CLIENT-PRINCIPAL access token through the OpenEdge SSO.
    oauth2 URLs are authorized through OpenEdge by validating OAuth2 JSON Web Tokens. For more information, see Authenticate using OAuth2 and JWT.
    saml Users authenticate and authorize using SAML tokens. For more information, see Authenticate using SAML.
    You can customize the Spring login process by modifying the associated <type>LoginModel.xml. Create a local copy of the $CATALINA_HOME/common/spring/<type>LoginModel.xml in the $CATALINA/webapps/<oeabl.webapp.name>/WEB-INF/spring directory. For more information on customization, see the Spring documentation.
    Note: Add a migration task to review any customizations after upgrading Spring versions for any Spring updates.
  3. Select the user account source for the http.all.authmanager property. The following user account sources are supported:
    User account source Description
    local The source is web application WEB-INF/users.properties with clear-text passwords. For more information, see About local and extended local user accounts.
    extlocal The source is the application WEB-INF/users.properties with encrypted passwords. For more information, see About local and extended local user accounts.
    ldap The source is a simple LDAP (or Active Directory) server configuration. For more information, see About LDAP user accounts.
    oerealm The source is a bridge to the ABL application-maintained user accounts. For more information, see OERealm user account configurations.
    ad The source is a simple (constrained) Active Directory configuration. For more information, see About Active Directory user accounts.
    sts The source is the OpenEdge Authentication Gateway client.

    For more information, see the OpenEdge Authentication Gateway Guide.
  4. Update the default ABLDomainRegistry.keystore to include your domain name and domain access code:
    1. Design the OpenEdge domain name space to be used by the ABL application or instance, and assign a domain access code (DAC) to each domain name.
    2. Create an ABLDomainRegistry.csv file with domain names and clear-text DAC pairs, one pair per line. Domain names and DACs are separated by a comma, for example:
      domain-name,clear-text-DAC
    3. Use the GENDOMREG utility to create an encrypted Java keystore file from the CSV file, for example:
      $DLC/bin/gendomreg ABLDomainRegistry.csv ABLDomainRegistry.keystore
    4. Copy the encrypted Java keystore file to the .../conf directory of each PAS for OpenEdge instance. Delete or override the default keystore.
      Note: If you use a non-default name for the keystore file, then change the .registryFile property in the oeablSecurity.properties file to the non-default keystore name.
    5. Design the role name pattern to designate an OpenEdge domain. For more information, see Obtain a domain name from a role name.
    6. After you establish a role name pattern, construct the Java regular expression (regex) pattern that distinguishes the domain name from any other normal user account granted roles.
    7. Set the OEClientPrincipalFilter bean's domainRoleFilter property to the value of the Java regex match pattern.
    8. If it is required by your security practice, set the OEClientPrincipal.validateClientDomain property in the oeablSecurity.properties to true. The OEClientPrincipal.validateClientDomain property is a Boolean value. When the value is set to true and when there is a domainRoleFilter defined, the property compares the domain specified by the client to the domain produced by the domain role filter. If the domains do not match, then the client request is rejected.
Note: Changing the oeablSecurity-*.xml file from local to another user account source, or adding and changing the users and passwords is not handled by the “local” ~/conf/tomcatusers.xml file. You must modify the oeablSecurity*.xml file to access your authentication service.