 Hi. In this video we'll demonstrate how Red Hat Mobile running on OpenShift can integrate with a third-party product. We'll be integrating our Red Hat Mobile project with InterSeed's RAPID product. This will enable us to have two-way TLS in our mobile API. InterSeed's RAPID product is the mobile-focused extension of their MyID product. RAPID provides certificate management capabilities that can be integrated into mobile solutions. You can get an overview of this process from their documentation as shown. The solution we create as part of this video is architected as shown in the diagram. Red Hat Mobile is deployed on OpenShift in a typical configuration. But we'll be modifying the inbound route, so traffic will be routed via an Apache proxy that validates certificates being presented by the mobile device. This is done so we establish a two-way TLS session. To get started we'll create a new application on our RH map instance. We'll be using the Hello World template project, so choose that and give your project a name. Once you've named your project, ensure the cloud app and Cordova app checkboxes are ticked, then click create. The create process can take a while, so we fast-forwarded it here. Awesome! Now we've got a project that's ready to go, so click the center column to view our Node.js cloud app. You'll see from the detailed screen that it's not deployed yet, but we'll get back to that soon. Click the editor tab and open application.js. This is our entry point script. We're going to enforce two-way TLS just for our Hello World JSON API in this example, so nest it under slash API. Next we'll add a login endpoint, so add an app.post and use the URL auth slash login. Now to find a handler, you can implement this using a dummy function for this demo, so long as it generates an anonymous ID for a given username. It also must return a request ID upon success to satisfy RAPID requirements. Here's the login handler I implemented. It verifies the username and password. If those are valid, we get an existing or generate a new anonymous ID for the given username. We then request an identity from RAPID and return the ID of the identity request to the mobile device as a JSON payload. Now that we have a login endpoint, we can deploy our application. Deploying will create a Node.js container image that bundles our Node.js code. It'll deploy that container image on OpenShift and create a public route to access our API. The deploy process takes a while, so we sped things up a little here. Once the deploy completes, you can go to the detailed screen in RHMap and use the public URL of your application to check if it's running as expected. Now that we have our Node.js code deployed on Red Hat Mobile, it's time to create the Apache HTTP server to verify two ATLS sessions. The RAPID documentation explains how to configure Apache and generate self-sign certificates if necessary. Since I'm developing locally on my machine, I'll generate self-sign certificates now. Using OpenSSL commands provided by the RAPID documentation, we can get started. I've sped things up here since you can copy and paste these commands from the RAPID documentation. One important point of note though is that you'll need to provide the fully qualified domain name of your application when entering these commands. This is the URL that you found earlier. You can also find it from this OpenShift dashboard. Once you've got this URL, drop the prefix of HTTPS and paste it in when issuing the command to generate the certificate signing request. Once you've generated your HTTPS cert, head over to the RAPID portal and download your trusted issuer certificate. Now that we have our trusted issuer certificate from RAPID and our self-signed HTTPS cert, we'll need a directory structure similar to the one shown here. It contains a Dockerfile. The Dockerfile is a manifest that describes how our container image should be built. We're creating an image based on Red Hat's REL and it's running HTTPD 2.4. We copy our cert's WW content and a configuration file into the container. It's worth noting that OpenShift has features for managing certificates and configurations, but we're not using those right now. This is because we want to keep this demo as simple as possible. An important file that we need to update is the Apache HTTP configuration. We need to make some modifications to it to enable two ATLS. Here you can see I've made those changes to the file that's bundled with the Red Hat Apache image. These changes require the request sent to slash API enforce verification of the client SSL certificate. I've also allowed all of our endpoints to pass through using standard HTTPS. Now that we have a Dockerfile HTTP configuration, our SSL certs and all the other various parts needed, we can actually build our image locally. Once it's built using the Docker build command, we can then run it using Docker run. Here I'm running it locally and binding the internal port of 8443 to 9443 on my local machine. I'm doing the same with 8080 by binding it to 9090 on my local network. You can verify the container is running by running a Docker PS and checking that the rapid container that I just spun up is there. Then we can actually curl local host. We get back our WW content as expected from port 8080. If we curl port 8443, which remember is 9443 on my local machine, we should be denied. You can see it's telling us that the SSL handshake failed and this is expected behavior. If we try and hit another route on port 8443, you can see that the request goes through. However, we're told the service is unavailable. This is exactly what we'd expect since we haven't set up the service to actually proxy the requests to just yet. Now that we're happy with our image, we need to go back to OpenShift and get the Docker registry URL that can be found in the default project. Copy that and what I'm going to do now is set it as an environment variable on my terminal for use later. Next, we'll log into OpenShift locally using our OC command line. Type OC login, enter your username and password, and then find the project ID that you want to deploy the RAPID proxy in. In our case, that's RHMapRHMapDevelopment. Now we'll set that as an environment variable on our terminal for use later. Next, we're going to log into the Docker registry. To do that, we need to use OC Who Am I dash T to get our login token. Then we can use Docker login, pass the registry URL and our username, and finally pass our token. Once we do that, we can log into the registry and push images. Now we can tag our image, so run Docker tag, give the image name, the registry URL slash the project ID slash the image name. Then you can do a Docker push using the same URL structure. This can take a second, so we sped things up, and once it's done, we can head over to OpenShift. Back in OpenShift, the first thing we need to do is get the service hostname of our Node.js cloud app. So head to applications, services, find the hostname and copy it to your clipboard. Now choose add to project and deploy image. From the deploy image screen, choose your project name. The image stream will be your RAPID proxy and then the latest tag. We need to input some environment variables. The first is the RH map host, and that's the service name we just copied, plus a prefix of HTTP. Then we can add a value again, and it's going to be the port of our app. This is usually 8080 or 8001. Then we're ready to deploy. While our image is being deployed, we'll update the public route of our cloud application. Choose applications, routes, and then from the routes screen, find the route that corresponds to your cloud app. Choose it, and then select actions and edit. We want to update the route, so it routes traffic to the RAPID proxy. We also want to make sure it targets to crack port on the proxy, so change it to 8443. And then finally in the security section, change TLS termination to pass-through, so that our proxy becomes responsible for the HTTPS sessions. Now that our route is updated, let's verify it's working as expected. Note the route, then using your favorite HTTP client, make a HTTPS request to it. For now, we'll just hit the normal endpoint, and we can see that it's being served as expected. However, if we hit slash API, you can see we're being denied. That's because we're not presenting a valid SSL cert. Now that our backend is updated, let's work on updating the front end with the RAPID SDK. Copy your Git URL, and then clone the app locally. This is a hybrid app, so I'm cloning it into a folder called client-hybrid. Once the app is cloned, we'll need to CD into the directory, and use the Cordova plugin add command to add the interseed plugin to our app. When adding the plugin, we'll want to pass some extra variables to the add command. The first is the RAPID whitelist. This is a whitelist of URLs that our app can communicate with. So for us, we're going to pass the public URL of our cloud application. The next variable to pass is the RAPID access group identifier. This is the identifier that will be used to store our credentials in the underlying device keychain. Finally, we type dash dash save to save our changes into the appconfig.xml. Once the plugin is added, we're going to open our editor and update the widget ID of our Cordova app so that it represents the same value as the RAPID access group identifier. After this, we'll run Cordova at iOS, since we'll be testing against the iOS platform in this demo. Next, we'll update the index.html and hello.js files of our project. I've included links to two gists that have the code required to do this. So check out the blog post for those links. Now we're ready to open our project in Xcode. In Xcode, make sure you're bundled ID and code signing are set up correctly. Next, head over to capabilities and make sure the keychain sharing is turned on and that the correct group is shown. You should also make sure that your entitlements file is showing the correct keychain access groups. Since we're working locally, you'll also want to make sure your fhconfig.json has been updated with the correct URL and that the local flag is set to true. Once you're ready, you can go ahead and run your app on an iPhone simulator. This can take a while to start up, so we're going to skip ahead. Before testing our application, we need to install our self-signed certificate onto the device. This is to satisfy iOS security requirements. This step is only required for local development, since production applications will be using certificates that have been issued by a trusted certificate authority. We're now ready to use our app, so enter a username and password that will satisfy your login function that you created earlier. Once you're ready, click login, and our app will send our credentials to the auth-slash-login endpoint in our Node.js application. Once our Node.app has verified our credentials, it will return a request ID and the interested SDK will use that to request credentials for our user. We enter a pin to protect those credentials. Once the pin has entered, we'll be logged into the application. Now that we're logged in, we can use the slash-api-slash-hello function in our application. So enter our name, and then press the say hello from the cloud button. When we do this, the interseed SDK will be used to establish a secure 2-way TLS connection with our backend. During this connection, we need to enter our pin to unlock our certificate so the request can be made. Upon a successful request, our name is echoed back. We can also head over to our Node.js dashboard and check the logs to make sure the request succeeded. If we look at the log screen, we can see various logs from our app, but the one we're interested in is at the bottom. This represents the last request we made, and we can see that the name we entered is appearing. And that includes our demo. We used RHMap to deploy a simple mobile JSON API on top of OpenShift. We added a login endpoint that verifies the username and password, then requests the unique credential from RAPID on the behalf of the user. It then returns the credential request ID to the device. We then added a RAPID SDK to our Red Hat Mobile Template application. The application used the Red Hat Mobile SDK to login, and then used the RAPID SDK to collect the user's credentials and establish a 2-way TLS connection with our JSON API.