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.
In the previous article, I mentioned how we can Dockerise a progressive framework based application (Vue). I have made few improvements to the application where I am now able to perform CRUD operations on the client side using AXIOS, based on API’s available from the server side. I wanted to test these incremental features added to the application and imagine executing those docker commands everytime you make a new component/feature available. This is quite a task. So I was looking at ways to automate the task where every time I commit/push the code to GitHub the build happens automatically so that the latest container is ready for deployment. This is where Docker Hub comes to our rescue. Here are the steps for the automated build process:
Now days with the adoption of Serverless architectures, microservices are becoming a great way to breakdown problem into smaller pieces. One situation that is common to find, is multiple backend services running on technologies like NodeJS, Python, Go, etc. that need to be accessible via HTTPS. It is possible to enable these internal microservices directly with SSL over HTTPS, but a cleaner approach is to use a reverse proxy that front ends these microservices and provides a single HTTPS access channel, allowing a simple internal routing.
In this blog, I am showing how simple it is to create this front end with Nginx and leveraging “Let’s encrypt” to generate trusted certificates attached to it, with strong security policies, so that our website can score an A+ on cryptographic SSL tests conducted by third party organizations.
In this post, I am going to show how to build and containerize a Vue.js application and let it run on Container Cloud Service (OCCS) using the following steps:
- Build a Vue.js Web App
- Build Docker image based on the above Vue.js SPA
- Push it on Docker-Hub
- Create a Service in Oracle Container Cloud Service (OCCS)
- Deploy Service (the vue.js app)
Modern Integrations require touching lots of different APIs coming from multiple “systems”. These “systems” can be big enterprise backend applications, such as: E-Business Suite, SAP, JDE, Siebel, etc. As well as modern SaaS Applications, such as: Service Cloud, ERP Cloud, Salesforce, Netsuite, Workday, etc. These “systems” can also be other smaller or custom applications running either on premise or in the cloud exposing either SOAP or REST services.
Rarely any of these “systems” can provide solid abilities to remotely expose APIs in a way that are tailored for a specific business case. Commonly, to achieve this, we need a separate integration layer that orchestrates APIs from multiple “systems” and easily obtain the desired business outcome, in a way that they are also reusable APIs to be utilise in other business scenarios. Furthermore, in order to properly apply security measures and effectively protect these APIs and safely expose them to external consumers (potentially in the public Internet), normally we need to use an API Gateway (see this blog to learn how).
Also, in previous blogs, John Graves showed us how to automate the creation and deployment of existing “internal Integration APIs” and expose them as secured external APIs using Oracle API Platform. (See ICS to API Platform and Oracle Service Bus to API Platform).
If we take the same automation concept, we can then apply it in a DevOps scenario, where we want to achieve the following: