Seems like the SAML identity provider setting page that let you configure the Entity ID is not respected.
It appears that the entity ID is derived from the sign-in URL, which is problematic for cases where the issuer and the sign-in URL do not match (custom domains).
But in general, is there a solution for cases where there is a custom domain in Auth0 and the issuer does not match the domain?
I don’t know about “Derived from”. I used an Auth0 tenant, and the entity ID is … of the form urn:HOSTNAME , where HOSTNAME is the name of the house for my developer tenant in Auth0.
So they are coincident, in the case for Auth0, but I don’t think it’s required that they be the same.
I have another that uses a name of a different format.
In the case of Okta, the entityID is of yet another different format.
What makes you say “it’s not respected”?
What are you observing that leads you to this conclusion? Is the Signin failing?
When you use the Auth0 “Debug” tool, do you see the SAML Assertion? It should have a saml:Issuer element. That is the thing you should use for entityID in the Apigee developer portal configuration panel. Is that what you’re doing?
Thanks for getting back to me. We tried the debugging in Auth0.
It turns out that when Auth0’s custom domain changes also updates the entity ID to match that same hostname. We did try this combination in Apigee, but it seems like those settings take a while to apply and take effect. In addition, we noticed that sometimes different browser sessions gave different responses after a change of saml settings in apigee. We suspect this might be because the changes weren’t fully propagated across all Apigee servers?, which confused our debugging. Anyway, it’s all sorted out now.
GREAT. Glad to hear you got it sorted out.
