Sitecore 9.0 has shipped and one of the new features of this new release is the addition of a federated authentication module. I wrote a module for Sitecore 8.2 in the past (How to add support for Federated Authentication and claims using OWIN), which only added federated authentication options for visitors. Backend functionality was a lot harder to integrate, but I am glad that Sitecore took the challenge and solved it for both the front- and backend. It means that I can get rid of the old code and finally can use the out of the box solution provided by Sitecore. They created a very pluggable solution which can basically register any kind of authentication module via the OWIN middleware. This blogpost will show how I integrated the Identity broker Auth0 with Sitecore. Auth0 is a platform which can act as an Identity Broker: it offers solutions to connect multiple identity providers via a single connection. Code is available at my github repository:
PS: in this example I use Auth0 as Identity broker for Facebook and Google. It’s of course possible to connect directly to Google and Facebook, I just chose not to do this.
In a previous blogpost about the Http Strict Transport Security I explained how to force connections to make use of https to encrypt connections. A lot of people think it’s expensive, hard to implement and slow. This blogpost shows off how you can get a free, secure certificate, get your Sitecore site up-and-running in no more than 5 minutes, just by using the Let’s Encrypt service. Source-code can be found here on Github.
This is not a write-up on the complete CSP specification, there are other great sources for that on the web, I included them at the end of the article.
The module will be available on the marketplace when it has passed quality control.
Sourcecode is available on: https://github.com/BasLijten/SitecoreSecurity
Secure connections? Why would I even bother? It’s expensive, slow, complex and I’ve got a firewall anyway? On the SUGCON in Copenhagen I showed off how easy it is to intercept, modify and redirect unencrypted traffic and what can be done against this threat. This blogpost is all about why you should serve your website always and fully over HTTPS and how the browser can be forced to use this HTTPS connection. This blogpost will not show off how to configure HTTPS and will not tell about all the benefits of https. The technique to achieve this is bu adding a HSTS header for your domain, google recently announced that they will introduce this for the complete www.google.com domain as well!
Note: Some other great articles have been written about this subject, but I intentionally wrote this article to reach out the Sitecore (and SharePoint) community!
The configuration is included in the blogpost below, it will also be released as a XDT as part of a bigger security project
At the upcoming Sitecore Symposium, starting on September 15th, I’ll have the pleasure of presenting a session about Sitecore Security – Keeping Hackers out: Secure Application Development for Sitecore.
Let’s face it: It’s a business nowadays to hack sites, retrieve personal information and sell them on the black markets, think of usernames, passwords, credit card details and-so-on. Often, this data is stolen using SQL injection attacks, which may be possible to your Sitecore site as well, thus, it’s better to be safe than sorry. As Sitecore ships with an old hashing algorithm to handle Sitecore users login, it’s time to replace the hashing algorithm as well. When having a fresh installation, this isn’t much of an issue, but for existing installations, you will face the challenge on upgrading your existing users, because the password hashing algorithm will be changed. This blogpost will show how to upgrade the hashing algorithm, describe those challenges, and tell you how to increase your Sitecore security.
Find the sources on https://github.com/BasLijten/SitecoreDefaultMembershipProvider for use on your own Sitecore environment!
At Achmea, we made the strategic decision to use Sitecore as platform for all of our websites, we’ve got hundreds of them. To do this at enterprise level, on such a scale, it’s important that we have guidance on infrastructure, development, deployment, security, content, DMS, just to be sure that the stable environment that we deliver, will stay stable. We all know that it’s important to work with the right Sitecore assemblies (correct version) and not to overwrite them. But Sitecore doesn’t only deliver Sitecore assemblies, but 3rd party assemblies as well, for example: Microsoft assemblies, TweetSharp, Facebook API, Google API’s, et cetera. This blogpost tells us what 3rd party components Sitecore ships with, what license is tied to it and what version is delivered. It currently only includes Sitecore 8.0 update 5 and Sitecore 8.1 update 1.
And please try to guess the answer to now: “What is the year of the eldest component that ships with Sitecore?”. You will be surprised 😉
When developing claims based web applications which need to connect to ADFS, Azure or any other STS, it’s not always possible to connect to an existing environment, for example, due to security, the absence of a test environment or an unwilling admin ;). To solve this, a lot of people try to setup a local AD, ADFS, which can cause a lot of trouble, especially in an Enterprise environment. This setup is not very convenient, especially when you just want to create a claims based application. Whenever SharePoint and Claims based hight trust provider hosted apps are thrown into the game, the inconvenient setup turns into a very complex situation.
Luckily, there is a very easy solution for this! In the next two blogposts I will show to solve this:
- How to setup a simple STS for web application development (this blogpost) – how to create a simple STS using Thinktecture embedded STS and configure the web application using the classic web.config
- How to setup claims based authentication via OWIN
- How to mix in SharePoint 2013 and hight trust claims based provider hosted apps using OWIN and the thinktecture Embedded STS
I was working on a small addition to the Thinktecture EmbeddedSTS, to ease up local development for our development teams, who are building a lot of MVC applications and SharePoint provider hosted apps. We don’t want to bother them with setting up a separate AD and ADFS, so we decided to use a simple, small STS: the Thinktecture Embedded STS. One of the actions was to add a FederationMetdata endpoint. This is a small improvement, as it’s now possible to setup claims based identities via OWIN, which is way easier to setup than via the typical web.config configuration. But there was one nifty error that was, in my case, very hard to find, but easy to fix. It turned out that the signature node may not contain any formatting, this means that spaces, line feeds and carriage returns should not be included in this Federationmetadata file
A few days ago I was reading a blog (And I forgot what blog!!) with information that the ApplicationPool password was stored as plain text. If you don’t believe me: check the screenshot below:
The password is as well accessible via the objectmodel, when runnin under elevatedPrivilges..
Lessons learned: Always try to have a least-privilegd installation for your SharePoint farm!