REST application managed security

Each OpenEdge REST application has an embedded Spring Security framework that provides a richer set of security features than is normally found in the Java Servlet Container. Additionally, it provides a common authentication and authorization configuration regardless of which type of Java container the REST application runs in. Spring Security provides access to the same forms of user authentication protocol as the Java container does, but has a richer set of user authentication system plug-ins, form login controls, and URL access controls.

The Spring Security framework may be configured to provide its own user authentication instead of using the Java container. Normally the administrator would choose the Spring Security framework for user authentication when application specific user authentication is required. Allowing the web application to perform user authentication also has the advantage of having a single location to configure all authentication, authorization, and session management. Of course, Spring Security can be configured to delegate user authentication to the Java container when needed.

The REST application and REST Manager come with built-in support for a number of authentication plug-in sources via a selection of sample configuration files, which may be configured at the production site.

The Web application's Spring Security is always where login session management and authorization to the REST resources (i.e. URIs) will be performed. The authorization is based on role memberships supplied by whichever authentication system is employed. The production administrator has a number of options to control login session management, including a built-in "remember-me" service. Other session context schemes are available where session context can be shared across multiple web servers configured in a load-balancing architecture.

The Spring Security framework has a rich set of access controls that employ powerful regular expression matching for URIs, HTTP verbs, and user role memberships. The granularity of this access control can range from coarse to fine-grained as demanded by the production site's security requirements.

The other primary task of the Spring Security framework is to bridge the REST application's authenticated user ID and session management with the AppServer. After the Web application user authentication, session management, and HTTP resource authorization completes, the Spring framework will generate a sealed Client-Principal for the login session. The resulting sealed Client-Principal will then be inserted into the Web application login context where it will be stored and transparently passed to the AppServer on each operation. Therefore, the AppServer application developer does not need to add additional parameters to each and every remote request for user-id and session-id. (If required, the AppServer and REST application may manually pass private user-id and session information as parameters for each service interface API, and configure the web application to send it to the REST client via customized data sources)

The AppServer application can accesses the Web application's sealed Client-Principal and session id via the ABL RequestInfo object from any activate, deactivate, or remote execution object. The RequestInfo object is common to all AppServer clients so that all service interfaces may share the same identity management code. Each time the AppServer runs a request the REST application will ensure the correct user Client-Principal and session ID pass are passed to it.