G
gary calcott
Guest
With the GA of OpenEdge 11.2 now successfully behind us, it’s time to take a closer look at one of the “mega topics” that (almost) everyone is talking about – security and mobile apps. In this two part series, we’ll first take a closer look at security from the mobile client perspective. In part two, we’ll dive into security requirements at the Web and Application Server Tier and explore the capabilities of the OpenEdge platform and how it satisfies those requirements to provide a secure, end-to-end deployment platform for mobile apps. I hope this proves useful for the broader OpenEdge Community, and not just Alice and Bob….
In OpenEdge Mobile, we can develop and deploy mobile apps as HTML5 web apps or as native apps for distribution via an app store such as Apple’s App Store or Google’s Play Store. Irrespective of the deployment variant, secure communications between the mobile client and the Web Tier using the HTTP/HTTPS REST transport (SSL/TLS) are fully supported (remember that the JavaScript Data Object (JSDO) facility in the mobile client relieves the developer of the complexities of secure communication via REST with backend mobile services). SSL/TLS support runs on the client side framework upon which the JSDO facility runs. Furthermore, as part of the instantiation of a Session between the mobile client and the Web Tier, OpenEdge Mobile supports several authentication models:
Clearly, these authentication models have to match across the mobile app and mobile application – i.e. Web Tier components of the architecture. Progress supplies mobile application security templates for appropriately locking down resources on the Web Tier (but we’ll look at that at more depth in part two).
Finally, OpenEdge Mobile implements Cross Origin Resource Scripting (CORS), which allows JavaScript code to call out to resources located in another (DNS) domain. We’ll take a closer look at this in part two, as it’s a server side capability; but it does of course impact the client. “Out-of-the-box,” JavaScript’s built-in security won’t allow you to do cross-domain calls. This W3C standard works by adding HTTP headers to the request and enabling server-side grant/revoke control for cross-domain resource requests – another good example of OpenEdge providing end-to-end security for enterprise class business applications.
That’s it for this brief tour of client-side security in OpenEdge Mobile. Watch this space for part two where we’ll look at more depth in securing the Web and Application Server components of our Mobile Application architecture.
Continue reading...
In OpenEdge Mobile, we can develop and deploy mobile apps as HTML5 web apps or as native apps for distribution via an app store such as Apple’s App Store or Google’s Play Store. Irrespective of the deployment variant, secure communications between the mobile client and the Web Tier using the HTTP/HTTPS REST transport (SSL/TLS) are fully supported (remember that the JavaScript Data Object (JSDO) facility in the mobile client relieves the developer of the complexities of secure communication via REST with backend mobile services). SSL/TLS support runs on the client side framework upon which the JSDO facility runs. Furthermore, as part of the instantiation of a Session between the mobile client and the Web Tier, OpenEdge Mobile supports several authentication models:
-
Illustration 1. A mobile native app running inside a native wrapper for the target platform (iOS and/or Android)
Anonymous – basically establish a session without supplying user credentials- HTTP Basic Authentication – this mode requires the mobile app to provide a username/password pair to the Web Tier in order to access the requested server-side resource
- HTTP Form Authentication – if a mobile app requests access to a server-side resource-requiring authentication it can either respond to an HTML logic page to capture the users credentials or the mobile app can provide those credentials prior to accessing the resource.
Clearly, these authentication models have to match across the mobile app and mobile application – i.e. Web Tier components of the architecture. Progress supplies mobile application security templates for appropriately locking down resources on the Web Tier (but we’ll look at that at more depth in part two).
Finally, OpenEdge Mobile implements Cross Origin Resource Scripting (CORS), which allows JavaScript code to call out to resources located in another (DNS) domain. We’ll take a closer look at this in part two, as it’s a server side capability; but it does of course impact the client. “Out-of-the-box,” JavaScript’s built-in security won’t allow you to do cross-domain calls. This W3C standard works by adding HTTP headers to the request and enabling server-side grant/revoke control for cross-domain resource requests – another good example of OpenEdge providing end-to-end security for enterprise class business applications.
That’s it for this brief tour of client-side security in OpenEdge Mobile. Watch this space for part two where we’ll look at more depth in securing the Web and Application Server components of our Mobile Application architecture.
Continue reading...