44

After speaking with my friend @kamsar, he pointed out the CORS origin on the Identity Server Instance needs an update. The Identity Server doesn't allow logging in from just any url, for security reasons. Open the file C:\inetpub\wwwroot\sc910.identityserver.dev.sc.local\Config\production\Sitecore.IdentityServer.Host.xml Add a new AllowedCorsOriginsGroupN (...


11

In Sitecore 9.1 license file for Identity Server is kept in sitecoreruntime\license.xml Just replace the file with your license and restart the app.


9

With some serious Googling, and with the help of the Community and this gist I was able to successfully get a token from Sitecore 9.1's Identity Server. First, you need to add a new Client to the Sitecore.IdentityServer.Host.xml file (\Config\production\Sitecore.IdentityServer.Host.xml). I dug up more details on the PasswordClient and created my own ...


8

In 9.1, you need to patch in the path of your custom admin pages to the list of the siteNeutralPaths for the ValidateSiteNeutralPaths processor in the owin.cookieAuthentication.validateIdentity pipeline like so: <configuration> <sitecore> <pipelines> <owin.cookieAuthentication.validateIdentity> <processor type="...


7

In addition to Michaels correct answer: It is also possible to define the AllowedCorsOrigins pipe-separated. I also stuck on this and found the description in the IdentityServer WDP zip (parameters.xml): <parameter name="AllowedCorsOrigins" description="Pipe-separated list of instances (URIs) that are allowed to login via Sitecore Identity."> ...


7

I've added a new post on my blog here: https://sitecore.derekc.net/extending-sitecore-identitys-sitecore-profile-to-map-additional-profile-data/. Summary below: So three steps to add a field that exists in UserProfile to Sitecore: Add the field to sitecore.profile in Sitecore Identity Create a claim transform in Sitecore Identity Map the claim in Sitecore ...


7

Sitecore Host (the platform Sitecore Identity is built on) does have a "patching" mechanism for configuration files that is an extension of the default ASP.NET Core configuration builder. When a Sitecore Host application such is Sitecore Identity runs, Sitecore Host performs a merge of all of the .xml configuration files in the various folders in the ...


6

So after some back and forth with Sitecore Support, this is the conclusion and the solution. The fact that SXA ends up in the endless loop has been registered as a bug. Bug reference number #349107. The solution is this You need to add the site registration to SitecoreIdentity, making it a known entity for it to act on. We added the following configuration ...


6

I tried using https instead of http to access my local sitecore admin panel like this https://site.local/sitecore and it worked remember every request in sitecore 9.1 needs to be in secure SSL so use only https ! Hope it helps someone.


5

https://sitecore.derekc.net/setting-up-azure-active-directory-integration-with-sitecore-identity-server-sitecore-9-1/ might have your solution -- he writes: "just 'cuz you're in AD, doesn't mean you're automatically allowed to log in to Sitecore." You'll need to map group membership in Active Directory to roles in Sitecore. The link then walks you ...


5

SitecoreIdentityServer in the URL /identity/login/shell/SitecoreIdentityServer is just an identity provider name which is configured in Sitecore.Owin.Authentication.IdentityServer.config. It should be SitecoreIdentityServer for everyone until we change the config manually for some reasons. So basically you no need to worry about redirection to /identity/...


4

Turns out, when Sitecore sets up these instances, it does some variable replacement in various config files. On CM, the file Sitecore.Owin.Authentication.IdentityServer.config gets this replacement (near the top of the file): <sc.variable name="identityServerAuthority" value="https://[redacted]-si.azurewebsites.net" /> So the installation script ...


4

I had a similar issue and the following page from the documentation pointed me in the right direction: https://doc.sitecore.com/developers/93/sitecore-experience-manager/en/understanding-sitecore-authentication-behavior-changes.html From that page: By default, Sitecore configures the SI server provider to handle authentication for the Sitecore Client ...


4

using different domains for front- and backend is the most simple one. Cookies won't be shared between those domains.


4

I have actually blogged about how to implement this, though I am using Sitecore 9.3 in my scenario (I believe this should work in 9.2 as well) You need to do the following: Create a Sitecore Host Plugin for ADFS using OpenID. The key to this plugin is to specify these options below. I have added a screenshot of my implementation (link to Github on my blog ...


3

This generally happens when your Sitecore instances doesn't have SSL binding enabled. This is happening because the Tenant Service is using the Sitecore Client Services RESTful API to authenticate against the Sitecore Instance and the authentication method only responds over HTTPS. You can find more on the topic here - The RESTful API for the ItemService ...


3

It looks like there is an XML instead of a config file on which we can do it. website.identityserver\Config\production\Sitecore.IdentityServer.Host.xml <Settings> <Sitecore> <IdentityServer> <CertificateThumbprint>‎ABCB50CAB808CDD021A9850CF6BB8AA2B6A1B3AD</CertificateThumbprint>


3

I've figured out the answer based on the comment from @Gobinath and answer of this thread. So, first you must add NEW config for these Owin and IdentityServer stuffs and don't touch your previous version of these processes (before IdentityServer, in my case it's working properly without IS) <configuration> <sitecore> <pipelines> <owin....


3

If you issued a redirect with second parameter being default, true, this explains it. What happens in default is, the redirect gets called and then throws an exception to stop further processing. Which, in your case, means that after your processor runs - you abort the pipeline and Sitecore's OWin processing steps are never run. See: Why Response.Redirect ...


3

So it is stating that your AntiforgeryOptions.Cookie.SecurePolicy is set to Always. This means, that for the cookie to be provided to the client, the request has to start on HTTPS and stay on HTTPS. However, you should be able override the CookieAuthentication processor in the <owin.initialize> pipeline to allow the authentication cookie to be shared ...


3

Sitecore 9.3 will not work with Active Directory Module directly. In Sitecore 8.2, the AD module allows you to sync the AD on-prem users into Sitecore. This is no longer possible in Sitecore 9.3 In Sitecore 9.3 I will recommend using the Active Directory Federation Service (ADFS) approach instead. Since you can use Sitecore Identity as federation gateway, ...


3

If you want to do at Sitecore level only then you can add entry for IdentityServer log folder in <agent type="Sitecore.Tasks.CleanupAgent" of CM website but make sure you give delete access to IIS AppPool user e.g. - IIS AppPool\CMSiteAppPoolUser <remove folder="C:\inetpub\wwwroot\sc93identityserver.dev.local\logs" pattern="*.*...


2

As you are upgrading from Sitecore Commerce 9.0 follow the upgrade guide. The Sitecore Identity server is included as part of the Sitecore Experience Platform (XP) 9.1 deployment. The following instructions assume that you completed Sitecore Identity installation as part of the Sitecore XP upgrade process. You must make the following configuration changes ...


2

Sitecore 9.1.0 and later uses Identity server and Owin authentication, so Active Directory module is officially not supported. You need to set up the Federated Authentication. Refer the Sitecore document where they mentioned the same and also there are steps to setup the Federated Authentication.


2

In Sitecore 9.1, the IdentityProvidersProcessor constructor parameters got changed, you will see additional parameter like ICookieManager, BaseSettings, I missed to use these two parameters on my custom class. public class GoogleAuthentication : IdentityProvidersProcessor { public GoogleAuthentication(FederatedAuthenticationConfiguration ...


2

You can solve the problem by simply forcing all requests on the CM to be on HTTPS by using the following IIS rewrite rule on your CM instance web.config <rule name="HTTP/S to HTTPS Redirect" stopProcessing="true"> <match url="(.*)" /> <conditions logicalGrouping="MatchAny"> <add input="{SERVER_PORT_SECURE}" pattern="^0$" /> ...


2

After my investigation, it appears that the default configuration of Identity Server is federating the authentication back to the Sitecore Membership of the main Sitecore instance. The default configuration is found in $path_to_your_Sitecore_identity_instance$\Config\production\Sitecore.IdentityServer.Host.xml <?xml version="1.0" encoding="utf-8" ?> ...


2

I finally got back the answer on using the right token for authentication with iDentity server Bearer tokens. For anyone who comes behind, a sharable Postman set of APi calls can be found here. https://www.getpostman.com/collections/a98dc7091c404c879b77 Here is the basic super simple controller that returns json data. The important part is the [Authorize] ...


2

Sitecore Support responded to a ticket I opened with this question. They outlined three steps for creating the project. Create a new Class Library project Add a reference to Sitecore.Framework.Runtime.Build. Set the attribute PrivateAssets to All. Add references to other dependencies as needed: Add Sitecore.Framework.Runtime.Commands to enable commands in ...


2

I found the solution. Thanks to @Kasaku public class Startup : Sitecore.Owin.Startup { protected override void PreInitialize(IAppBuilder app) { JwtSecurityTokenHandler.DefaultInboundClaimTypeMap = new Dictionary<string, string>(); app.UseCookieAuthentication(new CookieAuthenticationOptions { CookieName = "...


Only top voted, non community-wiki answers of a minimum length are eligible