Using Single Point of Authentication security configurations
This section helps you understand how to use the OpenEdge Single Point of Authentication (SPA) configurations to configure your REST Web application's security.
SPA in OpenEdge enables you to reuse an AppServer as the source of user account information for the authentication process. This reusability is provided by the Spring Security framework. Spring Security requires a separate authentication provider plug-in for each user account information source, such as an RDBMS database or a local text file. The Spring Security authentication process uses an object model that performs certain tasks:
Authentication manager: The manager is responsible for creating and calling one of more authentication providers until the authentication process is complete (success or failure).
Authentication provider: The provider is called by the authentication manager and is responsible for creating the user details service.
User details service: This service is created by the authentication provider and is responsible for interacting with the account system to retrieve the user account along with the account attributes information, such as password and user roles. This information is used for validating the account password and for creating a Spring Security authentication token.
Authentication token: This token is created as the result of a successful Spring Security authentication process. The token contains authenticated user information, such as user ID, granted roles, and session ID.
Note: The authentication token is used to generate a Spring ClientPrincipal token that can be used further in the authorization process.
The OpenEdge SPA implementation extends the Spring Security authentication process. The implementation consists of 2 components:
OpenEdge Realm (OERealm) Client: The client contains the Spring Security authentication provider and user account service objects that interact with the AppServer to retrieve the user account information. This information is then sent to the Spring Security authentication process.
The OERealm Client does the following:
1. Connects to the AppServer.
2. Executes a request to locate the user account and retrieve the account unique numeric ID.
3. Executes requests to retrieve the user account details in the following order:
a. Granted roles
b. The account enabled state
c. The account locked state
d. The account expired state
If the OErealm client finds that the account does not exist or if the account is in the disabled, locked, or expired state, no additional AppServer requests are performed.
OERealm AppServer ABL interface:The service interface class that implements the OERealm ABL interface must also implement the OERealm component on the AppServer.
The actions of the class are performed in the following order:
1. Search for the user account using the name (userid[@domain]).
2. Return the user account attributes for the user account.
3. Validate the user account’s password.
Optionally, authorize the OERealm client and enable it to receive user account information.
For details on how to create an OERealm AppServer ABL Interface see the OERealm section.
To use SPA for configuring your REST Web application's security:
Authentication manager: The manager is responsible for creating and calling one of more authentication providers until the authentication process is complete (success or failure).
