1

I have set up 2 identity provider plugins in sitecore identity, one is being used for /sitecore login the other is used for one of our portals to authenticate against. Both use Okta as the IdP, however they are using 2 different instances (one is for internal employees, the other is for application users).

The issue I am having is that when the application users hit Okta and then redirect back to the identity server /signin-idsrv endpoint the identity server falls back to using the employee version of the Okta plugin. Is there something I am missing configuration wise that can solve this issue? I believe the issue is that the identity server does not know which Okta instance is redirecting back to it and so it handles it using the first identity plugin it finds in the config.

I think this might be the issue as both plugins use the same paths currently.

options.CallbackPath = new PathString("/signin-idsrv");
options.SignedOutCallbackPath = new PathString("/signout/callback");

loginPage="$(loginPath)admin-portal/SitecoreIdentityServer/IdS4-OktaGroupPortal"

<configuration>
    <sitecore>
        <federatedAuthentication>
            <identityProvidersPerSites hint="list:AddIdentityProvidersPerSites">
                <mapEntry name="admin portal" type="Sitecore.Owin.Authentication.Collections.IdentityProvidersPerSitesMapEntry, Sitecore.Owin.Authentication" resolve="true">
                    <identityProviders hint="list:AddIdentityProvider">
                        <identityProvider ref="federatedAuthentication/identityProviders/identityProvider[@id='SitecoreIdentityServer/IdS4-OktaGroupPortal']" />
                    </identityProviders>
                    <sites hint="list">
                        <site>admin-portal</site>
                    </sites>
                    <externalUserBuilder type="MLCGP.Security.Feature.Pipelines.CustomExternalUserBuilder, MLCGP.Security.Feature" resolve="true">
                        <IsPersistentUser>true</IsPersistentUser>
                    </externalUserBuilder>
                </mapEntry>
            </identityProvidersPerSites>
            <identityProviders>
                <identityProvider id="SitecoreIdentityServer/IdS4-OktaGroupPortal" type="Sitecore.Owin.Authentication.Configuration.DefaultIdentityProvider, Sitecore.Owin.Authentication">
                    <param desc="name">$(id)</param>
                    <param desc="domainManager" type="Sitecore.Abstractions.BaseDomainManager" resolve="true" />
                    <caption>Log in with Okta</caption>
                    <icon>/sitecore/shell/themes/standard/Images/24x24/msazure.png</icon>
                    <domain>portal</domain>
                    <enabled>true</enabled>
                </identityProvider>
            </identityProviders>
            <propertyInitializer type="Sitecore.Owin.Authentication.Services.PropertyInitializer, Sitecore.Owin.Authentication">
                <maps hint="list">
                    <map name="name to FullName" resolve="true"
                      type="Sitecore.Owin.Authentication.Services.DefaultClaimToPropertyMapper, Sitecore.Owin.Authentication">
                        <data hint="raw:AddData">
                            <source name="name"/>
                            <target name="FullName" />
                        </data>
                    </map>
                </maps>
            </propertyInitializer>
        </federatedAuthentication>
    </sitecore>
</configuration>

1 Answer 1

1

If you have setup two separate identity providers in config, then you should just be able to use the Ids of those providers as part of the login paths.

See example below, which uses ADFS and Azure as two separate providers:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
    <federatedAuthentication>
      <identityProviders>
        <identityProvider id="SitecoreIdentityServer/IdS4-AzureAd" type="Sitecore.Owin.Authentication.Configuration.DefaultIdentityProvider, Sitecore.Owin.Authentication">
          <param desc="name">$(id)</param>
          <param desc="domainManager" type="Sitecore.Abstractions.BaseDomainManager" resolve="true" />
          <caption>Log in with Sitecore Identity: Azure AD</caption>
          <icon>/sitecore/shell/themes/standard/Images/24x24/msazure.png</icon>
        </identityProvider>
        <identityProvider id="SitecoreIdentityServer/IdS4-WsFederation" type="Sitecore.Owin.Authentication.Configuration.DefaultIdentityProvider, Sitecore.Owin.Authentication">
          <param desc="name">$(id)</param>
          <param desc="domainManager" type="Sitecore.Abstractions.BaseDomainManager" resolve="true" />
          <caption>Log in with Sitecore Identity: ADFS</caption>
          <icon>/sitecore/shell/themes/standard/Images/24x24/msazure.png</icon>
        </identityProvider>
      </identityProviders>
    </federatedAuthentication>
    <sites>
      <site name="your-site-name" loginPage="$(loginPath)your-site-name/SitecoreIdentityServer/IdS4-WsFederation" />
      <site name="shell" loginPage="$(loginPath)shell/SitecoreIdentityServer/IdS4-AzureAd" />
    </sites>
</sitecore>
</configuration>

Then when you go to either site to login, then it should provide a different redirect URL.

How does your config compare to the example above?

10
  • Adding that has solved it for me, my issue was that I had the wrong id (I did not prefix with SitecoreIdentityServer) Commented Aug 25, 2023 at 1:54
  • Actually this did not work once I changed the callback path specified in the Identity Provider plugin Commented Aug 25, 2023 at 5:00
  • So it logs them into sitecore shell rather than the front end application? Can you share the relevant sitecore config in question? Commented Aug 25, 2023 at 7:38
  • I have added the relevant config, did you also want the identity server config as well? Commented Aug 27, 2023 at 8:28
  • 1
    Did you create new domain and also add it to the site config. You might find info here useful deanobrien.uk/… Commented Aug 30, 2023 at 20:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.