Welcome!

Java Authors: Elizabeth White, Roger Strukhoff, Pat Romanski, Mark Cravotta, Liz McMillan

Blog Feed Post

Simplifying the app delivery stack

Gunnar Peterson and Ken van Wyk are running a Mobile Application Security Triathlon in NYC for three days (hence "Triathlon") starting on 29 April. As part of this, they're running a joint blog. The posting today is a great examination of the different sessions which are in play when a mobile app is used:
First off the user likely authenticates locally to the mobile app itself, let's call this session #1. Then any time the app needs to do something on the network (like synchronize data or replicate) it authenticates from the mobile app to the server, let's call this session #2. Next the server is very likely an API Gateway with no data or business logic, that is on the backend app servers, so the Mobile API Gateway has authenticate to the backend servers, let's call this session #3.
Now just logging into each of these sessions is a decent bit of work in and of itself. Add onto that the fact that very likely these are three fundamentally different protocols - maybe username/password for #1, OAuth for #2 and SAML for #3. Logging in is where it begins, but that's not where it ends.
 
http://mobappsectriathlon.blogspot.com/2013/04/mobile-session-management-which-session.html
Counting the different session contexts is a useful way to examine the traditional architecture used to deliver mobile applications. I'd add that there is usually a data services layer behind the app server, and that has a security context of its own, which is often overlooked.

Drawing it out, we see the the diagram below:

But, let's examine what the app server is doing. Usually, it is housing Java code, and providing session management services. But wait, we've see that an API Server can be used as a container for scripts and Java classes. It also can be used to manage sessions, and to connect to data services. So it makes sense to simplify the architecture, introducing the API Server like so:



The API Server acts as more than just a Gateway, because it houses the API itself. It also means that there are fewer security sessions in the architecture to worry about. It means fewer moving parts, less to manage, and less expense. That connection between the API Gateway and App Server is gone, because they are now one and the same: the API Server.

Here at Axway we see the API Server enabling the Next Generation application "stack": consisting of apps at the front end, connecting to the API layer, with data services behind. An API Server simplifies the API layer by combining the API exposure with the API delivery itself, meaning fewer moving parts, less expense, and, as we see here, fewer security sessions to deal with. 

Read the original blog entry...

More Stories By Mark O'Neill

Mark O'Neill is VP Innovation at Axway - API and Identity. Previously he was CTO and co-founder at Vordel, which was acquired by Axway. A regular speaker at industry conferences and a contributor to SOA World Magazine and Cloud Computing Journal, Mark holds a degree in mathematics and psychology from Trinity College Dublin and graduate qualifications in neural network programming from Oxford University.