The team at Ksubaka implemented Stormpath earlier this year. We’re excited to share this post on their experiences from Ksubaka DevOps Lead Phil Hendren.
Here at Ksubaka we’ve been using Stormpath for identity management in Java since the beginning of 2016, but what is Ksubaka? Ksubaka is media network that links brands to consumers in high footfall retail environments.
We’ve currently rolled more than 6,000 interactive kiosks in 1000 retail stores across 90 cities and in every province in China. This means our network engages directly with over 10 million shoppers every month, for brands that include Coca-Cola, Colgate, Head & Shoulders, Kellogg’s and many others
The goal of the media network is to connect consumers with brands closer to the physical point of purchase, in-store. Our interactive kiosks, called ‘playSpots’, provide mini-games that take the consumer on a branded game journey. To support this network we’ve had to build a system that can manage these playSpots over-the-air, primarily using public cellular networks.
Through this system, we’re able to provision new games or update core software components in a matter of minutes from our backend systems running in the public Cloud. Branded campaigns can be edited post-deployment to optimize their exposure for our clients and these changes can also be delivered to the entire network or strictly targeted playSpots.
Achieving this is not without technical challenges, one of which was how we would allow the necessary engineers access to the tools required to manage the network from a technical point-of-view. This was especially important to us as we rolled out in China as many of these engineering staff could be transient. We needed to have a means of protecting our tools with a role-based system, and we needed to deploy it as rapidly as possible.
We first learnt about Stormpath when we started looking for Identity-As-Service providers. Although our initial use-case was very much around protecting some public-facing Internet services with a role-based layer, we were also interested in providers that offered other features such as SSO, OAuth, and Social Login for potential future uses, so we cast our search quite wide.
The criteria we worked towards that the solution had to provide us with token authentication and authorization; have a REST API; provide well-maintained and working libraries for integration with popular development stacks, in our case Java and Python; and most importantly, provide easy and rapid integration.
Stormpath was an ideal fit for us because it allowed us to create a new directory quickly without having to worry about the operational cost of maintaining a similar directory with something like LDAP, along with the advantage gained from the different SDKs available in different languages.
From start to finish it took us no more than a matter of hours to have Stormpath fully integrated with our target Java application in our non-production environments, and then, once QA was passed we pushed it to production and it’s worked well.
Recently, we started it using Stormpath to provide similar protection for some internal tools we use that have be written using the Flask-framework for Python. As with the Java integration, we were up and running in minutes with a fully authenticated application.
Since deploying to production we’ve only had to speak to Support once, in July, and they were quick to respond to us with the information we needed.
If you’re looking to deploy an authentication/authorization layer in front of your service and you need to do it rapidly, Stormpath is definitely worth consideration.
Thanks Phil and Team Ksubaka!
Interested in learning more about user authentication and identity management with Stormpath? Check out these awesome resources: