AeroGear Unified Push and OpenShift Origin


For people who are making mobile applications, managing the various server components and technologies is a challenge.
This post will demonstrate how to use OpenShift Origin to host an instance of Aerogear Unified Push Server and then start development on an Android application on your development machine.
AeroGear Unified Push Server is a project that provides a single service to manage multiple push networks for your mobile applications. OpenShift Origin is a container management platform build on Kubernetes and Docker technologies. Both are Open Source and sponsored by RedHat.

Getting and Starting OpenShift Origin


Before you can use Origin you need to have Docker installed on your computer as well as configure its to use OpenShift’s internal Docker registry. You can do this by passing the following parameter to Docker when the service starts --insecure-registry System specific details can be found here.

You will also need the tool oc. It can be found on the Origin’s GitHub releases page.

Launching OpenShift Origin

oc cluster up.

Yup that is all you need. Now you can browse to and login as developer:developer.

Deploying AeroGear UPS

We will use the Unified Push Server image found on Docker Hub. Reviewing that page we see that it needs two MySQL instances named “unifiedpush” and “keycloak”. We can create those in Origin, deploy UnifiedPush, and then add a route for our Android emulator.

Deploying MySQL containers

oc new-app mysql MYSQL_USER=unifiedpush MYSQL_PASSWORD=unifiedpush MYSQL_DATABASE=keycloak --name=keycloak

oc new-app mysql MYSQL_USER=unifiedpush MYSQL_PASSWORD=unifiedpush MYSQL_DATABASE=unifiedpush --name=unifiedpush

You can watch both systems come online in your console, or view their status with oc status.

Deploying AeroGear UnifiedPush

oc new-app aerogear/unifiedpush-wildfly \
 UNIFIEDPUSH_PORT_3306_TCP_ADDR=unifiedpush \
 KEYCLOAK_PORT_3306_TCP_ADDR=keycloak \

This command will deploy UnifiedPush and connect it to your MySQL containers. If you are work with Docker then the environment variables we use should be familiar; that is because this is a plain Docker container.

Adding Routes to the UnifiedPush application

By default OpenShift applications are not routable. This means that we can not point a web browser to UnifiedPush to configure it nor can an Android device connect to it to receive push messages. We will add two routes to enable both of these behaviors.

oc expose service unifiedpush-wildfly --port=8080-tcp --name=ups-local-unsecured
oc expose service unifiedpush-wildfly --port=8080-tcp --name=ups-android-unsecured

The first route exposes UPS on the local machine’s IP address, and the second exposes on which is the hardcoded IP address for the host of an Android emulator. These hostnames use to fake the DNS lookup.

Fixing Keycloak Linking

UPS uses an embedded Keycloak server to handle its authentication. Right now there is an issue when the UPS pod starts up it can’t route to Keycloak using the public route. To work around this you will need to use the OpenShift web console to navigate to the unifiedpush-wildfly pod and execute “wget http://localhost:8080/ag-push/index.html” in the terminal after the application loads.

Configuring UnifiedPush

You should be able to navigate to now and set up UnifiedPush. The full instructions for configuring this can be found on

Configuring you Android Push Application

You can follow the HelloPush tutorial here. The only change is you will use “” as your push URL.

Integrating Stack Exchange and JIRA


We are working to get the Red Hat Mobile Application Platform (RHMAP for brevity) Open-Sourced as FeedHenry and have discussed the usual array of community support options : mailing-lists, IRC, GitHub, JIRA, etc. However, the community is already using Stack Overflow to ask questions and get help from one another.

This leads to a question though : how do we integrate Stack Overflow monitoring with our current workflows? Enter so-monitor, a simple node.js application to watch Stack Overflow for questions and track their status in a JIRA. The project creates a ticket when a question is asked using a tag we monitor and then will close the JIRA ticket when the question is marked as answered.

Setup of Development Environment

I decided to write the monitor as a Node.js application, and that I would use Visual Studio Code as my IDE. Being a Java developer I am used to many tooling features: intellisense, robust debugging, etc. Also being a Java developer I had heard that most of these things were just not as mature in the Node.js ecosystem. While I feel this is still true, VS Code and [Definitely Typed|] have closed the gap significantly. If you are interested in learning more about this setup I suggest following MS’s blog post. It was very helpful to me.

Consuming the Stack Exchange API

The Stack Exchange API is pretty standard as far as RESTful APIs go. There is a public API that with a limited quota expands more once you get an API key. The biggest difficulty I had was with their filters concept. Basically in Stack Exchange sites you can create a filter for your API calls that lives on their servers and then reference it with a stable, public ID.

I used Moveo’s Stack Exchange API wrapper to access the API and it worked rather well.

JIRA’s black magic

For as simple as Stack Overflow was, JIRA was not. However, JIRA is 100% scriptable and you can configure it to respond to nearly any requirement you may have. Putting a question into JIRA was basically four steps

  • Create the ticket
  • Formatting the question as a issue
  • Tagging my team
  • Closing the issue when the question was answered.

To wrap the JIRA REST API I used steve’s node jira library.

The trickiest part of the process was keeping the issue and the question states in sync. I used a custom field to track the question id returned by the Stack Exchange APIs, but managing the state hit an unexpected snag.

JIRA uses a transitions metaphor for changing the state of a ticket. This means there isn’t a “close issue” API call, but instead you have to upload a “transition” object to the issue endpoint that defines which transition you wish the issue to have taken. This means that you have to either a) check the state of the JIRA issue, lookup a transition, and execute that one or b) create a “Any State” -> “Close” transition in JIRA and hard code that. I chose “b”. For more information I encourage you to read JIRA’s API docs. They are really good and it is a very different pattern than Stack Exchange uses.


While the Stack Exchange and JIRA APIs were the main meat of the monitor project, there were many small “learnings” I had above and beyond that. VS Code and typings is a wonderful JavaScript experience. Using Q promises and wrapping node calls in Promises with simple one liners made my main code much easier to follow. Node.js and the JavaScript ecosystem has come phenomenally far in four years and it is finally as productive as more “Enterprisey” technologies like .Net and Java.

Android N – Security with Self Signed Certificates

If you are a good developer you are securing your services with SSL encryption. Unless you have put in a lot of effort, local testing still uses the good old fashioned self signed certificate and just click through the warning window of shame.

Screenshot from 2016-05-04 13-04-42

This is great until you are writing a RESTful service to be consumed by something which isn’t a browser. If you are an Android developer you have probably come across blog posts (or the official Android docs) encouraging you to make your own Trust Manager to accept your certificate or, worse, disable certificate checking altogether! However, Android N has come to the rescue with new security configuration features.

Using Self Signed Certificates with Android N

To use a self signed certificate you need to

  1. Add a meta-data tag to your AndroidManifest.xml which points to a security configuration xml file
  2. Add to your xml resources directory the security configuration file
  3. Download your self signed certificate to your project

Edit AndroidManifest.xml

I’ve added in my projects the following code to Android Manifest’s application element
[code lang=”xml”]
<meta-data android:name=""
android:resource="@xml/network_security_config" />

This code just informs Android that the configuration file is found in res/xml/network_security_config.xml.

Creating the Network Security Config

The full documentation for the network security files covers a lot more than our use case for a self signed certificate. It is well worth a read to understand what is being done.

Here is my XML file to load my certificate from the raw directory. I have it named server_aerogear_dev, but the file name is irrelevant. What matters is that the common name in the certificate file matches the domain name of the server. I am pretty sure that this also works with IP addresses, but I haven’t tested it.
[code lang=”xml”]
<?xml version="1.0" encoding="utf-8"?>
<certificates src="@raw/server_aergear_dev"/>

Downloading the certificate

You can download the certificate to the raw directory in your source using your web browser or using the command line.

cd app/src/main/res/raw;
echo -n | openssl s_client -connect | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > server_aerogear_dev
// Credit to SO :

Replace the name of the server and the port with configuration appropriate to you.

Final Notes

This is a very simple example of a new feature from Android N. This may change or go out of date. However, this gives us a simple was to manage security and it ALSO works within Android’s build flavor system. Take a look, and stay safe.

RHMAP and Google Accounts in Android

The Red Hat Mobile Application Platform (RHMAP) has strong authentication and authorization mechanisms baked into its Auth Policy system. Android has deep integration with Google’s ecosystem which provides many easy mechanisms for authorizing services to act on a user’s behalf. Out of the box RHMAP allows for connecting to a Google account using OAuth and a web view, but a better user experience is using Google’s Android account picker. To enable this integration in RHMAP we have to use a MBaaS Auth Policy.


This post should be informative to anybody who wishes to learn more about RHMAP; however, you will have the most benefit if you have access to a RHMAP instance and have read through the Getting Started documentation. If you do not have access to a instance of RHMAP, you may sign up for a free one at

Additionally you will need a Google account and Android emulator or device with Google’s APIs set up.


You can view an example of this integration in my FehBot video. The Android portion of this post will refer to the code in the application.

Creating an MBaaS Auth Policy

Create a blank MBaaS Service

Select “Services & APIs” from the top navigation. Click “Provision MBaaS Services/API”


Select “Choose” next to the item “New mBaaS Service”.


Name the service, click “Next”, ensure you are using the “Development” environment, and finally click “Deploy”. The service should deploy and you should have a green bar.


You are now ready to set up the Auth Policy.

Setup the Auth Policy

Select “Admin” from the top navigation and then “Auth Policies” from the 6 boxes which appear. Create_auth_policy_1

Click “Create” on the next screen to begin setting up an Auth Policy.

Name the Policy and select “MBaaS Service” as the “Type” under “Authentication. From the “Service” drop down select the service you created in the previous step. For “Endpoint” our MBaaS service will use “/auth/init”. Finally select for your “Default Environment” the value “Development.

Scroll down to the bottom of the page and click “Create Auth Policy”.

Implementing the MBaaS

I have created a MBaaS Service for us to use. It implements the server side token validation that Google recommends in its documentation. You should be able to copy this project into your MBaaS’s source and redeploy it.

You may wish to limit which Cloud applications can access your MBaaS services in the “Service Settings” section of the MBaaS “Details” page.



The /auth/init route will consume tokens from the Android device and set up user accounts in RHMAP. The code should be easy ish to follow along. The most important part is that we return a userId value in the json which we can use to look up the user’s session informaiton.


The route /list/:session can be used by Cloud applications to fetch a user’s account information which is created and saved after a call to “/auth/init”.

Android Integration

In order to integrate with Android, please follow Google’s Guide for instructions on how to setup an Android account and get an IdToken from a sign in. The FehBot Android client contains a working example.

Once you have a IdToken you can use FH.buildAuthRequest to perform the sign-in with RHMAP. For the three parameters us the Auth Policy name you assigned during “Setup the Auth Policy”, the IdToken you retrived from Google, and an empty string for the final parameter. Here is an example from the FeHBot app.


As per the RHMAP Authentication API if you use this you will have to manually verify your sessions in your application yourself. The built in verification methods will not work.


As you can see, it is easy to add a third party authentication mechanism to RHMAP. The principles in this post can be applied to many other authentication providers and client platforms.