Redirection of urls, it’s a very common action, it’s important to maintain your SEO-value when URL’s move around and to provide friendly, short URLs. The only thing that you have to do is to create a permanent or temporary redirect, right? There are some solutions which add redirect functionality to Sitecore, for example the great Url Rewrite module by Andy Cohen, which is based on the IIS Url Rewrite 2.0 module by Microsoft. But there are several scenario’s when you can solve several redirects in other parts of the infrastructure, or with other products. This may, for example, be the case in in larger companies, hosting multiple Sitecore instances with multiple sites, where configuring certain types of redirects in different parts of the infrastructure can prevent a lot of other configuration in those same layers, reduce complexity or prevent issues on the permissions to configure redirects.
This blogpost explains why we chose to handle redirects in different parts of our infrastructure, from a technical and a functional perspective.
I am very happy and proud to announce that I have become a Sitecore MVP! For seven years, I have tried to become a SharePoint Server MVP, but last year I thought: screw you SharePoint, Hello Sitecore! Of course, I am just kidding ;). I have worked for years on very cool SharePoint projects, together with Microsoft, Avanade, a bunch of SharePoint MVP’s and some other very high skilled people. I had the chance to meet great people on SharePoint Saturdays, DIWUG, the SharePoint Conferences, Ignite, I shared a lot of the things we learned at Achmea on SharePoint, Security and WCM and learned a lot from the community.
Out of the box, Sitecore only offers their own forms-based authentication provider, which requires to add every user to the Sitecore membership database. At Achmea, we had the requirement to facilitate login via ADFS, as we are using our user accounts amongst different systems, web applications and apps. In addition to the absence of this functionality, it’s not possible to work with claims as well.
This blogpost describes how to add and use the Federated Authentication middleware using OWIN in combination with Sitecore and how to access the claims that are provided using the federated login. The solution supports a multi-site scenario, which can handle different identity providers and multiple realms. This opens up possibilities to use external identity providers, for example via ADFS or Windows Azure Active Directory.
The source code for federated login component can be found on github. Please feel free to contact me via twitter/mail/github if there are any questions! A special thanksto Kern Herskind Nightingale of Sitecore: We discussed a lot on the integration patterns for Federation and Sitecore.
If you want to use the recently released Visual Studio 2015 preview together with Sitecore rocks for sitecore development, you won’t be able to install this plugin from the Visual Studio Extensions gallery: you won’t even find installable plugin while searching for the plugin. This blogpost describes how to get this plugin to work.