Understanding the Oracle E-Business Suite 12.2 Technology Stack

 Oracle E-Business Suite (EBS) is one of the most widely deployed enterprise applications across industries. Behind every EBS environment is a collection of technology components that work together to deliver business functionality, manage user requests, and communicate with the database tier. This collection of components is known as the Oracle E-Business Suite Application Technology Stack.

What is the EBS Application Technology Stack?

The Application Technology Stack consists of the software components installed on the EBS application tier. These components are responsible for processing business logic, serving web pages, running forms and reports, and enabling communication between end users and the database.

For Oracle E-Business Suite Release 12.2, the technology stack includes:

• Oracle Fusion Middleware (FMW)

• Oracle WebLogic Server (WLS)

• Oracle HTTP Server (OHS)

• Oracle Developer (Forms and Reports)

• Java Development Kit (JDK)

Together, these components provide the foundation required to run EBS applications efficiently and securely.

The Classic Technology Stack

Since the release of EBS 12.2, most environments have been running on what Oracle refers to as the Classic Technology Stack. This stack is built on Oracle Fusion Middleware 11g and Java 7.

The certified component versions are:

Component	Certified Release
Oracle Fusion Middleware (FMW)	11.1.1.9
Oracle WebLogic Server (WLS)	10.3.6
Oracle HTTP Server (OHS)	11.1.1.9
Oracle Developer (Forms and Reports)	10.1.2
Java Development Kit (JDK)	7

For many years, this technology stack has provided a stable and reliable platform for Oracle E-Business Suite deployments worldwide.

The Next Generation Technology Stack

As technology evolves, Oracle is modernizing the EBS application tier with a newer and more secure technology foundation known as the Next Generation Technology Stack.

The planned certified releases include:

Component	Planned Certified Release
Oracle Fusion Middleware (FMW)	14.1.2
Oracle WebLogic Server (WLS)	14.1.2
Oracle HTTP Server (OHS)	14.1.2
Oracle Developer (Forms and Reports)	14.1.2
Java Development Kit (JDK)	17

This modernization introduces newer middleware and Java versions that align with current enterprise standards, helping organizations improve security, maintainability, and long-term supportability.

Why Does This Matter?

Many EBS customers continue to run mission-critical workloads on Release 12.2. Understanding the differences between the Classic and Next Generation Technology Stacks is important when planning upgrades, security initiatives, and future platform strategies.

Moving to the Next Generation Technology Stack provides organizations with:

• Modern middleware architecture

• Support for Java 17

• Enhanced security capabilities

• Improved compatibility with current infrastructure standards

• Better long-term support from Oracle

What About Support for the Classic Technology Stack?

One of the most common questions among Oracle E-Business Suite administrators is whether upgrading to the Next Generation Technology Stack is mandatory.

The answer is yes—if organizations want to remain aligned with Oracle's long-term support strategy.

Oracle has indicated that EBS Release 12.2 production environments are expected to move to the Next Generation Technology Stack to ensure continued supportability in the future. Once the Next Generation Technology Stack becomes generally available, Oracle will publish a detailed support timeline outlining key milestones and support dates.

How Long Will the Classic Technology Stack Be Supported?

At the time of writing, Oracle has not announced an end date for error correction support for the Classic Technology Stack. However, Oracle has stated that an updated support roadmap will be provided following the general availability of the Next Generation Technology Stack.

For organizations currently running the Classic Technology Stack, this means there is no immediate deadline to migrate. However, IT teams should begin evaluating the impact of the upgrade, reviewing infrastructure requirements, and planning their modernization roadmap to avoid future support challenges.

Planning Ahead

While the Classic Technology Stack remains fully functional today, the introduction of the Next Generation Technology Stack signals Oracle's strategic direction for EBS 12.2. Organizations that proactively prepare for the transition will be better positioned to:

• Maintain Oracle support eligibility

• Benefit from newer middleware and Java technologies

• Improve security and compliance posture

• Reduce technical debt

• Simplify future upgrades and maintenance

The move to the Next Generation Technology Stack should therefore be viewed not only as a technology upgrade, but as an important step in ensuring the long-term sustainability of Oracle E-Business Suite environments.

Final Thoughts

The Oracle E-Business Suite 12.2 Application Technology Stack is the foundation that powers the application tier of EBS environments. While the Classic Technology Stack has served organizations well for years, Oracle's Next Generation Technology Stack represents the future direction of EBS technology.

Organizations running EBS 12.2 should begin evaluating their technology stack roadmap and prepare for the transition to the newer platform to take advantage of modern security, performance, and support capabilities.

OCI Block Volume Enforcement Update: What Every OCI Customer Should Know Before Launching New Instances

 Oracle has introduced an important enhancement to the way Oracle Corporation Cloud Infrastructure (OCI) validates Block Volume storage limits and quotas during Compute instance provisioning. While the update may appear operational in nature, it can directly impact infrastructure deployments if organizations are not prepared.

This change strengthens governance and capacity enforcement across OCI environments and ensures that storage consumption aligns with configured tenancy-level limits and compartment quotas.

What Has Changed?

Previously, when launching a Compute instance in OCI, the platform did not fully validate tenancy-level total_storage_gb limits and compartment quotas during the boot volume creation process.

As a result, certain instance launches could still succeed even if the configured storage thresholds had technically been exceeded.

With the latest OCI Block Volume service update, Oracle now enforces these validations before a boot volume is created during Compute instance provisioning.

If the requested boot volume size exceeds:

• Tenancy-level Block Volume storage limits
• Compartment-level storage quotas

the Compute instance launch will fail immediately with a quota or limit-related error.

This enhancement brings consistent enforcement behavior across OCI storage workflows and improves overall resource governance.

---

Why This Change Matters

In many OCI environments, administrators configure storage quotas and limits to:

• Control cloud spending
• Prevent uncontrolled resource growth
• Segregate departmental resource usage
• Enforce governance and compliance policies

Without strict validation during boot volume provisioning, there was a gap where deployments could unintentionally bypass those controls.

Oracle has now closed that gap.

For organizations using automation pipelines, Infrastructure-as-Code (IaC), Terraform, autoscaling, or dynamic provisioning, this update becomes especially critical because new deployments may unexpectedly fail if storage limits are not monitored properly.

---

What Is Impacted?

The enforcement applies only to workflows that create new boot volumes.

Affected Workflows

• Launching new Compute instances
• Autoscaling events that provision new instances
• Automated deployment pipelines
• Any workflow that creates new boot volumes

Not Affected

The following existing resources remain unaffected:

• Existing boot volumes
• Existing Block Volumes
• Running Compute instances
• Previously provisioned infrastructure

This means there is no disruption to currently running workloads.

---

Oracle’s Proactive Measures

To reduce operational impact, Oracle is proactively increasing capacity limits for affected tenancies where necessary before enabling strict enforcement.

This helps minimize unexpected failures for customers already operating close to their storage thresholds.

However, organizations should not rely solely on automatic adjustments and should independently review their storage configurations.

Strengthening Oracle Autonomous AI Database Security with Multi-Factor Authentication

 As organizations continue moving mission-critical workloads to the cloud, database security has become more important than ever. Password-based authentication alone is no longer sufficient to protect sensitive enterprise data from evolving cyber threats. To address this challenge, Oracle Autonomous AI Database now supports Multi-Factor Authentication (MFA), providing an additional layer of protection for database access and SQL execution.

What is MFA in Autonomous AI Database?

Multi-Factor Authentication enhances database security by requiring users to verify their identity using two separate authentication factors:

• Something the user knows — typically a username and password
• Something the user has — such as a one-time token, authenticator app, push notification, or secure verification mechanism

With MFA enabled, even if database credentials are compromised, unauthorized access becomes significantly more difficult.

Key MFA Capabilities

Oracle Autonomous AI Database provides flexible MFA options designed for modern enterprise environments:

1. MFA for Database Logins

Administrators can enforce MFA during user authentication to ensure only verified users can establish database sessions.

2. MFA for SQL Access

Organizations can require additional verification before executing sensitive SQL operations, adding another layer of protection for critical workloads.

3. Multiple Verification Methods

Oracle supports different MFA delivery channels, including:

• Email-based verification
• Authenticator applications
• Push notifications
• Slack-based token delivery

This flexibility allows enterprises to align MFA with their operational and security standards.

How Oracle Implements MFA

Oracle provides the DBMS_MFA_ADMIN package to simplify MFA administration. Database administrators can:

• Register users for MFA
• Configure token delivery channels
• Enable or disable MFA policies
• Manage token attributes and session validation

This package enables centralized MFA governance while maintaining operational simplicity.

Why MFA Matters for Cloud Databases

Cloud databases are constantly exposed to risks such as:

• Credential theft
• Password reuse attacks
• Unauthorized privileged access
• Insider threats

By introducing MFA, organizations can significantly reduce the attack surface and strengthen compliance with modern security frameworks and regulatory standards.

For enterprises hosting critical ERP, financial, healthcare, or customer data in Oracle Autonomous AI Database, MFA becomes an essential component of a defense-in-depth security strategy.

Additional Security Benefits in Oracle AI Database

Oracle continues to strengthen its database security portfolio with features such as:

• TLS 1.3 support
• SQL Firewall
• Enhanced auditing
• Stronger password policies
• Improved encryption capabilities
• IAM integration for centralized access control

Optimizing OCI IAM Policies Across Compartment Hierarchies

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) enables organizations to securely control access to cloud resources. A critical aspect of IAM in OCI is how policies behave within a compartment hierarchy, particularly in large-scale enterprise environments.

As OCI deployments grow, managing IAM policies effectively becomes essential to ensure scalability, compliance, and operational efficiency.

Understanding Policy Evaluation in a Hierarchy

OCI evaluates IAM policies from the root compartment down through each level of the compartment structure. Every policy statement attached to the root or to intermediate compartments contributes to the total number of statements evaluated along a path from the root to a specific leaf compartment.

Key implications of this model include:

• Policies defined at the root compartment apply broadly and affect all child compartments.

• Policies defined in lower-level compartments impact only their respective branches.

• OCI enforces a limit of 500 policy statements per compartment hierarchy path.

If the accumulated policy statements along a path exceed this limit, operations such as creating, updating, or deleting policies may fail.

Why Policy Limits Matter

As organizations introduce additional compartments to segregate workloads, teams often create policies independently to meet their operational needs. Over time, this leads to:

• Redundant policy statements

• Overlapping access grants

• Excessively granular permissions

• Increased administrative complexity

When the total evaluated statements exceed the allowed limit, policy changes can fail unexpectedly, impacting governance and agility.

Best Practices for Managing IAM Policies

To maintain a scalable and efficient IAM framework, consider the following structured approach:

1. Eliminate Redundant or Unused Policies

Review existing policies for overlapping permissions. For example:

• Avoid defining both read and manage permissions separately when manage already includes read.

• Consolidate multiple statements granting similar permissions to the same group.

Periodic cleanup significantly reduces policy statement count.

---

2. Define Policies at the Appropriate Compartment Level

Root-level policies affect every branch of the hierarchy. Where possible:

• Move policies closer to the target compartments.

• Restrict scope to the minimum required hierarchy path.

This reduces unnecessary inheritance and keeps the evaluation path efficient.

3. Consolidate and Simplify Policy Statements

Instead of writing multiple narrowly scoped permissions, use broader resource families where appropriate. For example:

• Replace multiple individual resource permissions with a single family-level permission.

• Standardize policy patterns across business units.

Simplification improves both maintainability and scalability.

4. Leverage Tag-Based Access Control

Attribute-based access control using defined tags can significantly reduce policy sprawl. By applying consistent tagging strategies:

• Policies can reference tags instead of compartments.

• Access can scale without creating additional compartment-specific statements.

This approach supports large, dynamic environments effectively.

Conclusion

IAM policy management in OCI is not merely a configuration activity — it is a governance discipline. Understanding how policies accumulate within a compartment hierarchy is crucial to preventing operational constraints.

By removing redundancy, scoping policies appropriately, simplifying statements, and leveraging tag-based access control, organizations can maintain a secure, scalable, and efficient IAM framework.

Proactive policy governance today prevents scalability challenges tomorrow.

Understanding the OCI Policy Analysis Tool: An Overview

Managing identity and access in large Oracle Cloud Infrastructure (OCI) environments can be complex. As organizations scale, so does the number of compartments, groups, dynamic groups, and policy statements. Assessing who can do what—across thousands of permissions—can quickly become challenging, especially for administrators tasked with strengthening security and reducing risk.

To address these challenges, the OCI Policy Analysis Tool has emerged as an essential utility for OCI administrators and security practitioners. Designed to help visualize, interpret, and analyze OCI Identity and Access Management (IAM) policies, this tool provides clarity and insight into effective permissions across your cloud tenancy. 

---

What Is the OCI Policy Analysis Tool?

The OCI Policy Analysis Tool is an unofficial, open-source application targeted at users who need a deeper understanding of their OCI IAM posture. It goes beyond simple policy listing by loading all relevant identity and policy data and organizing it into a cohesive, searchable format. This empowers administrators to answer questions such as:

• Which principals have excessive privileges in sensitive compartments?

• Why is a particular service unable to perform an expected action?

• How have policies changed over time? 

Built entirely with Python and leveraging the OCI Python SDK, the tool demonstrates how custom scripts and utilities can be authored to fill functional gaps and make cloud security operations more manageable. 

---

Key Capabilities and Features

Once loaded with the necessary data from your tenancy or a compliance extract, the OCI Policy Analysis Tool provides several analytical and visibility features:

• Policy Browser: Explore and search policy statements across all compartments.

• Policy Analysis: Filter and inspect parsed IAM policies, including subjects, actions, resources, and conditions.

• Dynamic Group Insights: Review dynamic group matching rules to identify misconfigurations or unused groups.

• User & Resource Principal Analysis: Determine effective permissions for users and resources based on group memberships.

• Cross-Tenancy View: Analyze global policy statements such as Define, Admit, and Endorse.

• Historical Comparison: Compare policy sets at different points in time to detect changes or anomalies.

These features are accessible through an intuitive, tabbed interface that helps administrators quickly locate information and understand complex relationships within IAM configurations. 

---

Additional Utility Functions

Beyond policy inspection, the tool offers usability enhancements that improve flexibility and extend analysis capabilities:

• Caching: Load and save OCI policy and identity data locally for offline analysis.

• Export / Import: Export analysis results to CSV or JSON for reporting or auditing.

• Compliance Script Integration: Import data from standard compliance scripts to enrich policy insights.

• AI-Assisted Insights: Receive natural-language explanations and risk annotations for policy statements.

• Contextual Help: Each view provides embedded help to explain the relevance of data fields or features.

---

Advanced Analysis & Simulation

For deeper investigations, the tool also incorporates powerful extensions:

• API Simulation: Test hypothetical API calls as specific principals to determine allowed or denied actions.

• Policy Recommendations: Generate suggested remediation steps based on detected misconfigurations or over-privileged access patterns.

• MCP Server Integration: Expose your OCI tenancy data to tools such as VS Code or generative AI systems for interactive analysis.

---

Getting Started

There are two main ways to run the OCI Policy Analysis Tool:

1. Direct Python Execution:

   • Ensure Python 3.12 or newer is installed.

   • Create and activate a virtual environment.

   • Install the tool dependencies and run the UI program through Python.

   • Load your OCI configuration or authenticate using an instance principal. 

2. Packaged Executable:

   • Download the binaries from the project’s GitHub releases.

   • Launch the platform-specific executable and follow on-screen prompts.

Once started, you can import tenancy data and begin exploring policies, dynamic groups, and user permissions from a consolidated view.

---

Conclusion

In complex OCI deployments, maintaining an accurate understanding of IAM policies and the effective permissions they grant is essential for security and compliance. The OCI Policy Analysis Tool provides administrators with a comprehensive way to visualize, analyze and assess policy configurations across an entire tenancy. Whether it’s identifying over-privileged users or tracking changes over time, this tool transforms raw policy data into actionable insights. 

Part 1 of this series focuses on the tool and how to get started; an upcoming Part 2 will explore the development journey and strategy behind the tool’s creation.

Resolving Public IP and Hostname Mappings Using dig and openssl

 In day-to-day infrastructure troubleshooting, especially in hybrid and cloud environments, verifying DNS mappings and certificate bindings is a routine yet critical task. Whether validating load balancer configurations, troubleshooting SSL issues, or confirming external exposure of services, having quick command-line methods can save significant time.

This article walks through two practical techniques:

1. Identifying the public IP mapped to a DNS hostname

2. Identifying the public hostname(s) associated with a public IP via SSL certificate inspection

---

1. Finding the Public IP Address for a Hostname

To determine the IP address associated with a public DNS record, the dig command is both simple and reliable.

Command

dig +short <public_url_hostname>

Example

dig +short example.mycompany.com

What It Does

• Queries the DNS system for the A record.

• +short ensures only the IP address is returned.

• Works for publicly resolvable DNS records.

Sample Output

203.0.113.10

When to Use This

• Validating DNS propagation

• Confirming load balancer IP mapping

• Verifying cutover during migrations

• Troubleshooting connectivity issues

This is often the first step in confirming whether a hostname resolves to the expected public endpoint.

---

2. Finding Hostname(s) Mapped to a Public IP Using SSL Certificate

Reverse DNS lookups do not always return the expected hostname. However, if the server presents an SSL certificate, you can extract the Subject Alternative Names (SAN) from the certificate to identify the DNS names associated with that endpoint.

Command

openssl s_client -connect <public_url_host>:<port> -servername dummy </dev/null 2>/dev/null | \
openssl x509 -noout -text | grep DNS

Example

openssl s_client -connect 203.0.113.10:443 -servername dummy </dev/null 2>/dev/null | \
openssl x509 -noout -text | grep DNS

What This Command Does

• openssl s_client -connect
  Establishes an SSL/TLS connection to the target IP and port.

• -servername dummy
  Enables SNI (Server Name Indication). Some servers require SNI during TLS negotiation.

• </dev/null 2>/dev/null
  Suppresses interactive input and hides connection noise.

• openssl x509 -noout -text
  Extracts certificate details.

• grep DNS
  Filters the output to display only DNS entries under the Subject Alternative Name section.

Sample Output

DNS:example.mycompany.com, DNS:www.example.mycompany.com

When to Use This

• Identifying which hostname a public IP is serving

• Validating SSL certificate bindings

• Troubleshooting multi-domain load balancers

• Confirming SAN entries after certificate renewal

---

Important Notes

• This method works only if the service exposes an SSL certificate.

• If multiple virtual hosts exist behind the same IP, SNI may affect which certificate is presented.

• The certificate may contain multiple DNS entries.

Bring Your Own Certificate Authority (BYOCA) in OCI

Security and trust are foundational requirements for modern enterprise IT environments. Many organizations have invested heavily in mature Public Key Infrastructure (PKI) systems to support thousands of applications, meet regulatory mandates, and uphold long-standing trust chains. Rebuilding these systems for cloud deployments can be costly, complex, and disrupt established governance models.

To address this challenge, Oracle has introduced Bring Your Own Certificate Authority (BYOCA) for Oracle Cloud Infrastructure (OCI) Certificates. This feature enables enterprises to integrate their existing Certificate Authority (CA) infrastructure directly with OCI without relinquishing control of sensitive private keys. 

Why Bring Your Own CA Matters

Traditionally, OCI Certificates allowed customers to build PKI hierarchies in the cloud, create CAs, and manage certificate lifecycles with automation. However, many enterprises already operate trusted root CAs that are deeply embedded in internal and external systems. Migrating or recreating these root hierarchies in the cloud can pose operational, compliance, and risk management challenges—especially for organizations in highly regulated industries. 

With BYOCA, OCI now provides a mechanism to retain existing trust chains while leveraging cloud automation and lifecycle management. Enterprises can extend their on-premises PKI into the cloud in a secure and controlled manner, preserving compliance and ensuring uninterrupted trust continuity. 

How It Works

BYOCA allows you to import an existing root CA certificate into OCI Certificates simply by providing the PEM-encoded certificate. Importantly:

• Private keys remain under your exclusive control and are never uploaded to OCI.

• OCI registers the imported certificate as an externally managed root CA while maintaining trust relationships with existing PKI infrastructure.

• You can generate subordinate Certificate Authorities (sub-CAs) in OCI by signing certificate signing requests (CSRs) externally and then uploading the signed subordinate certificates to OCI.

• Once activated, these sub-CAs can issue certificates using secure, OCI-managed keys protected within OCI Vault and HSM infrastructure. 

This model bridges existing enterprise PKI investments with cloud automation and lifecycle management capabilities. It enhances interoperability across hybrid and multi-cloud deployments, enabling consistent certificate issuance and trust configurations across environments. 

Enterprise Benefits

The BYOCA approach delivers several advantages:

• Leverage Existing Investments – Continue using established PKI policies, trust anchors, and governance frameworks without redesigning root hierarchies for the cloud. 

• Improved Compliance and Governance – Maintain strict separation of duties, regulatory compliance, and audit requirements while integrating with OCI’s certificate lifecycle automation. 

• Hybrid and Distributed Workloads – Easily support hybrid infrastructure, multi-cloud architectures, and distributed systems with consistent trust configurations. 

• Operational Efficiency – Delegate the operational burden of subordinate CA lifecycle management to OCI while controlling root trust policies internally.

Getting Started

Importing and using BYOCA in OCI Certificates involves a few key steps:

1. Import your external root CA certificate (PEM format) into OCI Certificates without exposing private keys. 

2. Create subordinate CAs in OCI by generating CSRs and signing them with your root CA. 

3. Upload the signed subordinate CA certificates to OCI and activate them for certificate issuance. 

Once configured, OCI Certificates can issue and manage certificates from these subordinate CAs, bringing the best of cloud automation together with trusted enterprise PKI.