Guest Blog: Five considerations for OCI IAM in IDCS-migrated tenancies

This is a guest IAM blog written by OCI Security expert Paul Toal.

Oracle Cloud Infrastructure (OCI) comes with its own, enterprise-class Identity and Access Management (IAM) service, which is used to manage users and their permissions within OCI. It can also be used for managing access to resources, applications, and services outside OCI, including on-premises. If you have been using OCI for some time, you may be familiar with Identity Cloud Service (IDCS) and how it was used to layer additional IAM capabilities over the core OCI IAM service. The capabilities from IDCS have now been merged into OCI through the introduction of OCI IAM Identity Domains, meaning IDCS no longer exists as a separate service. There is a great FAQ posted to answer many common questions about this change, including why Oracle has made the change and the benefits of this change.

Oracle has recently undergone the process of automatically migrating all existing OCI customer tenancies from IDCS to identity domains. In this article, we will examine the implications of the migration and the best practices following a tenancy IAM migration.

Continue reading “Guest Blog: Five considerations for OCI IAM in IDCS-migrated tenancies”

#BuildWithAI 2021 Team Tribute

#BuildWithAI Hackathon 2021 comes at a different point in time. Last year it was a little of an unknown. This is the second year that this event has been run and there was more of an understanding about what to expect and who might be participating.

As like last time, it is a privilege to write this article as there has been significant effort to get to these outcomes. If all I do is to highlight those that have been generous with their time, knowledge and willingness to participate, then it is a service that I will do every time. Here is a recount of some of the teams that participated at the #BuildWithAI Hackathon 2021 (and who were the winners).

This is a tribute.

The one ask that I do have for those is to connect. Connect with the problem; connect with the team and make this tribute more than an article but a way to #BuildWithAI.

Continue reading “#BuildWithAI 2021 Team Tribute”

#BuildWithAI 2021 – Another Step

Last weekend (from Friday 29th Oct to Tuesday 2nd Nov), was the #BuildWithAI Hackathon 2021 where participants, mentors, sponsors and organisers gathered together to solve real world challenges with AI. This event does not standalone. In a world full of change, this (from my perspective) started last year in the #BuildWithAI Hackathon 2020 and continued to build.

This article is about the event but the event itself is just “Another Step”.

Continue reading “#BuildWithAI 2021 – Another Step”

Not Just Another Workshop

In closing out 2020 and before going on leave, I was given an opportunity (never a challenge). And it came in the form of these Oracle Code Cards. For those that haven’t seen them, this is what they look like and here is a git repository of some code explaining more about the cards themselves that I’m revamping – https://github.com/jlowe000/codecard.

An trial using the Oracle Code Card before the workshop.

The outcome required was as open as I could get.

There were no boundaries and there were no specific rules.

Continue reading “Not Just Another Workshop”

#DigitalDefence – The Infinite Game

Last weekend saw over 2,000 people participate in the #DigitalDefence Hackathon hosted by Hackmakers, Oracle as the lead sponsor plus a vast range of other sponsors – ITIC, AustCyber, NASSCOM CoE, Cyber Security Centre of Excellence, IBM and community partners – Public Sector Network, Slack, Black Nova Group, Yirigaa, UNSW DataSoc, SLASSCOM, DataCated Academy and DataEthics4all.

This event was off the back on #BuildWithAI Hackathon hosted by Hackmakers. Being a contributor to that event as a Lead Mentor, Sponsor and a Challenge Organiser, there was something there that resulted from what we were able to deliver – another step in the infinite game. (Note – I haven’t read the book, I don’t follow Simon Sinek however from different communities and framework where we focus on growth mindsets, long tail and talking about your why – this is another example of that same conversation).

This is another step in the infinite game.

Continue reading “#DigitalDefence – The Infinite Game”

API Design Governance – Style Guides in Apiary

Much has been written on the design of ideal REST APIs, from Roy Fielding’s original description of HATEOAS interfaces, to much more practical approaches mirroring APIs rolled out by large technology companies. When working alone, I have a lot of freedom in how I design and build my APIs, and I always strive to design APIs which I would love to consume, based upon a number of undocumented, but strongly-held design intuitions. Collections are plurals; sub-objects are used sparingly, and mostly for practical considerations like payload size; HTTP status codes are used appropriately for particular types of errors and responses; etc.

When I work as part of a larger team, I often find that we end up building interfaces with slight inconsistencies, even if the design of them was based upon some documented high-level design principles. These inconsistencies impact the productivity of both internal and external developers which have to use these APIs, as they have to carefully parse the documentation to develop around the ‘quirks’ of the individual APIs.

Ironing out these inconsistencies can be achieved in a couple of ways, adopting a waterfall-style development model, in which each team is required to submit their detailed design specifications to an architecture council for review and sign-off; or putting a system in place which checks new API designs for consistency, and provides real-time feedback to API designers as they sketch out the interface. Oddly enough, the approach that I am going to discuss in this blog post is not the former; instead we are going to explore the Style Guide capabilities offered by Apiary.io, which allows us to develop rules governing API styles, which are assessed in real-time during API design.

Continue reading “API Design Governance – Style Guides in Apiary”

Teaching How to Design and Secure an API with Oracle API Platform

This blog is the second part of an end-to-end exercise that starts explaining the steps to clone a GitHub repository that contains an agnostic Medical Records application, built by us in NodeJS and which exposes REST API endpoints via a Swagger API-descriptor running locally on Swagger UI (all included as part of the repository). The previous part of this 2-blogs series also explains the steps required to run the MedRec NodeJS application on Docker containers either locally or in the Oracle Public Cloud. For more information about this first part, go here.

Moving to this second part, we are going to cover the following steps:

  1. Create an Apiary account used to Design APIs (API First approach) and create a new API Project using the existing MedRec Swagger API-definition.
  2. We are going to spend a little bit of time playing with Apiary to feel comfortable in areas such as:
    1. Validating API definitions
    2. Testing API endpoints
    3. Switching across out-of-the-box Mock Servers and real Production MedRec service end-points.
  3. Login to Oracle API Platform and configure an API, this includes:
    1. Enforcing Security and other policies.
    2. Deploy API and securing access level to on-premise and Cloud-based API Gateways.
    3. Publishing APIs into the API Developers Portal.
    4. Linking API to Apiary Swagger API-definition living document.
  4. Login to API Developers Portal (API Catalog)
    1. Register a New Application
    2. Understanding the role of API Keys
    3. Reviewing MedRec API Documentation
    4. Registering to consume MedRec APIs
    5. Testing APIs.
  5. Understand API Analytics, consumption, metrics and monitoring dashboards.

Continue reading “Teaching How to Design and Secure an API with Oracle API Platform”

DX Workshop Season 3 — The Experiment

Season 3 of the Developer Experience Workshops had just kicked off today in Perth. And travelling to Melbourne tomorrow for the meetup tomorrow night and then the workshop after that.

See what is happening at the upcoming workshop here at medium.com.

Here are the upcoming workshop (at the point of publishing this article):

Melbourne – Wednesday 8 Nov 1800 Meetup – (York Butter Factory) – http://bit.ly/2hJgfBk
Melbourne – Thursday 9 Nov 0900 Official Session – (Oracle Office ) – http://bit.ly/2zgifsj
Brisbane – Tuesday 14 Nov 0900 Official Session – (Oracle Office) – http://bit.ly/2lUVHtV
Brisbane – Tuesday 14 Nov 1800 Meetup – (Oracle Office) – http://bit.ly/2AlQBKr
Wellington – Monday 20 Nov 1800 Meetup – (TBD) – To Be Finalised
Wellington – Tuesday 21 Nov 0900 Official Session – (Oracle Office) – http://bit.ly/2AbnXuD
Auckland – Wednesday 22 Nov 1800 Meetup – (TBD) – To Be Finalised
Auckland – Thursday 23 Nov 0900 Official Session – (Oracle Office) – http://bit.ly/2hee2k7
Sydney – Wednesday 29 Nov 1500 Official Session – (Oracle Office) – http://bit.ly/2hg3pxx
Adelaide – Thursday 30 Nov 1500 Official Session – (Oracle Office) – http://bit.ly/2h6kQg0

 

Apiary designed APIs tested using Dredd

APIs are becoming the window to the digital assets of the modern business. Well documented, well governed and easy to use APIs are key to their successful uptake, longevity and associated business success. Yes, I did say well documented. In this instance I am talking about the documentation required to describe the APIs capabilities in a manner that is meaningful for your ultimate audience, the “API Consumers”, however it will also provide the template for the API Developer to develop their code from. In the modern business climate, we probably don’t want to produce War and Peace, we simply want to take a minimum viable approach to our API documentation. But where would I find a capability that will simplify our task as API Designers, capture the design documentation for our APIs, allow us to do some initialise testing to validate the usefulness of our design before any code is cut, and also have the documentation ready for consumption by team members and interested parties using a standards based approach. Where indeed ! Look no further than Apiary.io. Continue reading “Apiary designed APIs tested using Dredd”

A New Hackathon Experience

This week I was attending a customer event. It was an interesting learning experience on different levels. It was a great opportunity to meet some people that I would not normally would be.

It was a hackathon put on by MLC Life Insurance (#MLCLifeHackathon) and we (as Oracle) were happy to support them as one of their partners. I’ve been to other hackathon events but they were organised differently. So I was curious to see what their objectives were. It would too easy to be cynical. With an open mind, I was happy to be part of their journey.

Continue reading “A New Hackathon Experience”