Oracle Visual Builder: Applications That Outlive Their First Release · Module 6 · Connecting to Fusion
Authentication, and whose identity is used
Lesson 57 of 176 · 3 min
The SIGNED-IN USER against a FIXED SERVICE ACCOUNT. The single most consequential choice in this module, and IT IS A SECURITY DECISION, NOT A TECHNICAL ONE. Every call your application makes to Fusion is made as somebody. Which somebody is a single setting, it takes two seconds, and it decides what your application is. THE SIGNED-IN USER MEANS THE CALL CARRIES THE IDENTITY OF THE PERSON USING THE PAGE. So Fusion applies its own security: they see the records they are entitled to and nothing else, exactly as if they had opened Fusion directly. Your application inherits an authorisation model somebody has already designed, maintained and audited. A SERVICE ACCOUNT MEANS EVERY CALL IS MADE AS ONE FIXED USER, WHOEVER IS AT THE KEYBOARD. So Fusion applies THAT account's security to everybody, and your application is the only thing standing between a user and everything the account can reach. Lesson…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Visual Builder: Applications That Outlive Their First Release, with a certificate on completion and a fourteen-day refund window.
In this module: Module 6 · Connecting to Fusion
- 1What a service connection is
- 2Creating one against a Fusion REST APIFree preview
- 3Authentication, and whose identity is used
- 4Why a shared service account is usually wrong
- 5Query parameters, filtering and fields
- 6Pagination, properly
- 7Writing back to Fusion
- 8When the shape changes underneath you
- 9Calling an OIC integration instead
- 10Handling a service that is down
- 11CORS and the errors it produces
- 12What breaks: four connection failures
- 13Lab briefing · Connect, over-fetch, then fix it