An ongoing trend, as organisations increasingly adopt cloud-native development approaches, is from centralised services, to widely distributed services. This shift requires a rethink about how access management is delivered, in terms of aligning with this model in development practice, as well as accommodating the radical effect that this has on deployment architecture. I have previously alluded to this shift as being from ‘perimeter-based access management’ to ‘centralised access management’, and how this is able to accommodate the increasing adoption of distributed infrastructure and services.
I initially began writing a post which would explore this concept in more detail, though it quickly grew beyond what could be easily captured within a single post. As a result, in order to give the topic justice, I will break this into a number of posts, beginning, in this post, by exploring what Access Management even looks like in this sort of architecture, then going into more detail about strategies for implementing a micro-services approach to access management.
Continue reading “Access Management and Micro-services – Part 1: Overview”
There are no shortage of acronyms in the security space, and shifting towards centralised-security, rather than perimeter-based-security, has added even more. As I have been playing with solutions around centralised identity services, such as Oracle’s Identity Cloud Service, I have found myself spending more and more time in IETF RFCs in order to understand these concepts. While there is a lot of value in the standards documents, they assume a lot of knowledge and I often found myself wishing for a slightly more approachable, high level description of the elements I was dealing with. While there is something tempting about being part of the secret ‘We read the security RFCs’ club, I resisted this, and took it upon myself to provide this higher level overview of these important concepts.
Continue reading “JWTs? JWKs? ‘kid’s? ‘x5t’s? Oh my!”
The May 2017 update for ACCS (17.2.3) brought a cool new feature to ACCS, zero-downtime updates. While previously, there was support for performing a rolling restart of an application instance, where each instance would be brought down and updated in turn, this only enabled zero-downtime updates if you had an application running two or more instances, and your application could satisfy performance requirements with one fewer node. While any production system should be able to satisfy these requirements, many of the utility systems I ran were on a single node, and I had to send out an email blast to avoid being disruptive when I wanted to push a quick code fix.
Continue reading “ACCS Zero Downtime Updates and Re-Deployments”
Throughout my development experience, I feel that I have had several major bursts-of-learning, due to problems which have made me re-evaluate how I approach architecting and developing a solution. I feel these ultimately make me better as a programmer, or at the very least, more versatile. I am sure some of these bouts of learning and understanding are near universal, experienced by most developers, such as understanding parallelisation, but others are somewhat more specialised, such as when I first started writing games, where having to take 60+ snapshots of a continuously evolving environment every second completely changed how I thought about performance and accuracy. Developing Cloud-Native applications (and indeed micro-service based applications, which share very similar principles) feels as though it is one of these moments in my development experience, and I feel it might be interesting to reflect upon that learning process.
I see the problem statement for Cloud-Native applications as something akin to: ‘you have no idea how many instances of your application will be running, you have no idea where they will be in relation to one another and you have no idea which one will be hit for any particular call’. That is a lot of unknowns to account for in your code, and forces you to think very carefully about how you architect and develop your applications.
Continue reading “Learning How to Write Cloud Native Apps”
Try though we might to shift everything to a glorious set of stateless services, there are still plenty of scenarios in which an application might need to store some state, commonly to track some information about a user and that user’s session. In these cases, an in-memory cache is a powerful addition to an application, and is nearly indispensable to an elastic cloud architected app which is expected to be able to scale horizontally on-demand, to allow information to be shared between application instances, avoiding the need for load balancer complexity to implement sticky-sessions. Application Container Cloud Service added the ability for applications to add a Caching Service binding in the 17.1.1 drop, and in this blog post we will explore how to leverage this capability in a Node.js application.
Continue reading “Developing with ACCS Caching Services”
Reading Alessia’s recent post about her experiments with beacons reminded me of a post that I have been meaning to write for a while, regarding my previous dabbling with building location-aware applications. Beacons are a powerful tool by which to provide fine-grained location services to applications, but need to be used carefully, and really need to be part of a larger mix of technologies in order to provide the richest experiences. In this post, I will look at the weaknesses I have previously encountered using beacons, and outline some of the strategies I have used to mitigate those weaknesses.
Continue reading “Reflections on making Mobile-Applications Location Aware”
OAuth 2.0 is an awesome standard. It has made it much easier to discuss standard security flows, uses gloriously simple REST APIs and provides a very robust mechanism by which to provide third-party authorisation. Unfortunately, while the third party authorisation mechanisms are great for web clients, the fact that they rely upon browser redirects or collecting credentials in order to use the Resource Owner Password flow make them less awesome for third parties who are delivering API-driven experiences via mobile apps or smart devices.
In this scenario, we are looking for a mechanism by which we can provide informed consent to resource owners; doesn’t risk exposing user credentials to third parties; and can be API-driven for the third-party, not relying upon browser behaviour. In this post we will explore an approach that checks all of these boxes, something that I have called an ‘Out-of-band Consent’, in which credentials and consent are handled through a process which is entirely removed from the third-party requesting application.
Continue reading “3-Legged OAuth for Non-Web Clients”