We have a load balanced v9.3 CM environment with 3 CMs and 1 Identity Server. The load balanced URL is https://test-cm.myclient.com/sitecore. The client would like to also be able to sign in to a single particular CM node for troubleshooting purposes. The AllowedCorsOrigins config in my Identity Server looks like this:
<DefaultClient>
<AllowedCorsOrigins>
<AllowedCorsOriginsGroup1>https://test-cm.myclient.com|https://test-cm-1.myclient.com|https://test-cm-2.myclient.com|https://test-cm-3.myclient.com</AllowedCorsOriginsGroup1>
</AllowedCorsOrigins>
</DefaultClient>
If I open a browser and go to https://test-cm.myclient.com/sitecore it redirects me to the Identity Server (https://identity.myclient.com) like I would expect. However I get an error on the Identity Server sign in page that says:
Sorry, there was an error: unauthorized_client
When I look in the Identity Server logs I see the following:
Invalid redirect_uri: http://test-cm.myclient.com/identity/signin
Notice that the redirect_uri in the logs is HTTP and not HTTPS. If I go and modify my AllowedCorsOrigins to include the HTTP version of the URLs then I don't get that error anymore. However I can't sign in because it attempts to POST back to the HTTP version of the URL and that fails.
I don't understand why when Sitecore redirects to the Identity Server it is sending along the HTTP version of the redirect_uri. I guess maybe I don't know how Sitecore constructs that redirect_uri when it redirects you to Identity Server.
NOTE: Originally I had set the following setting in Sitecore.Owin.Authentication.IdentityServer.config on each CM:
<setting name="FederatedAuthentication.IdentityServer.CallbackAuthority" value="https://test-cm.myclient.com" />
When I had that setting everything works except you can't sign in to an individual node without changing this setting. Ideally I would like to be able to sign in to either the load balance URL or an individual CM node if needed. So I commented out this setting on each CM node.
UPDATE/SOLUTION:
Thanks to Marek's answer I realized that what I had to do was create an outbound rule that modified the querystring and looked for redirect_uri
and changed it from HTTP to HTTPS. However it is even a little more complicated than that because the redirect_uri
data is escaped because it will be decoded later. So the outbound rule that worked for me looks like this:
<rewrite>
<outboundRules>
<rule name="Change Redirect URI" preCondition="IsRedirect">
<match serverVariable="RESPONSE_LOCATION" pattern="(.*)redirect_uri=http%3a(.*)" />
<action type="Rewrite" value="{R:1}redirect_uri=https%3a{R:2}" />
</rule>
<preConditions>
<preCondition name="IsRedirect">
<add input="{RESPONSE_STATUS}" pattern="3\d\d" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
<AllowedCorsOriginsGroup1>https://test-cm.myclient.com|http://test-cm.myclient.com</AllowedCorsOriginsGroup1> <AllowedCorsOriginsGroup2>https://test-cm-1.myclient.com|http://test-cm-1.myclient.com</AllowedCorsOriginsGroup2> <AllowedCorsOriginsGroup3>https://test-cm-2.myclient.com|http://test-cm-2.myclient.com</AllowedCorsOriginsGroup3> <AllowedCorsOriginsGroup4>https://test-cm-3.myclient.com|http://test-cm-3.myclient.com</AllowedCorsOriginsGroup4>