Using SAML SSO for sign in - portal not refreshing

Google Cloud Apigee
1

We just configured using SAML SSO into our integrated portal.

After signing in, we noticed that the portal link Sign In at top does not change to sign in status. Usually its shows signed in with the account email. After clicking on the Sign In again, then it refreshes the page and the Sign in link changes to show the signin in email.

I am using the out of the box integrated portal and done very minimal changes in themes.

Any ideas on this issue? Thanks

2

Hi @Elvina_ART !

Are you on Apigee X or the older Apigee Edge?

3

Apigee X fully cloud hosted

4

@Elvina_ART Gotcha! thanks for confirming which Apigee version you’re on.
So I attempted to reproduce this issue with my Apigee X Integrated Developer Portal and Okta as my IdP, but I didn’t experience this issue. So I’m assuming it could be one of these things:

1. Sometimes the portal’s internal cache holds onto an older configuration state.

To fix this:

  • Go to your Portal Settings > Identity Provider.

  • Disable the SAML provider.

  • Wait for ~5-10 minutes.

  • Enable the SAML provider again.

  • This forces the portal infrastructure to flush its caches and pick up the latest configuration.

2. A common cause for subtle SAML weirdness in Apigee is a mismatch in the Identity Provider Entity ID, specifically regarding trailing slashes.

To fix this:

  • Check your IdP’s metadata file. Look for the entityID attribute.

  • Example: If the metadata says https://sts.windows.net/uuid/, ensure you have included the trailing / in the Apigee Portal configuration.

  • If the metadata says https://sts.windows.net/uuid, ensure you omit the trailing /.

  • They must match character-for-character.

3. I would recommend using Incognito/Private Window to test the sign in flow. If it works there every time, the issue is strictly related to aggressive caching in your standard browser session.

Lastly, please take a look at this video for setting up SAML IdP login for Apigee integrated dev portal. It’s a bit outdated as it refers to Apigee Edge, but the same configurations apply for Apigee X: https://youtu.be/X_JVmsMUC5k?si=A4i7cxpeuUW45ElP

Hope this helps!

1 Like
5

Hi Elvina_ART,

That is a frustrating user experience, especially after successfully configuring SAML SSO. A proper SSO integration should transition the user seamlessly to a fully signed-in state, which typically means the “Sign In” link should immediately update to display the user’s email or profile name.

The fact that the user has to click the “Sign In” link again to force a refresh and see the updated status suggests an issue with how the integrated portal is handling the post-authentication redirect and subsequent session state update on the client side (browser).

This is a known point of friction in many SAML integrations and usually involves one of three things:

:hammer_and_wrench: Potential Causes and Solutions

  1. Missing or Incorrect Redirect URI:

    • Cause: When the Identity Provider (IdP) sends the successful SAML Assertion back to the Apigee portal’s Assertion Consumer Service (ACS), the redirect URL might not be pointing back to the correct home page or a specific page that triggers the session validation script.

    • Action: Double-check your IdP configuration (like Okta, Azure AD, etc.) to ensure the Default Relay State or Target URL is set correctly. It should usually point to the base URL of your integrated portal.

  2. Portal Caching Issues:

    • Cause: The browser may be aggressively caching the pre-sign-in state, and the portal theme scripts are not forcing a refresh of the header components.

    • Action: Advise users to clear their browser cache and cookies, or try accessing the portal in an Incognito/Private window. If it works in Incognito, the issue is local caching.

  3. Client-Side Scripting/Theme Conflict (Most Likely):

    • Cause: The built-in integrated portal relies on JavaScript to check the session status after the SAML redirect completes and update the header dynamically. If you have added any minimal custom themes or scripts, even small ones, they might be interfering with this core session-checking script.

    • Action:

      • Temporarily revert to the default Apigee theme to see if the problem disappears. If it does, the issue is within your custom theme’s HTML, CSS, or JavaScript files.

      • Inspect the browser console (F12): Look for any JavaScript errors (red lines) immediately after the successful SAML redirect. This can pinpoint which script is failing to run or is being blocked.

:telephone_receiver: Contacting Apigee Support

Since this is a core integrated portal functionality issue impacting user experience, the most effective solution will come from the dedicated Apigee support team who can look at the server logs and the SAML flow trace.

  • Official Documentation for SAML Setup: Review this document to ensure every step of the configuration was followed precisely: Configuring SAML for the integrated developer portal

  • Contact Google Cloud Support: You should open a support case through the Google Cloud Console, specifying the product as Apigee and the category as Integrated Developer Portal or Identity and Access Management.

6

Thank you. That seemed to have worked. Took a while but switching the SAML provider off and on again, seem to have kicked in the portal refreshing.