OCI Identity and Access Management (IAM) from a Multicloud Lens

Introduction

This article provides an overview of the Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) service, its key features, concepts, and practical applications in the multicloud arena. It covers:

• Authentication and authorization.
• Identity domains, users, groups, and compartments.
• Policy creation and advanced configurations.
• Federation with Azure Active Directory.

Part 1: Basics of IAM

IAM Overview:

• IAM stands for Identity and Access Management.
• Controls access to OCI resources by managing users, groups, and their permissions.
• Key components: Authentication (AuthN): Verifying who a user is. Authorization (AuthZ): Defining what a user is allowed to do.

Key Features

1. Identity Domains: Containers for managing users, groups, roles, and configurations. Each tenancy includes a default identity domain. Additional identity domains can be created for separate environments (e.g., development, production).
2. Users and Principals: Users: Individuals or systems managing resources. Principals: IAM users and resource principals.
3. Groups: Collections of users requiring the same type of access. Dynamic Groups: Membership changes dynamically based on rules.
4. Policies: Define authorization in a human-readable format (e.g., "Allow group A to manage network resources").
5. Compartments: Logical collections of resources for isolation and access control.

Part 2: Identity Domains

Overview:

• Represent user populations with associated configurations and security settings.
• Support advanced capabilities like multi-factor authentication and federation.

Identity Domain Types

1. Free Identity Domain: Default, used for managing OCI resources.
2. Oracle Apps Identity Domain: Supports seamless authentication for Oracle SaaS and PaaS, and GBU apps.
3. Oracle Apps Premium Domain: Extends IAM to OCI-hosted or on-premises Oracle applications, like EBS.
4. Premium Identity Domain: Full feature set for third-party applications.
5. External User Identity Domain: For consumer-facing use cases (e.g., contractors or millions of users).

Best Practices:

• Use separate identity domains for different environments (e.g., development and production).

Part 3: Policies and Authorization

Policy Syntax:

• Components of a policy: Subject: Specifies users or groups (e.g., "group A"). Verb: Actions allowed (inspect, read, use, manage). Resource Type: Resource or resource family (e.g., virtual network family). Location: Specifies compartment or tenancy. Conditions: Advanced rules (e.g., restricting access by IP).

Example Policy:

Allow group <domain/group_name> to manage virtual network family in tenancy

Policy Principles:

• OCI enforces least privilege by default.
• Policies always grant permissions (deny is implicit if not explicitly allowed).

Part 4: Federation Concepts

Key Terms:

• Identity Provider (IdP): Service providing credentials and authentication.
• Service Provider (SP): Application relying on an IdP for authentication.
• Federation Trust: Relationship between IdP and SP.

Process:

1. User accesses the service provider’s application.
2. Service provider delegates authentication to the IdP.
3. User authenticates with IdP.
4. IdP provides an access token.
5. User accesses the service provider’s application with the token.

Supported Protocols:

• OCI supports Security Assertion Markup Language (SAML) 2.0.

Part 5: Practical Demonstrations

Example 1: Creating Users and Policies

1. Create Identity Domain: Name the domain (e.g., "Test Domain"). Select the domain type (e.g., Free Identity Domain). Specify a domain administrator.
2. Add Users and Groups: Create a user and assign to a group. Define permissions by writing policies (e.g., allowing a group to manage virtual networks).
3. Test User Permissions: Log in as the user and verify resource access.

Example 2: Federation with Azure Active Directory

1. OCI Configuration: Export SAML metadata from the OCI Console.
2. Azure Configuration: Create an enterprise application for OCI in Azure. Configure single sign-on with SAML. Upload OCI SAML metadata.
3. Federation Setup: Upload Azure SAML metadata to OCI. Create and activate the identity provider. Assign the provider to a policy for sign-in.
4. Testing: Log in using Azure credentials via the OCI Console. Verify seamless access.

Conclusion

This article provides a concise introduction to OCI IAM, focusing on managing users, groups, policies, and federation. By mastering these concepts, you can effectively control access to OCI resources and ensure secure, streamlined operations in the multicloud context of Oracle DB@Azure.