Overview
OCI Identity and Access Management (IAM) is the identity fabric for Oracle Cloud. It acts as the login service, or gatekeeper, for IaaS, PaaS, and many SaaS services. Historically, Fusion SaaS services created an OCI IAM identity domain early in the lifecycle, but that domain was used mainly for Fusion extensions. Fusion Applications themselves continued to rely on Fusion IDM as the login service.
That model has changed. For new Fusion SaaS customers, and increasingly for existing customers as they migrate, OCI IAM Identity Domains become the native login service and user store for Fusion Applications. The shift makes Fusion identity management more consistent with the rest of OCI, but Fusion still behaves differently from other SaaS services such as EPM and GBU applications.
Key takeaway: Fusion Identity Domains now provide the authentication front door for Fusion Applications, but Fusion Security Console remains the authoritative place to manage Fusion users and their roles.
This article explains the key differences, what the new model enables, and the guardrails customers should follow when using Fusion Identity Domains.
Fusion Identity Domains: Key Differences and Guardrails
How Fusion Identity Domains Differ From Other SaaS Domains
In EPM and most GBU SaaS services, all users in the configured identity domain can access the application, and application roles can be managed from either the identity domain or the application itself. Fusion is different. Fusion users must be created and managed in the Fusion Security Console.
It is technically possible to create a user directly in the identity domain and assign the user to a Fusion Application role represented as a group in that domain. However, that action does not grant the user the corresponding Fusion role inside Fusion Applications, and it does not make the user able to sign in to Fusion. The Fusion Security Console remains the authoritative place for Fusion user and role management.
There is also a lifecycle difference. Non-Fusion SaaS applications can be configured to use an existing identity domain as their user store and login service. Fusion Applications create a new identity domain for each Fusion pod. In Fusion terminology, lifecycle environments are often referred to as pods, so each pod should be treated as having its own associated identity domain.
What the New Model Enables
With Fusion Applications using Identity Domains as their native login service, customers can create Fusion extension services, such as Oracle Integration Cloud and Visual Builder Cloud Service, in the same identity domain as the Fusion environment. This is a significant improvement over the previous model, where PaaS services often had to be created in separate PaaS identity domains and synchronized with the Fusion identity domain.
A shared identity domain gives administrators a clearer view of access across Fusion Applications and Fusion extension services. It also reduces identity synchronization complexity and creates a cleaner foundation for extensions.
The new model also improves security and observability:
- Modern authentication factors, including FIDO keys and passkeys, can be used for Fusion Application login.
- Authentication logs for Fusion can be accessed through OCI Logging because Identity Domain authentication logs integrate directly with OCI Logging.
- OAuth 2.0 and OIDC-based flows, including three-legged authentication and token exchange, can be used for Fusion and Fusion extension authentication.
Guardrails for Using Fusion Identity Domains
- Use the Fusion Security Console for Fusion users and roles. Create and manage Fusion users in Fusion, even though the users are represented in the identity domain.
- Treat Fusion Identity Domains as pod-specific. Do not assume one Fusion Identity Domain can be reused across unrelated Fusion pods in the same way that other SaaS applications can be pointed to an existing domain.
- Keep extension sign-on policies separate. If you create Fusion extensions in the Fusion Identity Domain, create dedicated sign-on policies for those extensions. Do not reuse Fusion sign-on policies for extension-specific rules.
- Plan around login limitations. Fusion Identity Domains do not support username-first login.
Identity Provider SAML Integration for Fusion Applications
Many customers use an enterprise IAM service to sign in to Fusion Applications. In the Identity Domain model, this can be implemented by configuring SAML 2.0 federation between the Identity Domain and the enterprise IAM provider. If the provider is Okta or Microsoft Entra, use the OCI IAM tutorials as the starting point. Fusion Applications for a long time support single Identity Provider except for Supplier users use-case. However, with Identity domain, customers can add multiple Identity Providers.
Fusion Identity Domain for non-oracle Applications
Fusion customers can also use their Fusion Identity Domain as the Enterprise SSO provider across their broader application landscape. By default, a Fusion Identity Domain supports integration with two non-Oracle applications. However, customers can change the Identity Domain type to Oracle Apps Premium to support up to 10 non-Oracle application integrations, or to Premium to support as many non-Oracle application integrations as required. This is especially powerful for Fusion HCM customers because, in most enterprises, the HR application is where user identities are born. If the HR identity system can provide Single Sign-On, customers can reduce or even avoid the need to sync user data from the HR application into a separate enterprise IAM service. To support additional applications, you can create customer groups for those applications in Fusion Identity Domain and manage those groups in the Fusion Identity Domain. However, make sure to not update Fusion Application roles in the Identity Domain.
Conclusion
Fusion Identity Domains simplify and modernize the identity architecture for Fusion Applications, but they do not make Fusion behave exactly like EPM, GBU SaaS, or other services that can freely use any existing identity domain. The best operating model is to use OCI IAM Identity Domains for modern authentication, logging, federation, and extension integration, while keeping Fusion Security Console as the system of record for Fusion users and roles.
For customers building Fusion extensions, the biggest opportunity is a unified identity plane across Fusion and the extension services. The biggest responsibility is to respect Fusion-specific guardrails: manage users through Fusion, separate extension sign-on policies, and design around pod-specific domains. Done well, this model gives customers stronger authentication, better visibility, and a cleaner foundation for Fusion extensibility.