I finally managed to get both Sitecore login (standard) and enduser login (Azure B2C AD) to work at the same time. I did a few changes and I am not 100% sure exactly which of them made the difference, so I will just list them and post the working code.
Moved the Feature.AzureB2C.config (config file for Identity provider) out of a "zFeature" folder ...
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 ...
Yes, you can use virtual users in XM:
Sitecore also supports Virtual Users, which is a transient user account system that you can use, for example, when integrating with custom authentication systems where an ASP.NET membership provider is not available or possible. A Virtual User is a user that Sitecore does not retrieve or store through an ASP.NET ...
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 ...
I heard from Sitecore support on the roles at least, so I wanted to share this answer:
The concept of the Federated Authentication means that you delegate
authentication to a trusted identity provider and all the users are
managed on the side of this provider. Based on this the User Manager
usage is not intended to maintain users from aside ...
Sitecore 9.1.0 and later enabled the Federated authentication entries by default that's why we are seeing the .\Website\App_Config\Include\Examples\Sitecore.Owin.Authentication.Disabler.config.example but not the enabler file. You can find the federated authentication related entries in the below file, just validate whether the federated is enabled or not.
If you don't want to signout of B2C when the user logs out of Sitecore, just set TriggerExternalSignOut to false in your identity provider configuration.
The external redirect feature appears to be undocumented and used internally by Sitecore to logout from IdentityServer. However, you can get it to work with your custom provider if you do a couple things. ...
I gone through into the greater details of the issue and found the solution.
I replaced the configuration for Idp Claim transformation from
<transformation name="Idp Claim" ref="federatedAuthentication/sharedTransformations/setIdpClaim" />
<transformation name="Idp Claim" type="Sitecore.Owin.Authentication.Services.SetIdpClaimTransform, ...
You are using invalid claim names in your configuration.
You should use it this way:
<map name="email claim" type="Sitecore.Owin.Authentication.Services.DefaultClaimToPropertyMapper, Sitecore.Owin.Authentication">
Treat it as a comment. I don't have enough reputation to make a real one.
Have you specified allowed sites for your external identity provider in the corresponding federatedAuthentication/identityProvidersPerSites/mapEntry node? This node must have sites sub node that contains a list of site names for which users will have access if they are authenticated ...
There a few reasons why you are facing these issues:
You are using the [Authorize] Attribute
You are doing an own mapping
Sitecore, Identity & Owin do work a little bit different that you
The way Sitecore, Owin & Identity works
Sitecore has created a piece of pipelines and stagemarkers which are run during initialization of Sitecore. ...
Probably might help someone. I managed to figure this out as the issue was on the Controller Action for SignOut.
Sitecore handles the Owin Middleware integration little differently from Asp.NET. Below is the code for my Signout Action. Here please note, we need to pass the IDP Name "AzureADB2C" explicitly for Sitecore to know which provider is being logged ...
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)
Your code is correct. Just add Microsoft.Extensions.DependencyInjectionnamespace. It contains ServiceProviderServiceExtensions extension class that adds generic methods to the IServiceProvider interface.
At the same time, I would recommend you to use a constructor injection. It is supported in Sitecore and it lets you avoid a ServiceLocator anti-pattern.
I implemented a custom user builder by inheriting from ExternalUserBuilder where i override the CreateUniqueUserName method to provide the email as username and now the user created is having username as email instead of guid based name. Not tested it fully but below is the code snippet
[SuppressMessage("Microsoft.Naming", "CA1726:UsePreferredTerms", ...
The Habitat v9 branch has a working example of how to implement this. Blog available here:
The Feature.Accounts module configures the use of the Facebook
provider, but it will also show additional buttons to any providers
Sitecore Support provided a solution for this. Basically it was to swap the position of two pipeline calls in the owin.cookieAuthentication.validateIdentity pipeline. I've put this patch into my solution and validated it worked:
Yes, you can have a SAML Federated Authentication implementation with Sitecore 10.0.1. Federated Auth is a bring-your-own-auth framework, and while most examples show OpenID Connect, you can implement whatever OWIN-based authentication that you want.
For a SAML implementation, I would recommend trying Sustainsys.Saml2. There's a good blog post from George ...
As a note, user persistence is optional with Federated Authentication.
Federated Authentication supports both virtual users and a membership-backed user. It is also possible to roll your own persistence if required.
Since the underlying Membership storage structure is unchanged, the same scaling limits apply as with previous versions.
NOTE: The official ...
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 ...
I think the code looking to instantiate your processor, is asking for the parameter-less constructor. Since you've not specified much around instantiation, this more or less has to be the case.
1) You're not following the cited Sitecore Guide which states:
To create a new processor:
Assuming you have configured federated authentication properly. You can do this by mapping claims.
This is an excerpt an example from @Bas Lijten 's blog.
As the Administrator role isn’t a real role, but more a Sitecore user
property, this “role” needs to be set in a different way. The
Propertyinitializer can be used to achieve this. First, it ...
From the above blog post I can see that you are using getSignInUrlInfo in LoginLinksController, where you are passing the returnurl as "/",
var url = "/"
var args = new GetSignInUrlInfoArgs("website", url);
You need to get the current Item URL in the controller, here and then you can pass it in the ...
As your screenshot suggests, the 2 constructors have been marked as Obsolete. You have the following options.
Mark your class as obsolete so compiler ignore these.
Ignore the warning and make sure your project doesn't have "Treat warning as errors" set on it.
Remove obsolete constructors from your class and add one that uses valid constructor. Make sure ...
We are using this same approach in our Sitecore solution. The main challenge we ran into is that the SecurityTokenValidated event from the OWIN middleware, where you receive the token, runs before the AcquireRequestState lifecycle event from IIS where the session state gets instantiated. Therefore we were unable to use the Sitecore private session state
I created a custom processor in the initializeTracker pipeline
<processor type="[custom code type]" patch:after="processor[@type='Sitecore.Analytics.Pipelines.InitializeTracker.CreatePage, Sitecore.Analytics']">
public class ...
I just recently ran into this issue myself and spent hours trying to resolve it. I could hardly find any documentation related to an SXA site (i.e. a CD site) using a federate/Sitecore Identity subprovider to login. Randomly I tried removing the site groupings, and instead used a config file to setup the site: