Log inSign upBook a demo
Tines Stories
  1. Docs
  2. Credentials
  3. Workload identity Federation
  1. Docs
  2. Credentials
  3. Workload identity Federation

Oracle Cloud

Last updated

Introduction

An Oracle Cloud credential authenticates to an Oracle Cloud Infrastructure (OCI) identity domain through workload identity federation. Tines signs a short-lived token for the credential and your identity domain exchanges it for a session token through an identity propagation trust, so no OCI API key is stored in Tines. Tines acts as a service user you create and signs OCI API requests for you.

OCI requires the token exchange itself to be authenticated, so you also create a confidential application in the domain and give Tines its client ID and secret. The secret alone can't mint anything; the trust only accepts tokens signed by Tines for this credential.

You can create the credential with the Oracle Cloud connect flow, which walks you through the steps below, or manually by choosing Manual creation and the Oracle Cloud credential type. Both show the same trust details.

Creating an Oracle Cloud credential

Step 1: Choose the identity domain

In the OCI console, open Identity & Security › Domains, pick the domain Tines should authenticate to, and copy its Domain URL from the Overview page, e.g. https://idcs-1a2b3c4d5e6f.identity.oraclecloud.com.

Step 2: Start the credential in Tines

From the credentials page, select New credential and choose Oracle Cloud, or choose Manual creation and then Oracle Cloud. Tines shows the credential's Issuer URL, Public key endpoint, Subject, and Audience. In the connect flow, enter the identity domain URL first; the audience defaults to it.

Step 3: Create the service user and confidential application

  1. Create a service user for Tines to act as (a user with serviceUser set to true), and grant it the access your stories need through a group and an IAM policy.

  2. Under the domain's Integrated applications, add a Confidential Application with the Client credentials grant and no application roles, then activate it. Tines authenticates the token exchange with it.

Step 4: Create the identity propagation trust

Identity propagation trusts are created with the OCI CLI or the REST API (POST /admin/v1/IdentityPropagationTrusts), using an access token with the Identity Domain Administrator role.

Create a trust of type JWT from the trust details Tines shows. The impersonation rule maps this credential's subject to the service user, and oauthClients must list the confidential application's client ID. The connect flow shows this request body with the values filled in:

{
  "schemas": ["urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"],
  "name": "Tines",
  "type": "JWT",
  "active": true,
  "issuer": "<issuer URL>",
  "publicKeyEndpoint": "<issuer URL>/.well-known/jwks.json",
  "clientClaimName": "aud",
  "clientClaimValues": ["<audience>"],
  "subjectClaimName": "sub",
  "subjectType": "User",
  "allowImpersonation": true,
  "impersonationServiceUsers": [
    { "rule": "sub eq <subject>", "value": "<service user ID>" }
  ],
  "oauthClients": ["<confidential application client ID>"]
}

Step 5: Enter the application details

Copy these from the confidential application's OAuth configuration.

In the connect flow, enter the Client ID and Client secret.

In the manual form, enter the Token endpoint (<domain URL>/oauth2/v1/token), the Client ID, the Client secret, and the Audience (the value the trust's client claim matches, the identity domain URL by default).

Step 6: Save

Saving verifies the connection by exchanging a token with the identity domain.

Using an Oracle Cloud credential

Reference the credential in the Authorization header of an HTTP Request action, as you would an AWS credential. Tines adds the OCI request signature:

"Authorization": "<<CREDENTIAL.oracle_cloud>>"

The requests carry the access you granted to the service user. Deactivating the trust in OCI stops Tines from signing requests within a few minutes.

Test credentials

A test credential has its own subject, the live subject with a :test suffix, so give it its own trust rule, typically mapped to a non-production service user. See test credentials.

Was this helpful?