Developing Secure Applications Part 4 Secure MicroServices

0
3914
Developing Secure Applications Part 4 Secure MicroServices

Developing Secure Applications Part 4 Secure MicroServices

In part 2 and part 3 of Developing Secure Applications series we have looked at OpenID connect and OAuth2 using the excellent WSO2 identity server from wso2. This is an excellent solution when you need a secure intranet or domain and you do not want to have to use an external Authorization Server or relying party.

You could use this approach as a lightweight alternative to security implementations based on The Lightweight Directory Access Protocol (LDAP). While many open source LDAP solutions are available that are highly configurable and secure they are difficult to set up and maintain.

In contrast the wso2 suite of security products as we illustrated when we configured the wso2  Identity Server as a local Authorization Server are a breeze to set up and run.

However the wso2  Identity Server is still a large applications and in the case of the Identity server a Java based web application. While there is no intrinsic disadvantage in a Java application, Java web applications need to be tightly locked down when performing a security role. Without the protection of a correctly configured firewall the server itself can be vulnerable to a determined and resourceful attacker.

There is a movement in place partly driven by security concerns to move away from monolithic applications to more lightweight and configurable solutions, the success and vast uptake of the excellent Node Js JavaScript framework has been a big mover for this change.

More recently the term “Microservices” has emerged to describe an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms like REST.  There is a small optimised management layer for the services, which often are implemented in different programming languages and use different persistence layers.

Java also has a framework known as OSGi which allows highly configurable and modular application development very suitable for Microservices and combined with frameworks like  mqtt it is possible to build modular configurable maintainable applications with extremely small footprints.

The JVM programming language Scala has allowed java developers to learn from the innovations in Node Js, that is Non-blocking code with callbacks (Event-driven asynchronous callbacks). Scala can improve on NodeJs with Scala’s excellent concurrency framework akka. The concurrency allows massive simplification of the callback code.

Node Js is a stable well documented framework. There is a much larger community support network for Node. Seeking to fill a gap community support for Scala/Play, in this article we will go through the steps involved to create and configuring a Play Framework application for OAuth2 and OpenID Connect.

Also embedded OSGi applications would work better with a Scala/Java Play Framework server. Basically are premise for this final article in the series is that we can consider a good architecture for a microservice would be distributed OSGi clients connected with a Play Framework backend as a REST api.

Build a Small but Powerful Server with Wide Relying Party Support
The articles source code for this article can be found here.

The goal of the source code is to illustrate just how small the actual code base required to implement Oauth2 and OpenID Connect authentication flows with Play and associated Scala packages. We use the excellent upgrade of the OAuth library scribe to be implemented as a  Scala Play package  play-pac4j  also available for a range of frameworks in its parent framework pac4j.

This class shows the rest implementation once we have set up a rest client for each relying party.

Setup Application Credentials
The diagram below shows a highly simplified breakdown of the role of the three (3) relying parties
we use in the application’s source code.

1

First you must use the links above and follow to the pages to create authorisation credentials for the application. The process and requirements for creating the credentials can change over time and are markedly diferent for each relying party, however in all cases it is possilble to use localhost or 127.0.0.1 in your callback url, however it takes some patience and perserverence

To get you started for Google to set up OpenID Connect credentials once you have a registered app and followed the instructions to navigate to the APIs & Auth -> credentials
2
to get the the app to work I found I needed to enter the following in the ReDirect URL’s

  • http://localhost:9000/callback
  • http://localhost:9000/callback?client_name=Google2Client

It is a similar process for Facebook and Twitter.

Walk through the Play Server’s User Authorisation Code

The source code for this article (found here) is a basic template with a landing page and a link to authorise at the Relying party then, a protected resource to display the user’s information granted via the profile scope of the applications request and the user’s choice at the relying parties endpoint.

The goal of this code is to illustrate how we can exploit well known Social Media services as relying parties, to provide secure user authorisation with the delegation pattern (not requiring the user to submit their credentials at our application to authorize).

The code fragments that follow show how this can be achieved with minimal code and a light footprint via both the Play Frameworks excellent architecture and the previously described update for Scala of Scribe,pac4j,

Application code fragment for the Relying Party’s REST endpoints

This code fragment uses the Play frameworks rest endpoint configuration ‘magic’ with  pac4j  to implement the Authorisation start point links that pull in the appropriate REST client for each relying parties API.

Application Relying Party REST CallBacks code fragment
This code fragment uses the Play frameworks rest endpoint configuration ‘magic’ to implement protected resources hooked into the  REST client for each relying parties API.

The code blocks below show how incredibly simple it is to set up the REST clients for each party’s API. We have implemented REST clients Facebook Connect, Google OpenID Connect and vanilla Oauth2 via Twitter with pac4j. In most cases setting up the rest client is just a single line of code.

Set up the rest client

Authenticate with Twitter (OAuth2)
Code Fragment

Screen shot of the Twitter Authorisation and Grant endpoint
Twitter Authorisation and Grant endpoint
Authenticate with Google (OpenID Connect)
Code Fragment

Screen shot of the Google Authorisation and Grant endpoint
Google Authorisation and Grant endpoint
Authenticate with FaceBook (FaceBook Connect)
Code Fragment

Screen shot of the FaceBook Authorisation endpoint
FaceBook Authorisation endpoint
Screen shot of the FaceBook Grant endpoint
FaceBook Grant endpoint
After the user Authenticates and authorises at the relying party the Play Framework handles the callback with a simple annotation and displays the granted Federated identity information here.
Code Fragment

Using  pac4j and the Play Framework we have implemented an Authorisation flow utilizing the three major Social Media services as relying parties and implementing OAuth2 in the delegation pattern in the case of OpenID Connect.

Summary
In this we have looked first at the core security architectures for the Internet.

In part 1 of this series we looked first at the core security architecture for the Internet SSL/TLS and investigated the issues around SSL/TLS.  Using Plays excellent SSL/TLS integration and documentation we were able to rapidly spin up a basic server and rest client and perform the SSL/TLS handshake via our own digitally signed certificate.

This is the important first step as in security terms Oauth2 and its support of higher level specs like OpenID Connect are meaningless unless the bearer tokens are secured. In the OAuth 1 specification the bearer tokens were themselves were digitally signed, but the complexity and interoperability issues this caused led to this step being dropped for OAuth2.

In part 2 we investigated the issues around OpenID Connect and using the excellent OpenID Connect integration and documentation available in the wso2 Identity server looked at how you could set up your own OpenID Relying Party and Authentication server. This is useful if you need to set up a security or identity management system for applications behind a corporate or government firewall or do not want to rely on the Social media giants for your federated identities.

In part 3 we looked at the underlying Oauth2 code, artifacts and flows that support OpenID Connect. We looked at the key artifacts for Oauth2 ‘tokens’ and the types, roles and security issues around the tokens.

In this article we investigated the issues around OpenID Connect’s implementation with the underlying OAuth2 protocol. We also have provided a template for bootstrapping a Play application configured with pac4j for OpenID Connect and OAuth2.

LEAVE A REPLY

Please enter your comment!
Please enter your name here