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.
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.
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.