The OERealm authentication process must be secure against unwarranted attacks.
The following considerations must be observed for security purposes:
OERealm service interface security
If the ABL class that provides the OERealm service requires authentication of clients, then the client must have a realm token property configured with a file that contains a sealed ClientPrincipal that the OERealm service is capable of validating.
Since the OERealm user details service can be configured to send a sealed ClientPrincipal to the AppServer OERealm service interface on each method it invokes, the OERealm service interface can wrongly intercept the ClientPrincipal from SESSION:CURRENT-REQUEST-INFO:GET-CLIENT-PRINCIPAL and validate the client before performing any OERealm operation.
Another security flaw occurs when you use the SECURITY-POLICY:SET-CLIENT() or SET-DB-CLIENT() method for performing OERealm client identity checks. Using these methods changes the current identity of the ABL session, which must then be reestablished after the OERealm operation is complete.
To overcome this problem, it is recommended that you use the CLIENT-PRINCIPAL:VALIDATE-SEAL() method along with encoded domain access codes ("oech1::xxxx") to validate the ClientPrincipal. You can apply this validation as an operation at the beginning of each OERealm service interface method. This isolates the OERealm use case from the other ClientPrincipal-related activities, such as a session, database, AppServer connection, or BPM identity.
OERealmAuthProvider security
You can configure the OpenEdge domain access code to seal the ClientPrincipal in the Single sign-on (SSO) mode. By default, the Spring Security OERealmAuthProvider bean creates the ClientPrincipal as a single-tenant. The problem is that every Web application user of the ClientPrincipal is a member of the same OpenEdge domain.
You can enhance OERealmAuthProvider security in one of the following ways:
Set the userDomain and key properties.
You can enhance security by setting the following OERealmAuthProvider properties in theoeablSecurity.properties file while sealing the ClientPrincipal:
The OERealmAuthProvider.userDomain attribute to set the static OpenEdge domain.
The OEClientPrincipalFilter.key attribute to set the domain access code.
These attributes are used to uniquely identify application users based on the user domain. You can also disable access to the Web application just by disabling the domain. The following table defines the available combinations of domain, domain access code, and user ID:
Table 12. Available combinations of domain, domain access code, and user ID
Domain name
Key attribute
User ID
Signing operation
"" (default)
"" (default)
"uid" ("uid@")
Seal the blank domain using the built-in Domain Registry blank access code.
""
"<xxxx>"
"uid" ("uid@")
Seal the blank domain using the clear text sting value, "<xxxx>".
""
"oech1::<xxxx>"
"uid" ("uid@")
Seal the blank domain using the encoded value, <xxxx>.
"abc"
"" (default)
"uid@abc"
Seal the abc domain using the built-in Domain Registry blank access code.
"abc"
"<xxxx>"
"uid@abc"
Seal the abc domain using the clear text sting value, "<xxxx>".
"abc"
"oech1::<xxxx>"
"uid@abc"
Seal the abc domain using the encoded value, <xxxx>.
Set the multiTenant property.
If you enable the OERealmAuthProvider.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..
Set the External domain registry for multi-tenant applications.
The OERealmAuthProvider provides support for using an administrator-generated Domain Registry file to sign and seal ClientPrincipals in multi-tenant applications. This file contains a list of domains that are allowed to have access to the ClientPrincipal.
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 OE domains that are allowed to have access to the ClientPrincipal in the Domain-name=Domain-access-code format. Each domain must be listed in a separate line.
2. Copy the Domain Registry file to the OE REST Web application’s /WEB-INF/classes directory.
3. Configure the OERealmAuthProvider bean to load and sign a ClientPrincipal.
Preventing authorization before authentication
The ClientPrincipal that is generated by the Web application’s OERealmAuthProvider supersedes the one that is generated by the OEClientPrincipalFilter for SSO. This is a problem when the OEClientPrincipalFilter authorizes the incorrect ClientPrincipal 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 such unwarranted client access by using the ClientPrincipal 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 ClientPrincipal just like it is used in other parts of the ABL application.
To develop the Web application's OERealmUserDetails for acting as an OpenEdge application server client:
1. Use the genspacp utility, at the $DLC/bin location, to create a sealed ClientPrincipal that represents a OERealm service client. The utility requires the user ID, domain name, domain access code, and output file name to create a binary file that contains the sealed ClientPrincipal in the <file-name>.cp format. The domain name and domain access code correspond to those that are then used in the OERealm service interface to validate clients.
2. Copy the output file from the $DLC/bin location to the Web application's WEB-INF/classes directory.
3. Set the OERealm.UserDetails.realmTokenFile property to the output file name.
4. In the OERealm service interface, add the ClientPrincipal validation code. The code can reside in the AppServer activate procedure or as step in each of the OERealm class methods. It is recommended that you use the CLIENT-PRINCIPAL:VALIDATE-SEAL("domain-access-code") method for validation. You must ensure that domain-access-code is in the encoded "oech1::xxxx" format.
When the OERealm service interface validates the ClientPrincipal in the created binary output file, the following sequence occurs:
1. Once the Web application is loaded, if the OERealm.UserDetails.realmTokenFile property contains the output file name, the file is used to load the ClientPrincipal. If the output file does not load, an error is added to the error log.
2. For each user authentication request, OERealmUserDetails is used to send the ClientPrincipal to the AppServer OERealm service interface methods.
3. The OERealm service interface validates the ClientPrincipal. The following validation outcomes are possible:
If the ClientPrincipal is not sent to the interface, an error is returned.
If the ClientPrincipal is sent to the interface, the interface is used to validate the domain access code. If the validation fails, an error is returned.
If the ClientPrincipal validation is successful, the execution of the ABL class method continues.
OERealm service interface security