Umbraco Members and Identity Server - Part 3

The final article in a three-part series about integrating Umbraco front-end members with Identity Server for authentication and authorization. In Part 3, we remove the need for a local member and implement a custom role provider

Peter Stokes · Tuesday, April 10, 2018

In Part 1 of this series, I showed how to integrate Identity Server with Umbraco Identity plugin. But what if you already have login pages etc. and don’t need the account views that Umbraco Identity provides?

In Part 2 I showed how to implement your own login page, controller and custom Owin pipeline without the need for the UmbracoIdentity package (although still heavily influenced by it.)

In this article, we remove the need for a local member which is redundant if you are implementing your own Identity provider and it forms the single source of truth for authentication within your implementation.

Again, setting up Identity Server is identical to the process laid out in the first article so I’m not going to repeat that here.  There is, however, one change to the config to support roles.  Alter the Config.cs file with the code below:

Setting Up Umbraco

If you're not familiar with installing Umbraco then follow the instructions https://our.umbraco.org/documentation/getting-started/setup/install/install-umbraco-with-nuget to get started.

I’ve setup Umbraco to use SQL CE and installed the default starter kit.

Firstly, lets change the default port to 5001 so that it matches up with the config we setup in Identity Server earlier

Umbraco Project Properties

Roles

In a previous article we created a Member Group in Umbraco Back Office, in this article we will create a custom role provider for Umbraco which could retrieve the roles from an api.  For simplicity I will just hard-code the array of roles returned.

We need to install a nuget package first so the role provider can look for claim types.

Install-Package IdentityModel -Version 3.0.0

Now add a class to the Client project called CustomRoleProvider.cs and add the following code: 

For Umbraco to use the new provider we need to change the web.config Role Provider section. Replace with your namespace as appropriate.

Change

<add name="UmbracoRoleProvider" type="Umbraco.Web.Security.Providers.MembersRoleProvider" />

To be

<add name="UmbracoRoleProvider" type="UmbracoIdentityServer.Part3.Client.CustomRoleProvider, UmbracoIdentityServer.Part3.Client" />

Exactly as in Part 2 of the series we still need the login and access denied pages, so I’ve copied them here to save flicking between posts. 

Login and Access Denied Pages

Next, we need to open the back office and create two document types with associated templates.  Umbraco’s public access feature requires a content login page and an error page.  If you’re familiar with creating document types and content in Umbraco, then skip ahead to the next section.

In Umbraco back office create a new document type with an associated template called Login, allow this one to be created at root.  Then create another called Access Denied, again let be created at root.

Create two pages under the content node, one for login and one for access denied using the respective templates for each.

You content tree should now look like this ...

Umbraco Content Tree

Whilst we’re here let’s protect a page from public consumption.  Sorry good people of Umbraco but your mugshots are only going to be available to people logged in.

Right click the People node and select Public Access.  Choose our member group, login page and error page as per screenshot below.

Umbraco Public Access

That’s it for the Back-Office part of this article back to visual studio.

Add the following razor script to the Login view:

 And this to the access denied view:

Owin Startup

Again, as per the previous article we will setup the Owin pipeline pretty much as before.

Before we can write any code, we need some nuget packages:

Install-Package Microsoft.Owin.Security.OpenIdConnect -Version 3.1.0

First up is the Owin pipeline. Create an App_Start folder in the Umbraco solution and add two classes to the folder named AppBuilderExtensions.cs and CustomOwinStartup.cs.

The AppBuilderExtensions.cs class has a slight change to its previous incarnations to add in roles to claims transformation.

 And the code for CustomOwinStartup.cs is:

Before Umbraco will use the new startup class we need to alter the web.config to point to it.  Locate the line

<add key="owin:appStartup" value="UmbracoDefaultOwinStartup" />

Change it to:

<add key="owin:appStartup" value="CustomOwinStartup" />

Account Controller

Now let’s move on to the AccountController which is simplified version of UmbracoIdentity’s account controller.

Create a folder in the Umbraco solution called Controllers and add a class called AccountController.cs

The following code is all we need:

Job Done Again

That's it, exactly as in Part 2, run the Umbraco and Identity Server projects.  Try hitting the People page in the site and you will be re-directed to the Identity Server login page.  Login using username: test with password: password and you will be authenticated and allowed to view the page.

This article completes the series.  In this article we have shown how to integrate a custom role provider and remove the need for a local member.

You can find the complete source code for this on my github repo https://github.com/stokesy43/umbracoidentityserver-part3

If you found this post useful please share and comment.

If you have any suggestion for Umbraco subjects that you would like me to cover then please get in touch.

Share:

Peter Stokes

Peter Stokes

All author posts
;