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/webapp-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.

Before running and deploying business applications to a production instance, you should increase the security level by enabling authentication in a staging environment. 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 might require.

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, perform the following steps:
  1. Open the oeablSecurity.properties file at the security layer you require:
    • instance-name/webapps/webapp-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 spring.login.model . 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) 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 via Tomcat realm services and authorize URL access via Spring Security.
    sso OpenEdge SSO using ClientPrincipal access tokens. No direct login – only SSO headers.
    oauth2 OpenEdge support for validating OAuth2 JWT tokens for URL authorization. For more information, see Authenticate using OAuth2 and JWT .
    saml Users authenticate and authorize using SAML token. For more information, see Authenticate using SAML.
    You can customize the Spring login process using the associated <type>LoginModel.xml. Edit the $CATALINA_BASE/webapps/ROOT/WEB-INF/spring/<type>LoginModel.xml. 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 http.all.authmanager . The following user account sources are supported:
    User Account Source Description
    local

    Source is web application WEB-INF/users.properties with clear-text passwords. For more information, see Local and Extended Local user accounts in Manage Progress Application Server (PAS) for OpenEdge.
    extlocal

    Source is the application WEB-INF/users.properties with encrypted passwords. For more information, see Local and Extended Local user accounts in Manage Progress Application Server (PAS) for OpenEdge.
    ldap

    Source is simple LDAP (or Active Directory) server configuration. For more information, see LDAP user accounts in Manage Progress Application Server (PAS) for OpenEdge.
    oerealm

    Source is a bridge to ABL application maintained user accounts. For more information, see OERealm user account configurations in Manage Progress Application Server (PAS) for OpenEdge.

    ad

    Source is a simple (constrained) Active Directory configuration. For more information, see Active Directory user accounts in Manage Progress Application Server (PAS) for OpenEdge.
    sts

    Source is the OpenEdge Authentication Gateway client. For more information, see the OpenEdge Authentication Gateway Guide in OpenEdge Getting Started: OpenEdge Authentication Gateway Guide.
  4. Update the default ABLDomainRegistry.keystore to include your domain name and domain access-code. Perform the following steps:
    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 one.
      Note: If you use a non-default name for the keystore file, change the .registryFile property in the oeablSecurity.properties file to the non-default keystore name.
    5. Design the role name pattern that will be used to designate an OpenEdge domain. For more information, see Obtain a domain name from a role name.
    6. When you have established a role name pattern, construct the Java RegEx pattern that will distinguish 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 required by your security practice, set the OEClientPrincipal.validateClientDomain property in the oeablSecurity.properties to true . The OEClientPrincipal.validateClientDomain property is a Boolean value that when set to true and when there is a domainRoleFilter defined, it compares the domain specified by the client to the domain produced by the domainRoleFilter. 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 will also need to modify the oeablSecurity*.xml file to access your authentication service.