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.
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.
Earlier today I was given a challenge by my colleagues. Recently Oracle released the Autonomous Data Warehouse and we have a lot of excitement from customers, partners and internal folk alike. This excitement is driving a lot of innovation right now, but that also brings some challenges. The last thing we want is the Marketing team to mess with Finance resources. How do we make sure different teams don’t step on each other’s toes?
As we roll out the Oracle Digital Assitant workshop across Australia and New Zeland over the course of the next few weeks, below are the instructions for the participants interested to try out the platform and build a Digital Assistant.
- If you have registered for the event, you would get an email to set up the password for your Oracle cloud account on the day of the workshop.
- Once you set up the password access Digital Assistant UI to start building your first Digital Assistant.
- Download the hands-on lab material from here that has detailed instructions on how to design and deploy a Digital Assistant.
Here are some interesting links that can compliment your learning process of the Oracle Digital Assitant or if you would like to re-visit them later.
Oracle Digital Assistant Channel: This playlist is dedicated to covering all the major features of Oracle Digital Assitant. You can watch in sequence for an end-to-end insight into Oracle Intelligent Bots, or dip into any video to learn about that features.
Additional Blogs that might help you in your Oracle Digital Assistant learning journey
Leave your comments here if you would need any more information on this topic.