As a solutions architect, I am tasked with many things such as working with clients to determine their needs and wants when developing an application, writing specifications and user stories, and various other tasks. One of the most important of these various other tasks includes creating proof of concepts.
Recently, one of these proof of concepts included migrating users from an ASP.NET 2.0 Membership database into an Auth0 cloud based authentication/authorization platform, and then bringing those same users into a Kentico 12
In this four-part blog series, my goal is that you too will understand all the steps in the process, what is necessary for each of these steps, and why you may (or may not) want to perform these steps. With that, let’s dive right in, shall we?
One of my frustrations with blogs is that I have to browse through the entire post before I understand what the writer is trying to accomplish, and if that is going to solve my issue. I am also one of those people that always want to see the reveal of a fixed up house on one of those fixer-upper shows at the beginning as well, but maybe it is just me. Either way, let me show you what you can expect from this blog post before I pull back the curtain.
What I have is an ASP.NET 2.0 Membership Database with several users, many of whom do not exist in Auth0 or Kentico. Let’s take Jane Doe for example…
Once Jane exists in my old membership database, I find that I am in need of a more robust single sign-on type of solution. Auth0 will do swimmingly, so I decide to implement that into a couple of my applications, including my Kentico Web Application. Now, when a user logs into my application, they are redirected to Auth0 for authentication. But Jane doesn’t exist in Auth0 yet!
No problem! Once Jane is prompted for a login from my application(s)...
her username, email, existing password, role, and whatever other information I feel is a necessity is migrated from the old ASP.NET 2.0 Membership database into Auth0 through the use of some pretty powerful Node.js scripts.
Assuming that Jane logged into my Kentico Web Application, Kentico will check to see if Jane exists as a user, if the role she is associated with exists, and if Jane is part of that role. If any one of these is not true, Kentico will do the work for us, creating Jane as a user, the Developer role, and assigning Jane to the Developer role automatically.
Kentico Role Management
At this point, you might be asking yourself, “Why wouldn’t I just use Auth0 for role management?” Well, the answer is actually very straight forward, and for a couple of reasons:
- Performance Gain. Probably the number one reason to use Kentico over Auth0 for role management is a big performance gain. Role management is built into Kentico, and integrating it with MVC is well defined, and is part of the Kentico API. Addition code “outside the box” would have to be written to check if portions of the website were available based on roles provided from a 3rd-party application like Auth0.
- Configurability. Another reason to use Kentico role management is configurability. Defining the roles that are associated with portions of the website are easily defined within the Kentico Mother. This allows for easy transparency and updates to the assigned roles. Changes are then easily handled on the MVC side of the site using the Kentico API.
So there we have it. Jane has been migrated from an ASP.NET Membership database with her existing password and role into both Auth0 and Kentico. To Jane, this was seamless. The only thing different to her might have been the login screen, but even that can be customized. No password changes were necessary, no Kentico Admin was needed to associated Jane to a role that may not have even existed in Kentico in the first place, and now I have many more options for Jane when logging into my applications. Options like Social Authentication using Google or Facebook (to name a few)
or Multi-Factor Authentication
are now options that I can control through the use of Auth0.
So, this is all fine and good, but how exactly did I get here? In part 2
of this series, I will show you the applications behind the curtain, starting with our old friend ASP.NET 2.0 Membership.