OERealm security considerations

Secure the OERealm Service Interface

If the ABL class providing the OERealm service requires client authentication, the client must include a realm token property pointing to a file that contains a sealed Client-Principal object that the OERealm service can validate.

The OERealm user details service can be configured to send a sealed Client-Principal object to the PAS for OpenEdge instance on every method call. In this case, the OERealm service interface might incorrectly intercept the Client-Principal object from SESSION:CURRENT-REQUEST-INFO:GET-CLIENT-PRINCIPAL and validate the client before performing any OERealm operation.

Another security risk occurs when using the SECURITY-POLICY:SET-CLIENT() method or SET-DB-CLIENT function for identity checks. These methods change the current identity of the ABL session, which must then be restored after the OERealm operation completes.

Recommended Approach:

Use the Client-Principal:VALIDATE-SEAL() method to validate the Client-Principal object. This method accepts an optional character expression containing the domain access code originally used to seal the object. If no access code is provided, the AVM uses the code defined in the trusted domain registry. Apply this validation at the start of each OERealm service interface method. This approach isolates OERealm operations from other identity-related activities, such as session, database, server connection, or BPM identity.

Secure the OERealm AuthProvider

You can configure the OpenEdge domain access code to seal the Client-Principal object when using single sign-on (SSO) mode. By default, the Spring Security OERealm AuthProvider creates theClient-Principal object as a single tenant, meaning all web application users share the same OpenEdge domain.

To improve OERealm AuthProvider security, you can apply one of the following:

1. Set userDomain and registryFile properties.

   Enhance security by configuring these OERealm.AuthProvider properties in the oeablSecurity.properties file when sealing the Client-Principal object:

   • OERealm.AuthProvider.userDomain—Sets the default OpenEdge domain when the input userid does not include one.
   • OERealm.AuthProvider.registryFile—Stores the domain access code and supports multiple domains.
   Note: The OERealm.AuthProvider.key attribute is no longer supported.

   These attributes allow you to uniquely identify application users based on their domain. You can also disable access to the web application by disabling the domain.

   The following table defines the available combinations of domain, domain access code, and user ID:

   Domain name	Key attribute	User ID	Signing operation
   "" (default)	"" (default)	"uid"	Seal the blank domain using the built-in domain registry blank access code.
   ""	""	"uid"	Seal the blank domain using the clear text string value, "".
   "abc"	"" (default)	"uid@abc"	Seal the abc domain using the built-in domain registry blank access code.
   "abc"	""	"uid@abc"	Seal the abc domain using the clear text string value, "".

   CAUTION: Progress Software corporation strongly recommends that you take steps to hide or otherwise protect any domain access code that you specify in your ABL code from access (hacking) by unauthorized users. The clear-text string should be stored encrypted to secure the domain access code, and decrypted only when it is necessary to use the stored value.
2. Set the multiTenant property.

   When you enable the OERealm.AuthProvider.multiTenant property, all the user IDs are appended with the userDomain value only if the user ID being authenticated does not already specify a domain name.

3. Set the external domain registry for multi-tenant applications.

   The OERealm AuthProvider provides support for using an administrator-generated domain registry file to sign and seal Client-Principal objects in multi-tenant applications. This file contains a list of domains that are allowed to have access to the Client-Principal object.

   To use the domain registry file:

   1. Use the gendomreg command, located at DLC/bin, that takes a formatted text file as input and creates a secure binary domain registry file. The text file lists OpenEdge domains that are allowed to have access to the Client-Principal object in the domain_name,access_code format. Each domain must be listed in a separate line. These values are blank by default.
   2. Copy the generated domain registry file to the OpenEdge ABL web application's /WEB-INF/classes directory.
   3. Configure the OERealm AuthProvider to load and sign a Client-Principal object.

Prevent authorization before authentication

The Client-Principal object that is generated by the web application’s OERealm AuthProvider supersedes the one that is generated by the OEClientPrincipalFilter for SSO. This is a problem when the OEClientPrincipalFilter authorizes the incorrect Client-Principal object without any processing. You can disable the OEClientPrincipalFilter by setting the OEClientPrincipalFilter.enabled property to false.

Another potential security problem occurs if a client is able to call the OERealm service interface without authentication. You can secure the service interface against unnecessary client access by using the Client-Principal object and validation technique that is similar to the one that is used in the ABL business logic of your OpenEdge application server. To use this validation technique, the web application's OERealmUserDetailsImp module acts as a client and identifies itself to the application server's OERealm service interface. The service interface validates the client using a Client-Principal object just like it is used in other parts of the ABL application.

To develop the web application's OERealmUserDetails so it can act as an OpenEdge application server client:

1. Generate a sealed Client-Principal token file

   Use the genspacp utility in DLC/bin to create a .cp file representing the OERealm service client.

   The utility requires:

   • User ID
   • Domain Name
   • Domain Access Code
   • Output file name

     This creates a binary file containing the sealed Client-Principal object. The domain name and access code can match those used by the OERealm service interface for validation or be a unique combination.

2. Copy the output file

   Place the .cp file in the web application’s WEB-INF/common/lib directory.

3. Configure the realm token property

   Set OERealm.UserDetails.realmTokenFile to the output file name (for example, mytoken.cp).

4. Add validation in the OERealm service interface

   Include Client-Principal validation code in the PAS for OpenEdge instance activate procedure or in each OERealm class method.

   Progress recommends using:

   Client-Principal:VALIDATE-SEAL("domain-access-code")

   For details, see the VALIDATE-SEAL() method in the ABL Reference.

When the OERealm service interface validates the Client-Principal object from the generated binary file, the following sequence occurs:

1. Loading the Client-Principal object

   After the web application starts, if the OERealm.UserDetails.realmTokenFile property specifies the output file name, the file is used to load the Client-Principal object.

   • If the file cannot be loaded, an error is logged.
2. Sending the Client-Principal object

   For each user authentication request, OERealmUserDetails sends the Client-Principal object to the PAS for OpenEdge instance OERealm service interface methods.

3. Validation process and outcomes
   • If the Client-Principal object is not sent, the interface returns an error.
   • If the object is sent, the interface validates the domain access code:
     • If validation fails, an error is returned.
     • If validation succeeds, the ABL class method continues execution.

User password encryption

In the current sample HybridRealm.cls code, the ENCODE() function provides only a very basic method for creating a one-way hash of a password. In practice, you should use a more robust and secure hashing algorithm for both generating and validating user account passwords.