Onegini Updates

Security Proxy 2.0: The Security Proxy as a Resource Gateway

Posted on February 7, 2017 by Mathijs Brand

Ever struggled to provide end-to-end security from your backend API's to your mobile apps? How to make them OAuth 2.0 compliant? Maybe you use an API Gateway like CA API Gateway or Apigee’s API Gateway or Akana. You may have noticed their primary focus isn't mobile. Maybe you don't have an API Gateway, but you have REST API’s that you partially want to open up to your customers. Your backend developers would like to reuse existing security protocols like basic auth while your app developers just want to focus on the functionality in the app.

I’ll explain in this blog how Onegini helps you solve this issue, so you can start opening up your backend to mobile users in weeks. And now with the Security Proxy 2.0 release, it will even go faster, because your API architecture can remain as is. But first, let's take a step back and see how the Security Proxy 1.0 worked.

Security Proxy 1.0, an introduction
feel free to skip if you are already familiar with our solution

The Onegini MSP takes care of OAuth 2.0 token management between mobile device and server through native mobile SDK's. The solution manages authentication through biometrics or PIN after which an backend API can be requested. A high level picture of this process is shown below (see our docs for a full component overview). 

The blue arrows show the authentication requests which are handled by the platform, while the red arrows show the requests from your app to your internal API’s. Before the actual backend API will receive a request, some component needs to do some validation with the Token Server. It needs to validate the access token, to see if it belongs to the user. In addition, it needs to check which api the user is allowed to access. This validation is usually done by a so called “Resource/API Gateway". Last year Onegini open sourced an example java implementation explaining how this can be done. While the implementation can be used as a base for your own implementation and isn't complex for security domain experts, this requires changes in your existing API-architecture/infrastructure. With the new release there is no need to change your current API-setup. This can all be managed within the Onegini platform. And as an added bonus, you won't require an understanding of how the OAuth 2.0 security protocols work.


The Security Proxy 2.0 can act as a Resource Gateway

The Onegini Security Proxy is an NGINX based component that was originally added to act as a reverse proxy to provide Payload Encryption functionality [1]. With the new feature in Security Proxy 2.0, you can use the security Proxy to handle the oAuth2.0 security-protocol as an intermediate to your api's or existing resource-gateway while using your existing security-protocol. Which means, in effect you can fully replace the implementation of your current resource gateway as is shown in the picture below.


Validation of the resource calls are now handled by the resource Security Proxy. Here's a breakdown of the functionality within:



You will focus on adjusting the custom security plugin. It's where you connect your API's or API gateway by implementing your own custom security within the component. 

An example

Let's say you have a mobile app which shows a car insurance and home insurance for a specific user. Each insurance has a separate API in the backend. Let's say the API for car insurance is a GET request call on https://my_internal_lan_server_for_car_insurances/car/user_id/get_my_insurance. Similarly the API call for the home insurance is https://my_internal_lan_server_for_home_insurances/home/get_my_home_insurance. In this second example the user_id is added as a header. Within your DMZ you use basic auth to connect to the API's.

The security proxy needs to map those resource calls from the mobile device to the correct API in the backend. If a user is not registered or does not have access to the car insurance, the user is not allowed access. These specific business and security rules must be implemented somewhere. You need to set the custom security by implementing your own security protocol. Finally, the mapping of the URL's can be done either in NGINX configuration or in the custom security component. For a full description on how to do this, check out our documentation.


Summary

I hope this blog helps you fast-track your project to open up backend API's to your customers in a secure and modern way. If you'd like to understand more or have a few questions, let us know. One of our consultants is more than happy to look into your specific case and help you on the way.

 

1: Payload Encryption is an extra layer of confidentiality, integrity, and authentication for all requests between the mobile device and server. Where TLS already provides end to end encryption from the device to the token server, Payload Encryption provides an additional layer. This makes attacks on an application using the SDK significantly harder.

Topics: Product Features, API Security