Adding security over the APIs across multiple layers was something that we considered when putting this project together. This perspective was reinforced at the #DigitalDefence hackathon in Nov 2020. Check out what happened (here).
Here we will focus on the different REST APIs exposing the data hosted by Autonomous Data Warehouse. We started off with HTTP Basic Authentication but quickly turned to using OAuth. Here we’ll explore more about the OAuth side and how to get that started.
It was fantastic to see / hear / participate in the closing ceremony of the #DigitalDefence Hackathon 2020. If you want to check the whole ceremony including some of locknotes, check it out here.
It was great to see who won but also from the judging perspective, who else was in the Top 11 (yes 11, not 10) where we worked with our executive team including Cherie Ryan, Vice President at Oracle and our Regional Managing Director of Australia and New Zealand to pick the winners.
It’s almost 9 days before the event launches on the Friday night. Even before that, there are a series of workshops / webinars that we are hosting as part of the event in the days leading up to the event. Even then we are:
a/ Making sure that we have people, mentors, marketing, product managers, executives lined up to help where they can. b/ Making sure that we have ideas, platforms, trials, programs, education material lined up to help where it’s feasible. c/ Making sure that we help promote, advocate, market the event so those who would benefit would know about the event and attend.
All this effort for what outcome?
This says it all. And even though this is about #anomalydetection #deepfake #cybersecurity, much of this comes down to data – where the data can be sourced, how the data can be analysed, is the data reliable and can it be trusted.
Over the coming days leading up to the event – there will be plenty of chatter around it. Follow the event on LinkedIn. Some easy ways to follow are:
I’ll be writing more about it here as we go and as new content is available. If you are interested to know or more if you want to join a team or showcase a project or product – head to the Hackmakers website https://hackmakers.com/ to learn more and register.
Oracle Cloud Infrastructure provides a ton of useful services for automating and orchestrating behaviours in your cloud environment, and while they are often pretty handy on their own, leveraging them together gives almost complete flexibility on what you can achieve. Want to trigger a backup using a command in slack, then have a message get sent back when it completes? Sure! Want to periodically poll a log API and archive the results? Easy. Oracle Cloud Infrastructure provides a number of inbuilt capabilities, as well as the ability to jump into arbitrary code to build elaborate automation flows, and this blog post will focus upon the security constructs around this, looking at how services can be authorised to invoke one another, as well as how they authenticate themselves, while avoiding storing sensitive data in insecure ways. This post is intended as an overview of the concepts, and will be referenced in more concrete ways in future.
Version 1.0.0 of the Consumer Data Right standard was released in September, and it introduces a common set of Banking APIs in line with Australian government legislation. The principles behind the standards design are very solid, though the some of the specific requirements are pretty wild and they result in a bit of rethinking of some of the classical API conventions. The most prominent example of this is the approach the CDR standards take towards ‘object identifiers’, in the ID Permanence section, and I considered the requirements for this interesting enough to spend some time thinking about and documenting.
In this context, an ‘object identifier’ refers to the way in
which you refer to an individual instance of an object from your API, such as
the ‘accountId’ in the following URI:
In this blog post we will look at what the CDR requires for these types of identifiers, and provide some sample code which implements the obfuscation requirements specified in the standard.
Oracle recently introduced a Web Application Firewall (WAF) to further enhance and secure Oracle Cloud Infrastructure offerings. The Oracle Cloud Infrastructure WAF is based on Oracle Zenedge and Oracle Dyn technologies. It inspects all traffic destined to your web application origin and identifies and blocks all malicious traffic. The WAF offers the following tools, which can be used on any website, regardless of where it is being hosted:
Over 250 robust protection rules that include the OWASP rulesets to protect against SQL injection, cross-site scripting, HTML injection, and more
In this post, I configure a set of access control WAF policies to a website. Access control defines explicit actions for requests that meet conditions based on URI, request headers, client IP address, or countries and regions.
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.
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?
Who doesn’t like the security. This is one of critical element of our IT Infrastructure. Recently I was doing one POC and got requirement to setup a valid SSL certificate in Weblogic. However, since it was just an POC we were not having any valid SSL certificate issued by some Certificate Authority. Later, I came across for one website called https://letsencrypt.org/ . Let’s Encrypt is a free, automated, and open certificate authority (CA). they give people the digital certificates they need in order to enable HTTPS (SSL/TLS) for websites, and its free, yes you heard correctly It’s FREE !!!. You don’t need to pay them at all. So if you need a valid SSL certificate for your POC or even for Production environment you can get one from them. Although their certificate comes with 3 month validity, so while using for Production environment user need to keep renewing with them with simple automated process.
In this blog we will be learning how we can generate letsencrypt SSL certificate, what’s prerequisite to get the certificate and setup that certificate in Weblogic server to enable SSL communication.
So, Lets move on. We will be doing below stuff in sequence –
Get a registered domain name (This required while generating SSL Cert)
Install Certbot ACME Tool and Apache HTTP Server
Generate Letsencrypt SSL Certificate
Configure Letsencrypt SSL in Weblogic Identity Store