Posted on February 7, 2017 by Mathijs Brand
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 . 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.
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.
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.