Between the Oracle Cloud Infrastructure (OCI) Audit Service recording administrative operations and Oracle Identity Cloud Service (IDCS) tracking access and user management events, Oracle Cloud provides pretty comprehensive tracking of security events. Recently however, I have been in conversations with a number of organisations who have been seeking longer term retention of audit events for several different reasons, including governance, compliance and forensic requirements. The OCI Audit service supports requesting bulk export of audit events to Object Storage, which allows you manage the retention and archiving of those events yourself, so I started wondering if I could do the same for the IDCS access events. A bit of testing and some simple coding later, and I had events being pulled directly from the IDCS Audit Events API periodically and sent to Object Storage for retention.
In this blog post, I will provide this code as a sample, and discuss some of the techniques and technologies that are available in Oracle Cloud Infrastructure to enable simple, but highly secure and cost-effective, automation of cross-service tasks such as this.
Continue reading “Simple, Secure Log Retention using OCI Services”
Oracle Cloud Infrastructure provides a ton of useful services for automating and orchestrating behaviours in your cloud environment, and while they are often pretty handy on their own, leveraging them together gives almost complete flexibility on what you can achieve. Want to trigger a backup using a command in slack, then have a message get sent back when it completes? Sure! Want to periodically poll a log API and archive the results? Easy. Oracle Cloud Infrastructure provides a number of inbuilt capabilities, as well as the ability to jump into arbitrary code to build elaborate automation flows, and this blog post will focus upon the security constructs around this, looking at how services can be authorised to invoke one another, as well as how they authenticate themselves, while avoiding storing sensitive data in insecure ways. This post is intended as an overview of the concepts, and will be referenced in more concrete ways in future.
Continue reading “Secure Inter-Service Communication in OCI”
Version 1.0.0 of the Consumer Data Right standard was released in September, and it introduces a common set of Banking APIs in line with Australian government legislation. The principles behind the standards design are very solid, though the some of the specific requirements are pretty wild and they result in a bit of rethinking of some of the classical API conventions. The most prominent example of this is the approach the CDR standards take towards ‘object identifiers’, in the ID Permanence section, and I considered the requirements for this interesting enough to spend some time thinking about and documenting.
In this context, an ‘object identifier’ refers to the way in
which you refer to an individual instance of an object from your API, such as
the ‘accountId’ in the following URI:
In this blog post we will look at what the CDR requires for these types of identifiers, and provide some sample code which implements the obfuscation requirements specified in the standard.
Continue reading “Consumer Data Right (CDR) – User-specific Identifiers for ID Permanence”
Oracle PaaS services are typically protected by Identity Cloud Service (IDCS), which provides unified access management for the Oracle Cloud. This protection extends to their exposed APIs, which usually require you to present a valid access token as part of your invocation. Unfortunately, the documentation for a number of the services tends to assume that the reader has an in-depth knowledge of OAuth concepts, and IDCS operations.
Typically my blog posts are around specific proof of concept things I have been working on, or go in-depth into more advanced IDCS concepts, but I have realised (mostly because people kept asking me…) that many developers using these services don’t have a strong practical understanding of OAuth, and struggle to interpret the documentation around the authentication requirements for the services. This blog post is designed to provide a step by step explanation of what is required from an IDCS perspective, as well as an explanation of the techniques to obtain a an access token to use the service APIs.
A non-exhaustive list of PaaS services for which these instructions
Continue reading “Invoking Oracle PaaS service APIs protected by OAuth”
- Oracle Integration Cloud
- Oracle Blockchain Platform
- Oracle API Platform Cloud Service
- Oracle Mobile Hub
- Oracle Digital Assistant
Oracle’s Cloud Infrastructure has been designed in an API-first manner, which is awesome for all sorts of infrastructure automation tasks. It also implements an interesting API security model, in which all requests must be signed using a private key, associated with a public key which has already been configured in OCI (here, the developers are showing their infrastructure roots, as this echoes how SSH Auth is normally handled). The documentation of this model provides sample code in a number of languages, which is perfect if you are writing automation scripts, but is a little inflexible for ad-hoc testing. Typically I much prefer to use a rich graphical REST client, such a Postman, so that I can easily tweak my parameters and try out different types of calls before I write any code. Unfortunately while Postman is well equipped for Basic and Token based Auth, HTTP-Signature is not natively implemented, and rather than abandon Postman for a new tool, I set out to implement it using Postman’s powerful scripting capabilities. In this blog post I provide the result of this, which is a downloadable collection which provides all of the required scripts, and discuss the approach used.
Continue reading “Calling OCI APIs from Postman”
Hashed Timelock Agreements, or Contracts, have emerged as an important concept in the cryptocurrency space in order to perform transactions across ledgers – and I feel could be a valid mechanism to handle the issue of performing verifiable cross-channel transactions in Hyperledger in some use cases. The basic concept of a Hashed Timelock Agreement (HTLA) is that it allows for a conditional transaction (which I have deemed a ‘proposal’) with a cryptographic challenge which ensures it can only be completed by a pre-defined party. This can be chained through multiple intermediaries, which can enable two organisations who do not share a channel to interact, and for transactions to be confirmed across channels.
Continue reading “Hashed Timelock Agreements in Hyperledger Fabric”
In a recent blog post, I added a throwaway reference to the use of signed assertions as a better mechanism for interacting with the Oracle Identity Cloud Service REST APIs than the use of Client id/secret, though qualified it with ‘if you want to handle the additional complexity in your consuming client’. Reflecting upon this, I thought that perhaps it was worth trying to explain this ‘additional complexity’, since the use of signed assertions have a number of benefits; primarily that it does not require an exchange of sensitive information, as the private keys used to sign the assertion never need to leave the machine on which they are generated. In this blog post, I will delve deeper into what is required to leverage this authentication mechanism, for both clients and users.
Continue reading “Using Public/Private Key Authentication for Oracle IDCS”
Oracle’s Identity Cloud Service is typically associated with its role in acting as the primary identity store for Oracle’s Cloud services – acting as the gatekeeper for administrators and developers, and providing single-sign-on across Oracle services for end users. However, thanks to its API-first design, it is also very capable of acting as a headless OAuth server and user store, providing authenticated access to custom applications and APIs. When these custom applications are customer facing, you will want fine-grained control over your user experience, without them interacting with IDCS directly. In this post we will explore implementing custom user activation and password reset flows; which provides the opportunity to implement pixel perfect UIs, modify the flows for different classes of users, or just do whatever your custom application requires.
Continue reading “Custom User Activation and Password Reset Flows in Oracle IDCS”
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.
Continue reading “API Design Governance – Style Guides in Apiary”