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.
Majority of the websites have FAQ pages, and they are always dull. If only you could convert your FAQ to something more tangible that solves the users need you could resolve customer frustration of finding the right information. Moreover, if that experience is more interactive, it leads to an engaging experience where you can contextualise the data and also execute the task on behalf of the customer. We can create this rich experience by making your traditional FAQ’s wrapped inside a chatbot.
In this article let’s have a look at how we can quickly convert FAQ Pages to a Bot in minutes. Oracle’s natural language understanding technology and QnA engine available in Digital Assistant platform can sift through the historical FAQ data and answer even sophisticated requests from your clients. Further, you can handover complex queries to your support as I discussed in an earlier article
In earlier articles, I discussed Autonomous Digital Assistant, provisioning a Digital Assistant, building skills and making it multi-lingual. In this post, I would like to take the discussion forward to address certain scenarios where there is a need for Human Intervention when the Bot cannot handle the conversation and instead redirect the chat to a human agent.