IDCS – RedThunder.Blog

Simple, Secure Log Retention using OCI Services

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.

Access OIC REST based Integrations using an OAuth Client (No Password Expiry For Basic Auth User Anymore) !!!

Oracle Integration Cloud (OIC) is Oracle’s next generation modern Integration solution Platform as a Service (PaaS) offering. The core purpose of this product to integrate various SaaS and On-prem systems real time. In addition to Integration capability, it also provides Process Automation and Visual Builder Capability. Details docs are available here.

OIC has concept of Adapters. There are huge range of adapters available and documented here.

One of the Adapter REST Adapter been used to expose an Integration to outside world for consumption. In order word, it’s an entry point for most of Integrations what we developed using OIC. It also gets used to invoke any external REST based endpoint.

REST Adapter support Basic Auth and various flavour of OAuth as security mechanism to protect the Integration access.

However, not all OAuth flavour supported for Trigger Role (Used as Entry point of Integration) vs Invoke Role (Used for invoking third party REST endpoint).

REST APIs exposed using the REST Adapter (Trigger Role) are protected using Basic Authentication and OAuth token-based authentication.

REST API consumed using the REST Adapter (Invoke Role) Support HTTP Basic Authentication, OAuth Client Credentials (two-legged flow), OAuth Resource Owner Password Credentials (two-legged flow), OAuth Authorization Code Credentials (three-legged flow), OAuth Custom Three Legged Flow, OAuth Custom Two Legged Flow, OAuth 1.0a One Legged Authentication, Amazon Web Services (AWS) Signature Version 4, and Oracle Cloud Infrastructure (OCI) Signature Version 1. There is also support for consuming APIs that are unprotected.

Now, majority of Customers chose Basic AUTH while publishing an Integration because it’s very simply to implement but has limitation because the user password gets expired in every 3 month which result changing all Integrations configuration again in 3 month of time. We can very well avoid this problem by Implementing OAuth token which never gets expired.

Oracle has official document for setting up Service Account without expiry but it’s quite difficult to follow instructions from that document. Hence, I thought to publish more user friendly instructions to achieve the same outcome.

In this blog, I will be covering how we can invoke an Integration exposed using REST Adapter (Trigger role) using OAuth token which doesn’t get expired.

Continue reading “Access OIC REST based Integrations using an OAuth Client (No Password Expiry For Basic Auth User Anymore) !!!”

Invoking Oracle PaaS service APIs protected by OAuth

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 are applicable:

Oracle Integration Cloud
Oracle Blockchain Platform
Oracle API Platform Cloud Service
Oracle Mobile Hub
Oracle Digital Assistant

Using Public/Private Key Authentication for Oracle IDCS

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”

Custom User Activation and Password Reset Flows in 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”

Making access easy but secure

So following on from my earlier article, Policies let your teams play safe, I have been given another challenge: Can we give our users single sign on now that each team can play safely in their own Oracle Cloud Infrastructure compartments?

Single sign on delivers a number of really important benefits. Firstly, the user experience is much smoother and seamless as users don’t get prompted for multiple passwords and don’t have to remember even more passwords. More importantly, single sign on eliminates the need to manage multiple stores of identities. This can be a big overhead for administrators and sometimes open up additional risks. Finally, an enterprise wide identity solution can often provide additional capabilities can be leveraged by your Oracle Cloud Infrastructure.

Continue reading “Making access easy but secure”