Kentico 12 in All Its Glory
Welcome back! In the first three parts of this post, you were exposed to the final result, ASP.NET Membership, and Auth0. In this post, we will cover our final piece, Kentico 12 using MVC.
Need to catch up on this blog series?
- Part 1 | Introduction
- Part 2 | ASP.NET 2.0 Membership
- Part 3 | Exposing the World of Auth0
Kentico 12, or known to many of us as the Raptor, was released in December of 2018. Much of the new technology of Kentico 12 has revolved around the integration with MVC. In this post, I will show you not only how to integrate Auth0 with Kentico, but also how to do it using the MVC platform.
For my example, I will be using the Dancing Goat MVC implementation that was set up during the install of Kentico 12. In order for the Dancing Goat instance to have any knowledge about Auth0, we first need to add several keys to the web.config.
The first three keys can all be found in the tenant settings in Auth0 under the Applications section.
The final two keys are associated with the MVC application itself. The most important of these keys is the Redirect URI. This is where the code lives that will create our user in Kentico and associate that user to the correct role. These value of these keys need to be added to the Allowed Callback URL and Allowed Logout URLs sections in the Auth0 application settings.
There are several NuGet packages that will need to be installed for Auth0 to work correctly with Kentico MVC, but there are two that are significant to the successful use of Auth0.
- Microsoft.Owin.Security.OpenIdConnect. Assuming that your application is making use of OWIN, the OpenIdConnect middleware (better known as OIDC) is the easiest way to enable authentication with Auth0 and ASP.NET MVC. OIDC is an identity layer that sits on top of the OAuth 2.0 protocol and allows authentication and the ability to obtain some basic profile information about the user who authenticated.
Only one line of code needs to be added to this file. This helps to prevent scripting attacks when using Auth0.
This class deals specifically with the authentication of the application. The Configuration method handles all of the code that is necessary to handle the authentication with Auth0, setup claims that allow the application to make use of the Auth0 API, as well as store the identity token associated with the user in the cookie middleware.
There are several things in this code that should be discussed. First, notice the two claims being added in the SecurityTokenValidated section of the code. Both of these claims will contain a unique token. The id_token claim contains basic information about the authenticated user like user’s name, email, etc. The access_token claim contains credentials that are used to gain access into the Auth0 Management API. Along with these claims, the setup of the audience parameter (shown in the RedirectToIdentityProvider section of the code) is necessary to use the Auth0 Management API.
Another item of note is the AuthenticationType being set to Auth0
. This will be used with the Login and Logout methods in the AccountController. This setting is used with OIDC as a challenge and will start the authentication flow.
The Account controller contains a Login method. This method will cause OIDC to challenge the user to authenticate. In our case, the authentication type that is used is Auth0
, which matches the AuthenticationType property in the Startup.Auth.cs class.
Upon authentication, the VerifyUser method is called in the Account controller. This is where we will get information on the authenticated user that will allow us to create the user in Kentico.
This method is called once the user has successfully authenticated in Auth0. In this example, I am making use of the Auth0 Management API to get both app_metadata and user_metadata associated with the user within Auth0. This information is what will be used to create the user in Kentico (if necessary) as well as create and assign the roles associated with the authenticated user.
Setup of the user in Kentico
With the use of the user_metadata or app_metadata stored in Auth0, I first attempt to find if the user currently exists in Kentico. If the user doesn’t, they are created in Kentico prior to creating and assigning the roles for the user.
Keep in mind that the user_metadata is not necessary as the profile object contains the user’s email address which is another way to find the user.
NOTE: The given_name and family_name user_metadata were added directly in Auth0 for Jane Doe. This information was not passed back from the ASP.NET 2.0 Membership database, but it could be passed into Auth0 as well as the roles when applicable.
Setting the Role in Kentico
Once the user has been either created or returned from Kentico, the roles returned from Auth0 app_metadata need to first be created if they don’t exist and then they can be associated with the user.
In my example, Jane Doe was only associated with the Developer role, but a user might have more than one role. In that case, a JSON array of roles can be used to create and/or associate the user to those roles.
So there we have it. We have gone through the entire process of migrating a user from a legacy database into Kentico through the use of Auth0. At the end of the day, there are many different ways to achieve the same goal, but I hope this example provided some additional insight into the ease and power of both Kentico 12 MVC and Auth0.