360Agileweb

Sitecore Zero-downtime deployments – Part 4

Sitecore PaaS/AKS blue-green deployments

With modern and mature DevOps, we all want smooth, sleek and painless automated deployments with zero-downtime. Sitecore deployments are no exception. Have you embraced zero-downtime deployments? This is not a new topic. If you look around Sitecore community, you see an odd question popping here and there regarding this topic.

The journey towards achieving zero-downtime deployments for any application in fact starts with your code base. So, in this series of blog posts, we will refresh ourselves on concepts like “Code Freeze” and the CI/CD process before deep diving into implementing Sitecore zero-downtime deployments.

Sitecore XP PaaS Blue-Green architecture

Sitecore XP PaaS reference architecture

The infographic above shows a typical Azure PaaS architecture for Sitecore XP scaled topology. In summary we have:

  • our Sitecore XP application roles such as CM, CD, ID among others
  • these role have access to Sitecore databases (master, web, core among others)
  • access to rest of the services such as Azure Key Vault, Azure Redis cache, App Insights, Azure Search among others

You will notice in this architecture, we have Blue-Web and Green-Web databases, which are corresponding to the BLUE-GREEN deployment slots for the CD App Service. We need separate web databases to enable us achieve content-safe deployments

The CM App Service also has BLUE-GREEN deployment slots specifically for code deployment, but with a shared master database. There is no compelling reason to have BLUE-GREEN master databases purely on basis of complexity introduced by such architecture (although it is not impossible to implement if you prefer this approach).

The rest of our XP scaled topology resources are shared

The Azure DevOps organisation typically will have access to run the CI/CD pipelines, is also included in the architecture.

How to manage settings

App Service Settings section can be leveraged to manage your Sitecore configuration settings including Sitecore connections Strings

Sitecore XP PaaS CI/CD process summary

Sitecore XP PaaS CI/CD process

Required steps:

  1. Tigger CD process
  2. Make copy of your web-db – this is for content safe deployment. Both CM and BLUE CD pointing to original web-db at this point. BLUE CD still in production with our live users accessing it
  3. Now deploy your new version to both CM instance and GREEN CD Staging slot instance – pointing them to use copy of web-db. Perform content deployment as usual, publish, rebuild the Sitecore indexes and perform any tests. This will not affect your BLUE CD at this stage.
  4. Once happy with deployment, then Swap CD production and staging slots. The GREEN CD with our new version is now production and our live users accessing it now. Zero down time achieved! Our previous version is still running in BLUE CD. If we have issues, we swap again to roll back.

Some notes:

 This example doesn’t have BLUE-GREEN for the CM instance, as I want to keep it simple – This though means your content editors will have to wait for deployment to finish to use the CM. If you really need CM zero down time, then you need to deploy CM BLUE-GREEN deployment slots as well. Alternatively, you can keep the deployment time to CM to a minimum and avoid BLUE-GREEN

You can be more also be creative with your Sitecore templates changes such that your changes are always backward compatible between successive releases  (e.g. don’t delete fields immediately, mark them as obsolete) This means you can safely rollback your changes without breaking the application

Sitecore XP AKS Blue-Green architecture

Sitecore using Containers makes use of Azure Kubernetes Service. This infographics shows a very simplified AKS blue-green strategy allows us to achieve zero downtime deployments.

Kubernetes Blue-Green strategy

How does it work?

  1. You will define a blue deployment for v1 and apply it to your desired state of your cluster.
  2. When version 2 comes along, you define a green deployment, apply it to your cluster, test and validate it without affecting blue deployment
  3. You then gradually replace V1 with V2
  4. Version 1 can be deleted if no longer needed.

Below we have a typical Sitcore XP Azure Kubernetes Service architecture for Sitecore XP scaled topology – the AKS cluster containing various pods running our containers.

Sitecore XP AKS Blue-Green reference architecture

You can see the scaled out Sitecore XP application roles running as individual Pods within this AKS cluster backed by a Windows Node Pool.

We also have access to Sitecore databases as well as other services such as Azure Key Vault, Azure Redis cache, App Insights among others.

I am showing our Azure DevOps organisations which will typically have access to run the CI/CD pipelines

Similar to the Azure PaaS architecture, AKS zero downtime deployments will make use of BLUE-GREEN deployment strategy for CD or CM instance

AKS Zero downtime deployments process

How do we do that? we don’t need to provision a separate cluster for GREEN environment. Instead, we define an additional GREEN deployment with its corresponding service and then label it accordingly, alongside our BLUE deployment.

For content-safe deployments, we will also be pointing to a copy of web database (Green) as shown.

Once we have tested and are happy with our new GREEN deployment, we switch traffic or routing to point to GREEN. We do this by updating our Ingress controller specification

Sitecore AKS Blue-Green (Green deployment)

In the above infographic, you can see now our end-users can access V2 in the GREEN deployment

BLUE deployment is on stand-by in case of roll back. And can be deleted if no longer required.

Note as previously discussed in PaaS deployments, you can implement BLUE-GREEN for the CM if required

Sitecore XP AKS CI/CD process

Sitecore XP AKS CI/CD process

Steps summary

  1. Trigger release pipeline process
  2. Make copy of your web-db – this is for content safe deployment. Both CM and BLUE CD pointing to web-db at this point. BLUE CD still in production with live users accessing it
  3. Apply your green deployment desired state onto the cluster. This creates the green pods with new version of docker images, and our Sitecore deployment including content deployment. This will use the copy of web-db we created earlier.  Publish and Rebuild indexes as usual and test and verify the deployment
  4. Once happy with deployment, Update traffic routing in Ingress Controller and live users can now access our new Sitecore version. In event of roll-back, update traffic routing in Ingress controller. If BLUE deployment no longer needed, clean it up to save on resources

Next steps

An this is a wrap. This post concludes this series of blog posts where we looked into implementing Sitecore Zero Downtime deployments. I hope you found this useful and can start your own journey towards achieving Zero Downtime deployments with your Sitecore workloads. If you have any comments or queries, please leave me a comment at the end of this post.

360Agileweb

Sitecore Zero-downtime deployments – Part 3

Blue-Green Deployments

With modern and mature DevOps, we all want smooth, sleek and painless automated deployments with zero-downtime. Sitecore deployments are no exception. Have you embraced zero-downtime deployments? This is not a new topic. If you look around Sitecore community, you see an odd question popping here and there regarding this topic.

The journey towards achieving zero-downtime deployments for any application in fact starts with your code base. So, in this series of blog posts, we will refresh ourselves on concepts like “Code Freeze” and the CI/CD process before deep diving into implementing Sitecore zero-downtime deployments.

Blue-Green deployments architecture

Blue-green deployments strategy

In software engineering, blue-green deployment is a method of installing changes to a web, app, or database server by swapping alternating production and staging servers

Wikipedia

Key Concepts

In its purest form,  true BLUE/GREEN deployments means that we need two separate but identical environments, one is live (BLUE) and the other is on stand-by (GREEN). When you have  new version of your application, you deploy to the staging environment (GREEN) , test it without affecting BLUE. When you are happy with this new version, you can then swap it to be LIVE instance.

However, in practice, it doesn’t always make sense to run a copy of every resource. Furthermore, this may introduce some complexity to the process.

This is why we now have some shared resources as you can see in the infographic above, while others belong to BLUE or GREEN environment.

As part of this architecture, we need some way of switching or routing incoming traffic between the two environments.

Blue-Green deployment strategy effectively enables us to achieve zero down time deployments. This is because your users will not notice any downtime during deployments.

CI/CD process for Blue-Green deployments

CI/CD process for Blue-Green deployments

On the top part of the infographic above, – BLUE is currently production environment and our users accessing this environment. When we have, a new version of our application, it is deployed to GREEN environment, without affecting our users.

On the bottom part of the infographic above, – now GREEN is the production environment and our users are accessing this environment.  This leaves the BLUE environment available for us to deploy the next version of our application

We deploy to BLUE and GREEN in turns, this achieving zero downtime deployments. The process repeats in each deployment cycle.

Some benefits of Blue-Green strategy

If you haven’t already adopted the cloud for your Sitecore workloads – be it PaaS or Containers, then perhaps you need to start thinking about this seriously as there are benefits you will get.

“Blue-green deployments made easier with the cloud.”

fact

The cloud provides tooling you need to:

  • Automate your provisioning and tearing down of environments
  • Automate starting or stopping of services
  • Kubernetes simplifies container orchestration for us,  the Azure Kubernetes Service (AKS) provide a Control Plane for free
  • The flexibility and cost reductions the cloud offers makes blue-green deployments within everyone’s reach at this time and age, please embrace them.

Next steps

Hopefully, these blog post help you understand key concepts about BLUE-GREEN deployments.

In the next blog post in this series, we will look at implementing Sitecore Zero Downtime deployments.

360Agileweb

Sitecore Zero-downtime deployments – Part 2

Sitecore Container based CI/CD Flow

With modern and mature DevOps, we all want smooth, sleek and painless automated deployments with zero-downtime. Sitecore deployments are no exception. Have you embraced zero-downtime deployments? This is not a new topic. If you look around Sitecore community, you see an odd question popping here and there regarding this topic.

The journey towards achieving zero-downtime deployments for any application in fact starts with your code base. So, in this series of blog posts, we will refresh ourselves on concepts like “Code Freeze” and the CI/CD process before deep diving into implementing Sitecore zero-downtime deployments.

Sitecore container based CI/CD flow

Sitecore Deployment options

Sitecore can be deployed to the cloud using IaaS, PaaS or Containers.  Microsoft Azure cloud  is preferred, although you can deploy to other providers like AWS

  • IaaS makes use of Virtual Machines
  • PaaS makes use of Azure App Service to run Sitecore web apps
  • Containers makes use of Azure Kubernetes Service (AKS)

How working with containers is different

When working outside of containers, you would typically build your application and then push it directly to the IaaS or PaaS instances hosting them. Using Containers changes this process slightly. The infographic below captures this process in detail

Sitecore containers CI/CD process summary

Explanation of the CI/CD process

  1. So developers make changes to the codebase.
  2. They then commit their changes into the repository, in this case stored in GitHub
  3. An Azure DevOps Pipeline monitors this repository and triggers a new image build each time there is a commit into the repo
  4. These images are built by Azure DevOps and the new image version is pushed into an Azure Container Registry (ACR) instance
  5. We have Other triggers for a base images that might have changed. For example, an update to the base Windows image or Sitecore image that can also trigger a new image build to occur. This is where the CI part of the process ends. We now have our new images built and available for deployment.
  6. So this is where the CD element starts. A release element is going to execute to start the deployment process.
  7. The first thing the CD element does is to push the new version of the k8s Specs into AKS, including pinning the deployments to the unique tag of the new images.
  8. AKS will now connect to the ACR instance to pull down these new images and build new deployments based on them.
  9. Of course any Sitecore deployment isn’t complete without a push of the content changes. Once the specs have been deployed the content is then also pushed to the CM instance running in AKS and a publish is executed.
  10. Once this has happened your end users can now browse the site and interact with the new containers running in AKS.

Hopefully, these blog post help you understand how to manage Sitecore Container based CI/CD process going forward. If you still struggling, engage your digital partners to look for long term solutions.

Next steps

In the next blog post in this series, we will look at BLUE-GREEN deployments and how to leverage this strategy to implement Sitecore Zero Downtime deployments.

360Agileweb

Sitecore Zero-downtime deployments – Part 1

Why Zero-downtime deployments?

With modern and mature DevOps, we all want smooth, sleek and painless automated deployments with zero-downtime. Sitecore deployments are no exception. Have you embraced zero-downtime deployments? This is not a new topic. If you look around Sitecore community, you see an odd question popping here and there regarding this topic.

The journey towards achieving zero-downtime deployments for any application in fact starts with your code base. So, in this series of blog posts, we will refresh ourselves on concepts like “Code Freeze” and the CI/CD process before deep diving into implementing Sitecore zero-downtime deployments.

Code freeze? “Thing of the past”

A Code freeze is an adopted milestone from the Waterfall days.

“No changes whatsoever are permitted to a portion or the entirety of the program’s source code. Particularly in large software systems, any change to the source code may have unintended consequences, potentially introducing new bugs”

Wikipedia

Typical Code Freeze Challenges:

  • Complex Sitecore solution with several dependencies
  • Very large code bases possibly with legacy code
  • Multiple teams from multiple geographies
  • Complex and painful code merges
  • Dedicated QA testing window
  • Multiple languages and frameworks

All these challenges may mean you introduce some “code freeze” when preparing for your deployments. Naturally, this is not where you want to be. If not managed properly, this becomes a blocker, a barrier from a true CI/CD process and your journey to your Sitecore zero down time deployments. Let’s refresh ourselves on some tips to help address some of the issues.

Solving Code Freeze Challenges:

  • Adopt a code branching strategy
  • Adopt “clean code” principles
  • Adopt microservices architecture
  • Embrace modern CI/CD processes
  • Embrace containers

Git Branching Strategy

Git Branching Strategy
  • use of feature branches off the main branch – this will isolate work in progress from completed work, avoiding “code freezes” sessions when preparing for a release. Always use Pull Requests to merge feature branch into main branch. Make use of descriptive naming of your branches as best practice
  • use of release branches off main branch when close to your release, at end of your sprint or cycle. Make use of bugfix branches for any bugs fixes in your release and merge them back to release branch
  • There are other branching options available, such as the Release flow branching strategy

Embracing Microservices

Diagram of a CI/CD monolith
CI/CD monolith v Microservices – courtesy of Microsoft Docs

Let us now look how Microservices make life easier.  A traditional monolithic app on the left, there is a single build pipeline whose output is the application executable. All development work feeds into this pipeline. If team B break, the whole thing breaks. In contrast with microservices philosophy on the right, there should never be a long release train where every team has to get in line. The team that builds service “A” can release an update at any time, without waiting for changes in service “B” to be merged, tested, and deployed.

Next steps

Hopefully, these tips help you address “Code Freeze” problem going forward. If you still struggling, engage your digital partners to look for long term solutions.

In the next blog post in this series, we will look at Sitecore CI/CD processes to support Sitecore Zero Downtime deployments.

360Agileweb

Deprecated AD Module: Your upgrade options

Sitecore Identity Server Data flows

Faced with deprecated AD module, let us look at possible  upgrade options to Sitecore version 9.3 or 10 to for your Sitecore Identity Management

1. Do not use on-premises Active Directory?

If you choose to stop using on-premises AD with your Sitecore instance, THEN:

  • You will need to upgrade from 8.2 to 9.3 or version 10 using Sitecore provided Security Database Scripts
  • You will then need use the default Sitecore Identity provider for Sitecore local users
  • This option means you will keep all existing CMS users after the upgrade
  • There will be no more on-premises AD sync needed
  • Your upgraded Sitecore Security Database is now your single source of truth for Identity Management

2. Keep on-premises Active Directory?

If you choose to keep your on-premises AD with your Sitecore instance. THEN you will need to make it work with latest Sitecore 9.3 or 10. To achieve this:

  • You will need to do a vanilla 9.3 or 10 setup, no Sitecore Security DB upgrade is necessary in this case
  • Use a custom ADFS Sitecore Identity Host plugin. You can watch a demo for this later on my YouTube channel.
  • Now we have your on-premises AD working with Sitecore Identity, so your on-premises AD users can access Sitecore instance
  • No on-premises AD sync is needed as we are using Sitecore Identity
  • On-premises AD is now your single source of truth for Identity management

3. Switch into Azure Active Directory?

Depending on your cloud transformation strategy, this is probably what you should be considering at some point

We have a couple of options here such as using Azure AD Connect or Azure AD connect Health to help with the transformation. I will also recommend working with your digital transformation partner to explore further options.

  • IF you choose to switch into Azure AD instead, THEN
  • You will need to do a vanilla 9.3 or 10 setup as we did in previous option, no Sitecore Security DB upgrade is necessary
  • Use the Azure AD Sitecore Identity Plugin that ships out of the box with Sitecore
  • Now we your Azure AD users can access your Sitecore instance
  • No Azure AD sync is needed as we are using Sitecore Identity
  • Azure AD is now your single source of truth for Identity management

Sitecore Identity Server is your answer going forward!

Next steps

You can now watch the accompanying videos on my YouTube channel. You can also read on detailed step-by-step guide on creating an ADFS plugin. Stay tuned for more posts!

360Agileweb

Sitecore Symposium 2020 highlights part one

In this series of blog posts, we will revisit the recently concluded Sitecore Symposium 2020 where I will examine my key takeaways from the event.

This year saw the biggest Symposium ever with more than 5,500 people registering across more than 70 countries. I somehow managed to get myself an All-Access ticket, which I got as reward for being a speaker during the event.

Having an All-Access ticket meant you had access to all Live, Featured and On-Demand sessions. As of the time of going to press, you can still access the Video On-demand which is very cool in case you need to re-play any of the sessions you might have missed.

In this blog, I will start with revisiting the sessions presented by the Avanade teams.

Highlights from Sessions by Avanade

At Avanade, we are a Sitecore Platinum partner and this year we proudly sponsored the Symposium 2020 event as Connector Sponsors.

Our teams were available round the clock in the Partner Pavilion where we engaged attendees in the Virtual Chats covering the following areas:

  • Avanade Industry Sales Accelerators
  • Headless Digital Experience Accelerator
  • Accelerate Business with Avanade – Here’s How

Attendees had a chance to also watch our webinars below:

On the other hand, we had our speakers running the following sessions during the Symposium:

Bringing life-changing hearing health to a global audience with Demant

This Digital & Business Transformation session saw Christian Bennich our Digital Marketing Lead in Avanade Nordic interviewing Troels Kjær Rasmussen the Head of Customer Facing Applications, Demant Group.

I really enjoyed this session as it captures what we do best at Avanade, your digital transformation partner. In the session, Troels describes how 5 years ago, Dermant Group had a challenging Business landscape with aggressive acquisitions, branding equity and other technology challenges. This impacted their Total Cost of Ownership too. Fast forward to today, the Avanade partnership has helped “Establish one strategic platform that could cater for the combined needs of the entire group”. Worth mentioning that at the core of this transformation journey is the Microsoft Azure cloud and Sitecore Experience platform.

The key takeaways from Troels includes to always aim for long term success through a repetitive model of: Realize, Learn, Scale.

I would highly recommend watching this session on-demand for the full interview.

Defining new ways to transact with Sitecore Experience Commerce 9 and Azure IoT

This Experience-focused Commerce on-demand session was presented by Benjamin Adamski, Solution Architect, Avanade and Boris Brodsky, Director of Architecture, Avanade.

During the session, Boris and Benjamin outlined the case for IoT as there is marketplace expectations for seamless and automated commerce to extend into the physical world.

Armed with staggering statistics, the Avanade duo put forward a compelling case for taking IoT seriously:

  • it is estimated that there will be 1.9 Billion 5G Cellular subscription by 2024
  • it is estimated that more than 75 Billion IoT devices will be connected to the web by 2025

Some of the key takeaways include driving the business outcomes with IoT and Connected Commerce leveraging:

  • Automated checkouts
  • Personalised discounts
  • Smart Shelves/Inventory Management
  • Automatic Supply Chain Management

This is one of those session you will want to replay and replay again, as Boris and Benjamin go on and on How to implement IoT with Sitecore leveraging Headless Sitecore Experience Commerce.

Even the losing experience is a win!

This Featured Sitecore Fundamentals session was presented by Andy Leonetti, Digital Strategist, Avanade and Leah Feldman, MarTech Strategist, Avanade.

Tapping into Andy’s 10+ years with Customer Engagement and plenty of Digital Marketing experience from Leah, the Avanade duo put together “Your guide to experimentation” with Sitecore experiences.

This session tells the story behind the framework for testing and optimising the Microsoft Partner Network that will inspire you to get testing if you are not already!

Key takeaway for me is how easy it is to leverage out-of-the-box Sitecore Experience Optimization capabilities to test and learn.

Andy and Leah summarised their session with the pointers below:

  • Make it valuable – align experiments to organisational business outcomes
  • Define & measure – define your experimentation inputs
  • Set up & run – set up your test using your measurement inputs
  • Share results – determine the experiment winner and communicate results
  • Take it to next level – Utilize Engagement value scale and generate impactful experiment ideas
  • Make it repeatable – Create a process for your team to follow and optimise

Use Sitecore Host plugin architecture to transition on-prem Active Directory workloads onto Azure

I have previously blogged about my session and how I prepared for it. You can revisit the post here.

My session was themed Problem Solving Through Technology, and I discussed how you can leverage the Sitecore Host architecture to resolve the issue of deprecated Sitecore AD module as you transition into the cloud.

Key takeaways from my session is how easy and quick to leverage Sitecore Host architecture to create custom Sitecore Identity host plugins, including free sample code samples

Conclusion and Next Steps

This concludes part one of this series of blog posts revisiting the recently concluded Sitecore Symposium 2020. Until next time, keep watching!

360Agileweb

Sitecore Symposium 2020 (Oct. 26-28, 2020) is here, jump in with me

Yes, I will be presenting for the first time!

The wait is over. Sitecore Symposium 2020 is here. This year we will have the first all-digital Sitecore Symposium. Are you excited?

Well, I am very excited indeed for two main reasons. Firstly, I am lucky that I will be presenting for the first time in a Sitecore Symposium. More about my session in a second. Secondly, I am very excited at the content and sessions that the Symposium team have put together this year.

Join me for my on-demand session on Transitioning on-prem Active Directory workloads onto Azure

You will need to Register to watch my session

How I prepared for my session

As I promised earlier, I will walk you through how I prepared for my session.

I had two review sessions with Sitecore technical teams to help review my session content and tailor it for my audience. I found these sessions useful and it helped me reduce the number of my slides in my presentation as well as amplify the right message.

All on-demand sessions should be 20 minutes long. To this end, I had to practise and rehearse my presentation using the Presenter Coach tool from Microsoft. This is a great tool to hone your presentation pace and provides great feedback such as shown in the screenshot below. I will highly encourage you give this ago

Rehearse your slide show with Presenter Coach

The actual session recording was done using the Microsoft PowerPoint recording tool. I found this tool very versatile as I could record each slide at time, watch it back and re-do it without having to start the entire recording all-over again. Below is the screenshot on how to access this tool:

Microsoft PowerPoint Record Presentation

My session also include a demo, which I recorded using an open-source the Screen Recording tool OBS Studio. I have used various screen recording tools before, but I prefer OBS due to versatility it has in terms of actual recording experience and editing afterwards.

Viewing on-demand sessions

Update: My session recording available here

Please remember to register so you have un-limited access to all on-demand sessions. Follow this session link to access my presentation titled “Use Sitecore Host plugin architecture to transition on-prem Active Directory workloads onto Azure”

The screenshot below shows the agenda at glance Please remember to select your region so that you get the localised time so you don’t miss your favourite sessions

Agenda at a glance

I am looking forward to seeing you all at the Symposium!

360Agileweb

What is new in Sitecore XP 10.0

Sitecore Experience Platform 10.0 is available now, a testament to Sitecore’s vision not only the global leader in digital experience management software, but to embrace latest cloud technologies and respond to end users and developer community.

In this version, Sitecore now officially has support for Docker, Kubernetes and other image repositories. This is a feature that will bring smiles to Sitecore community given the already buzz around containerisation and breadth of knowledge in the Sitecore community. This for sure will help delivery teams move to now famous continuous delivery model, making infrastructure-as-code deployments for Sitecore “bread and butter stuff”.

In my previous posts, I have extensively looked in Sitecore Host. In this version, Sitecore has delivered the addition of the ASP.NET Core SDK and headless rendering host architecture also provides developers with a new way of building their solutions allowing for faster development iterations. With .NET 5 release on the horizon, you get a feeling Sitecore still watching this space before committing to a long term strategy with Sitecore Host.

Other key highlights

This version focuses on product updates and enhancements that provide more development and deployment options, increase usability and improve overall performance – all centered around enabling both Marketing and IT teams equally, thus making it easier and faster to launch and evolve digital customer experiences.

  • Sitecore CLI and Sitecore for Visual Studio bring headless serialization working both with TDS and Unicorn
  • Audience analytics filters allow for deeper insights on audience engagement and segmentation to drive powerful personalization across all your channels.
  • Additional HTML Email Templates for EXM provide more options when crafting emails.
  • Horizon editing interface updates give marketers in-context insight across multilingual and multisite experiences.
  • Stronger CMP integration supports additional field types and allows for persistent taxonomy associations.
  • Salesforce Marketing Cloud (SFMC) connector updates
  • New marketing automation capabilities
  • Support for GDPR compliance journeys

I am looking forward to installing this latest version and sharing in detail the experience on this blog.

Until next time.

360Agileweb

Using Facebook Login with Sitecore Identity 9.3

Facebook for developers

Today we will walk through steps about extending your Sitecore Identity Server 9.3 to work with Facebook sub-provider. We will be creating a Sitecore Host plugin, which you should be familiar if your have read my previous blog on Sitecore Host Plugins.

Why Facebook Logins?

The scenario is that you would like your front door visitor to your Sitecore based website to be able to authenticate using their Facebook logins.

The good news is that Sitecore Identity Server can be configured as a federation gateway which means we can leverage Facebook as external provider with little effort.

What steps are needed?

  1. Register your Sitecore Application on the Facebook For Developers Portal. This process is to get an Application Identifier and Application Secret, that are needed in your Sitecore Instance. I will walk with you on how to do this process.
  2. Create and deploy a Sitecore Host Plugin that extends Sitecore Identity Server to support Facebook Logins. I will walk with you on how to create this plugin, with full access to the source code in my GitHub Repository

Register your Sitecore Application

Head to Facebook for Developers portal. On the portal, follow the link to create a new application. This will require you to specify the application display name after which, you will get a dashboard similar to this below.

Application Dashboard

Ensure you configure a redirect URL for your Sitecore Identity Server instance and save your changes. This will be of the format below:

https://Your_SI_Base_Url/signin-facebook

For example, my SI redirect URL is https://sc93identityserver.dev.local/signin-facebook

Creating Sitecore Host Plugin for Facebook Login

Sitecore Host Facebook Plugin

I have previously blogged on how to create a Visual Studio project for your Sitecore Host plugin. I will recommend you have a read before proceeding further.

We need to reference the Microsoft.AspNetCore.Authentication.Facebook package needed for Facebook login functionality for ASP.NET core applications. This is it.

Facebook AppId and AppSecret configuration

Within our Sitecore Host Plugin configuration file, we will define two properties as follows:

AppId – This will be mapped to the Application Identifier available from Facebook for Developers portal

AppSecret – This will be mapped to the Application secret availabe form Facebook for Developer portal

Provide definition of ConfigureServices for the Plugin

As per Sitecore Host Plugin requirements, we need to configure services for the subprovider according to the instructions for this provider, and specify the SignInScheme  setting as idsrv.external

To use authentication middleware, we must have an object of the type Microsoft.AspNetCore.Authentication.AuthenticationBuilder

To initialise this object, we must use 

new Microsoft.AspNetCore.Authentication.AuthenticationBuilder(services) 

instead of services.AddAuthentication()

Notice how we use AuthenticationBuilder(services).AddFacebook() pipeline below, which is available to us via the Microsoft.AspNetCore.Authentication.Facebook package we referenced earlier.

Facebook Plugin – ConfigureServices code listing

Facebook Plugin in Action

After successful deployment of this plugin to your instance of Sitecore Identity server, you should see the Sitecore Identity login screen below.

Please note you will need to re-start your IIS to pick the plugin changes.

Source code

This is it. You now have a working Facebook Plugin that you can deploy to your Sitecore Identity Server 9.3 instance. The full source code for this plugin is available on my public GitHub Repository.

360Agileweb

Doing my first Sitecore User Group talk

Developers developers

Thank you for joining us for our first London Technical User Group of the year  on February 26, 2020. This was my first technical talk at a Sitecore User Group event. And I would like to share my experience with you.

Blank Canvas

So, where do you start? Perhaps the most difficult part is finding out a topic to speak about. I could imagine this resonates with you too. I decided to talk about Sitecore Host because I believe it is an area that relatively new and has not been blogged about as much. It also gave me chance “learn by doing” as I needed to demonstrate one or two highlight features of Sitecore Host.

Nailing your topic

Having nailed the topic, I embarked on reviewing as much documentation as I could to get content for my own talk.  I also planned out the various scenarios for my technical demos. Naturally, I went for Sitecore Horizon 9.3 being the new kid in the block in the Sitecore Host front. For comparison, I also went for Sitecore Identity Server, which also gave me the opportunity to demonstrate creating and extending Sitecore Host Plugin another highlight feature for me.

So, what is your story?

The next thing was to come up with a story on why I believe Sitecore Host is so cool. For me, what is interesting about Sitecore Host is as follows:

  • Sitecore have created a pluggable architecture that gives us a framework we can extend safely using .NET Core hosting bundle.
  • Sitecore is already doing cool stuff with this framework, Sitecore Horizon 9.3, Sitecore Identity and Universal Tracker Service
  • So, what can I do with this?
    • Sitecore Identity Server as a federation gateway can be extended to work with ADFS, and many more external providers
  • So, what is the big deal? Well, if you were to implement support for ADFS in a Sitecore version prior to Sitecore Identity Server, it won’t take you hours, we are talking weeks in fact. That is a big deal for me and my clients. So, I did an experiment and timed myself. The results are out – and it took me under 2 hours to create ADFS Host plugin!!!
  • I also got a chance to share my gotchas during my preparation, which are now available for you to view on my series of blog posts accompanying the talk.

Talking the talk

And on the actual event, how do you execute your talk? How do you keep the time? Oh well this was the tricky part as I had to restart my Sitecore instances in multiple occasions during the demos…and you know how slow the instances can be in your local dev environment. That is not very time efficient. Perhaps I needed to borrow a leaf from Jeremy Davis style of presenting with pre-recorded screen capture videos of demos. And with subtle pauses which allowed him to talk about the key points, without demo getting on his way. I think I will try this next time.

I also got some constructive feedback which I would like to share with you:

  • “Talking through code is tricky – Even though this is a technical user group, there are some non-technical people in the audience. Whilst it’s ok for them not to follow, you don’t want this to last too long or they get their phones-out.”
  • “Naturally when talking through code, you have to focus on what you are talking though – physically looking at your machine. This means you are dis-engaged from the audience (think about body language) – the aim is to be able to talk through code whilst barely even looking away from the audience.“

Happy my first talk is in my back pocket now. I can’t wait for another opportunity to do another presentation in future User Group event.

The second Sitecore User Group event will be in Manchester is on Wednesday March 11, 2020 week. Grab your ticket and join the Sitecore community over there who will be digging into testing personalization and optimization, using Docker with Sitecore and have a look at the new Horizon editor.

Happy Sitecore week!