Author: CallanHP

So, the other day I found myself having to connect to a server with self-signed SSL certificates while writing Nashorn Javascript. The precise details of how I found myself in this situation are pretty unimportant (I was re-writing an ant build script which had to obtain a build parameter by querying a running instance of a server in dev…), but the problem was suitably esoteric that I couldn’t find a code snippet with a quick search, while probably not being so esoteric that I am the only one who will ever need this, and hence, this post.

Much has been written on the design of ideal REST APIs, from Roy Fielding’s original description of HATEOAS interfaces, to much more practical approaches mirroring APIs rolled out by large technology companies. When working alone, I have a lot of freedom in how I design and build my APIs, and I always strive to design APIs which I would love to consume, based upon a number of undocumented, but strongly-held design intuitions. Collections are plurals; sub-objects are used sparingly, and mostly for practical considerations like payload size; HTTP status codes are used appropriately for particular types of errors and responses; etc.

When I work as part of a larger team, I often find that we end up building interfaces with slight inconsistencies, even if the design of them was based upon some documented high-level design principles. These inconsistencies impact the productivity of both internal and external developers which have to use these APIs, as they have to carefully parse the documentation to develop around the ‘quirks’ of the individual APIs.

Ironing out these inconsistencies can be achieved in a couple of ways, adopting a waterfall-style development model, in which each team is required to submit their detailed design specifications to an architecture council for review and sign-off; or putting a system in place which checks new API designs for consistency, and provides real-time feedback to API designers as they sketch out the interface. Oddly enough, the approach that I am going to discuss in this blog post is not the former; instead we are going to explore the Style Guide capabilities offered by Apiary.io, which allows us to develop rules governing API styles, which are assessed in real-time during API design.

Previously in this series we have examined what is required on an Access Management side in order to support a micro-services architecture, providing services for authentication, user management, assurance, etc. In this post, we expand the scope, looking at how to enable new services to easily implement access and authorisation appropriately, as well as a discussion about how they can authenticate to each other. Ultimately the creation of a secure system involves security of all parts, not just the access management services which facilitate it, and so this post focuses upon working towards enabling that. Security is also built upon organisational culture, and while it is a little difficult to instil that through a blog post, taking steps to create a technical foundation which allows the Access Management teams to be open and collaborative instead of being the team that says ‘no’ is unlikely hinder such cultural development.

Continuing from the previous post which dealt with the core concepts around performing authentication and authorisation in a distributed environment, this post expands upon those concepts, looking at additional factors for authorisation decisions, including supplementary information, authentication challenges and risk assessment. While basic authentication and authorisation requirements can be met through the use of JWTs and OAuth, this post shifts to tackling bespoke requirements, outlining potential services which could provide capabilities above and beyond what is captured in those standards.

In the previous post in this series we examined at a high-level how responsibilities for authentication and authorisation are distributed in a micro-services architecture. In this post, the strategies and technologies that underpin the implementation of authentication and authorisation will be explored further, with the core access management services providing authentication services, which support individual services performing authorisation. This discussion is actually split across two posts, as authentication and authorisation are core parts of the access management services, and require extensive discussion, with this post focusing upon the core capabilities, and the following post focussing upon more advanced authentication and authorisation requirements.

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.

Like this:

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.

Blogroll

RedThunder.blog and contributors. All Rights Reserved. The views expressed in this blog are our own and do not necessarily reflect the views of Oracle Corporation. All content is provided on an ‘as is’ basis, without warranties or conditions of any kind, either express or implied, including, without limitation, any warranties or conditions of title, non-infringement, merchantability, or fitness for a particular purpose. You are solely responsible for determining the appropriateness of using or redistributing and assume any risks.

Follow Blog via Email

Enter your email address to follow this blog and receive notifications of new posts by email.