Security considerations for SPA security configurations
The SPA security configuration process is used to authenticate users. The process itself must be secure against unwarranted attacks.
The following considerations must be followed for security purposes:
OERealm service interface security
The OERealm user details service can be configured to send a sealed ClientPrincipal to the AppServer OERealm service interface on each method invoked by the user details service. 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 OE REST 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 attributes
You can enhance security by setting the following OERealmAuthProvider attributes while sealing the ClientPrincipal:
The userDomain attribute to set the static OpenEdge domain.
The 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 OE REST Web application just by disabling the domain. The following table defines the available combinations of domain, domain access code, and user ID:
Table 89. 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 multiTenant attribute of the OERealmAuthProvider, all the user IDs are appended with the userDomain attribute value. In this case, the same key can used to seal the ClientPrincipal for all OE domains.
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 OE REST Web application’s OERealmAuthProvider supercedes 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 its enableCP 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 AppServer. To use this validation technique, the OE REST Web application's OERealmUserDetails acts as an AppServer client and identifies itself to the AppServer'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 OE REST Web application's OERealmUserDetails for acting as an AppServer client:
1. Use the genspacp utility, at the $DLC/bin location, to create a sealed ClientPrincipal that represents a valid AppServer 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 OE REST Web application's WEB-INF/classes directory.
3. Set the realmTokenFile configuration property of OERealmUserDetails 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 OE REST Web application is loaded, if the realmTokenFile configuration property of OERealmUserDetails 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