Batten down the hatches - Server-Side Security of OpenEdge Mobile

In part one of our look at security on OpenEdge Mobile we focused on making the client-side secure. As promised, in this short blog, we’ll take a deeper dive into the server-side of OpenEdge Mobile.

First of all, let’s briefly review the architecture of OpenEdge Mobile:

The JavaScript Data Object (JSDO) facility is the run-time facility of OpenEdge Mobile which enables mobile apps to easily communicate with back-end services. Under the covers, the protocol between the mobile client and the Web Server is HTTP(S)/REST. Mobile Services are securely housed in the Web Server and in-turn, access Mobile Interfaces on the OpenEdge AppServer to execute business logic.

On the Web Server Tier, OpenEdge provides application security templates which the application developers and production admins can customize to protect resources (a.k.a. Mobile Web Applications, see Figure 1 above). Mobile Web Apps are protected via similar mechanisms. The templates configure the industry standard Spring Security Version 3.1 framework which is co-packaged with the OpenEdge application to manage security for the mobile application’s REST resources.

Spring security is a comprehensive, peer-reviewed framework and having it tightly integrated with the OpenEdge platform is a huge benefit for system architects and developers. No longer do architects and developers need to develop “home grown” solutions to provide authentication and authorization, as they can now fully leverage the respected and well documented Spring framework for their security needs. The Spring templates are located in the WEB-INF directory of an OpenEdge project in Progress Developer Studio for OpenEdge.

Here’s a snippet of the web.xml file contained in the WEB-INF directory:

Note that we’ve enabled an authentication model of “anonymous” here. Let’s drill down one level to explore appSecurity-anonymous.xml:

REST Manager (or ‘RESTMAN’) is an administration utility for managing the lifecycle of mobile applications. We’ll make ‘RESTMAN’ the topic of a future blog. Let’s move down the file….

Here we can see a first introduction of how we can configure the generation and transportation of an authenticated user token into an OpenEdge Client Principal object which can be used on the AppServer Tier for handling fine-grained access to protected resources. Additionally we can see an indication of how Cross-origin Resource Sharing (CORS) can be configured to enable cross-domain access from (mobile) JavaScript clients.

Moving down the file further, we can see how we can evaluate access to protected resources:

This has been a very brief tour of server-side security in OpenEdge 11.2. As previously mentioned, in a future post we’ll dissect some of the capabilities outlined above, e.g. the ‘RESTMAN’ utility. We’ll also explore how OpenEdge enables Single-Sign-On across the end-to-end platform for secure access to protected resources.