Configure Multiple Identity Stripes for Oracle Integration 3
For Oracle Integration 3, the primary (primordial) stripe is automatically federated using preconfigured groups. However, you can create separate environments for a single cloud service or application (for example, create one environment for development and one for production), where each environment has a different identity and security requirements. Implementing one or more secondary stripes enables you to create and manage multiple instances of Oracle Identity Cloud Service to protect your applications and Oracle Cloud services.
Once provisioned, you cannot change the Oracle Identity Cloud Service stripe or change the association of the Oracle Integration instance to another IAM domain.
This topic applies only to tenancies that do not use identity domains. See Differences Between Tenancies With and Without Identity Domains.
You can manually federate one or more secondary stripes with Oracle Cloud Infrastructure using SAML IDP federation in which multiple Oracle Identity Cloud Service stripes are associated with the same tenancy. Note that the account owner administers both primary and secondary stripes, but identities within the stripes are isolated from each other.
For benefits to using multiple Oracle Identity Cloud Service instances, see About Multiple Instances.
Follow the steps below to manually federate a secondary stripe for your tenancy. You must be the owner of the tenancy.
- Define a Stripe Naming Convention
- Create an IDCS Group for Secondary Stripe Users
- Create an OAuth Client in the Secondary Stripe
- Create an Oracle Cloud Infrastructure Group for Secondary Stripe Users
- Create the Federation and Its Group Mapping
- Create an Oracle Cloud Infrastructure Policy for Federated Users to Create Instances
- Provide Access to a Federated Stripe in the Oracle Cloud Infrastructure Console Group for Secondary Stripe Users
- Create Oracle Integration Instances in the Secondary Stripe Compartment
Define a Stripe Naming Convention
As a best practice, define a <stripename>
for all the
entities you'll create specific to the stripe. Uniquely identifying configurations
associated with a stripe is important, especially when multiple stripes are
configured.
In the sections that follow, you'll use
stripename
in these entities:
Entity | Naming convention |
---|---|
IDCS group |
|
OCI group |
|
Compartment |
|
Identity Provider |
|
Policy |
|
Policy Statement |
|
Create an IDCS Group for Secondary Stripe Users
In IDCS, create a group in the secondary stripe and add users from the secondary stripe to the group.
Create an OAuth Client in the Secondary Stripe
Create an IDCS confidential application that uses OAuth client credentials and is assigned the IDCS domain administrator role. You must create a confidential application per secondary stripe.
Create an Oracle Cloud Infrastructure Group for Secondary Stripe Users
This group is needed because the Oracle Cloud Infrastructure SAML IDP federation requires group mapping for federating users from the federated IDP (IDCS), and OCI native group membership is required for defining and granting Oracle Cloud Infrastructure permissions (policies) for federated users.
Create the Federation and Its Group Mapping
Now that you have the IDCS and Oracle Cloud Infrastructure groups created and client information needed, create the IDCS identity provider and map the groups.
Create an Oracle Cloud Infrastructure Policy for Federated Users to Create Instances
With the federation done, set up Oracle Cloud Infrastructure policies that allow federated users from the secondary IDCS stripe to create Oracle Integration instances. As a common pattern, the policy is scoped to a compartment.
Provide Access to a Federated Stripe in the Oracle Cloud Infrastructure Console Group for Secondary Stripe Users
Perform additional steps to enable the secondary stripe administrator and all other secondary stripe users to see stripes under federation.
When you sign in as a user in the above Oracle Identity Cloud Service group, you can create users and groups in the Oracle Cloud Infrastructure console and assign permissions as you would in a primary stripe.
Additional information about where clauses
Suppose you define a policy for a group (as in the example shown below) that uses the manage verb with a where clause restricting it to a specific identity provider (ocid).
Example policy:
allow group OCISecStripeAdmin to manage
identity-providers in tenancy where
target.identity-provider.id='ocid1.saml2idp.oc1..aaaaaaaa...’
When a user from the group logs into the Oracle Cloud Infrastructure Console and navigates to the Federation page, the following message appears within the table: Authorization failed or requested resource not found.
Adding the following additional policy enables users in the group to navigate to the same page and see the identity providers. They can inspect both, but are only able to see the group mappings (read) of the allowed identity provider:
Additional example policy: allow group
OCISecStripeAdmin to inspect identity-providers in tenancy