Hi @DigamaS.67942 (Customer)​ Thank you for posting on our Community page!

A 501 error typically indicates a server-side issue on the identity provider (Keycloak) side, often caused by a mismatch between what Okta is sending in the SAML assertion and what Keycloak expects to receive.

Root Cause: When a user migrates from one Okta tenant to another, their username, email, or other SAML attributes may change or be formatted differently. If the org2org SAML connection is still configured to send the old attribute values or format, Keycloak rejects the assertion because it cannot match the user or validate the request structure. Additionally, org2org connections are sensitive to issuer mismatches, audience restrictions, and assertion consumer service URL validation.

Resolved: Follow these steps to diagnose and fix the issue:

• Verify the user exists in your primary Okta organization with the correct username and email that will be sent in the SAML assertion. Check the user's profile in the Admin Console to confirm the attribute values.
• Review the org2org SAML connection configuration in your primary Okta tenant. Navigate to Admin Console → Applications → Applications, find the org2org app, and open the Sign On tab. Confirm that the Issuer, Single Sign-On URL, and Audience Restriction match exactly what Keycloak expects.
• Export the SAML metadata from your primary Okta organization and compare it to what Keycloak has configured. The metadata should include the correct issuer URI and certificate. Any mismatch will cause Keycloak to reject the assertion.
• Check the SAML assertion attributes being sent by Okta. Using your SAML tracer, capture a fresh authentication attempt and examine the SAML response XML. Verify that:
  • The NameID or email attribute matches the user's identity in Keycloak
  • The Audience Restriction value matches Keycloak's expected audience
  • The Destination URL matches the Assertion Consumer Service URL configured in Keycloak
  • The NotOnOrAfter timestamp is in the future
• Confirm the Assertion Consumer Service (ACS) URL in the org2org app configuration matches the ACS URL that Keycloak is listening on. A mismatch here will cause Keycloak to reject the response.
• Check Keycloak's logs for the 501 error details. The Keycloak server logs will provide more specific information about why it rejected the SAML assertion (e.g., invalid signature, missing attribute, issuer mismatch). Access Keycloak's admin console or server logs to identify the exact validation failure.
• If the user's username or email changed during migration, update the org2org SAML connection's attribute mappings to ensure Okta sends the correct identifier that Keycloak recognizes. This may require adjusting the NameID format or adding custom attribute statements.
• Test with a user who has not migrated to confirm the org2org connection itself is working. If other users can authenticate successfully, the issue is specific to how the migrated user's attributes are being sent or mapped.

If these steps do not resolve the issue, contact Okta Support with the SAML tracer output, the Keycloak error logs, and confirmation of the org2org configuration details so they can verify the tenant-to-tenant SAML flow and attribute mapping.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.

Securing AI agents across your org? Join our upcoming Ask Me Anything on 8/5 about Okta for AI Agents. Ask our expert questions.