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.
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.
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.
In today’s environment where systems run in the cloud and so much business and personal activity occurs online, passwords are not strong enough by themselves to protect applications. Scandals about password breaches seem to happen on a regular basis. It’s easy to find many case studies where passwords have been compromised as a result of malware, email scams and other techniques. The key point is that no matter how strong our passwords, no matter how much we educate our users, there will be situations where people are caught off guard and click on the wrong link, look at the wrong email or open the wrong document. Once this happens, our passwords can be compromised.