Oracle IAM Upgrade Lessons Learned: Fixing RelayState URL & Access Issues -Navigating Oracle IAM Issues? Let’s Connect

Upgrading Oracle Identity Cloud Service (IDCS / IAM) is usually seamless until it isn’t.

Recently, during an IAM upgrade, we encountered post-upgrade access issues tied to RelayState URLs, impacting user login flows into Oracle applications like Oracle Fusion Cloud Applications and custom integrations.

Here’s a breakdown of the issue, root cause, and how we fixed it 👇

Azure AD (Entra ID) Enterprise Applications – Critical Checks During IAM Upgrade

In our case, a big part of the issue wasn’t just within Oracle Identity Cloud Service, but also how Microsoft Entra ID (Azure AD) handled SAML requests post-upgrade.

When Oracle IAM changes anything around endpoints, certificates, or redirect handling Azure AD Enterprise Applications must be revalidated.

Why This Matters

Azure AD acts as the Identity Provider (IdP) in many federated setups.Even a small mismatch can break:

• RelayState handling

• SSO redirection

• Token validation

• User login experience

What Went Wrong?

After the IAM upgrade:

• Users were able to authenticate successfully

• BUT… they were not redirected correctly

• Landing pages failed or defaulted incorrectly

• Deep links (bookmarked URLs) stopped working

The culprit? RelayState URL misconfigurations

Understanding RelayState (Quick Refresher)

RelayState is:

• A parameter used in SAML authentication

• Helps redirect users to the intended destination after login

If this breaks, users land in the wrong place or nowhere.

Step-by-Step Fix

✅ Step 1: Validate SAML Configuration

• Navigate to:

  • IAM Console → Applications → Your App → SSO Settings

• Check:

  • Default RelayState URL

  • Assertion Consumer Service (ACS) URL

• Ensure URLs are:

  • Correct

  • HTTPS

  • Not deprecated

Step 2: Verify Identity Provider (IdP) Settings

📸 [Insert Screenshot: Identity Provider Configuration]

• Confirm:

  • RelayState passthrough is enabled

  • No hardcoded/old URLs exist

• If federated (Azure AD / ADFS):

  • Validate reply URLs match exactly

Step 3: Test Deep Links

Use a known working deep link:

Validate:

• Redirect behavior post-login

• Session persistence

Step 4: Check Load Balancer / DNS Changes

Post-upgrade, sometimes:

• Domains change

• Traffic routing changes

👉 Ensure:

• No old endpoints are cached

• DNS propagation is complete

• SSL certificates are valid

Key Azure AD Enterprise App Tasks

✅ 1. Validate Basic SAML Configuration

• Go to:

  • Azure Portal → Enterprise Applications → Your Oracle App

• Check:

  • Identifier (Entity ID) matches Oracle IAM

  • Reply URL (ACS URL) is updated

  • Sign-on URL aligns with new RelayState logic

👉 Even a trailing slash mismatch can break SSO.

Claims & Attributes Mapping:

Verify:

• UPN / Email mapping

• NameID format (often emailAddress)

Common issue:

• Post-upgrade defaults reset or mismatch with Oracle expectations

Pro Tips

• Always document pre-upgrade SSO configs

• Use tools like:

  • SAML Tracer (Firefox/Chrome)

• Maintain a test checklist for IAM upgrades

• Validate with real business users, not just admins

Final Thought

The biggest learning?

IAM upgrades are not isolated.They are ecosystem upgrades involving:

• Oracle IAM

• Azure AD / Entra ID

• Applications

• Network layers

Pro Tip (From Real Experience)

During upgrades:

Treat Azure AD Enterprise App config as part of your IAM stack not external

✔ Always include Azure validation in your:

• Upgrade checklist

• Regression testing

• Business user validation

Let’s Connect

I’m always keen to exchange insights with the Oracle community especially around:

• Oracle IAM / IDCS

• OCI integrations

• Fusion applications

If you’ve faced similar challenges or want to collaborate via New Zealand Oracle Users Group, feel free to reach out!