EPiServer Owin integration - web and appSettings config changes


EPiServer Owin integration - web and appSettings config changes

EPiServer Owin integration - web and appSettings config changes


In Owin membership and role provider, the overview of the solution is given. In this blogpost, I aim to explain standard .NET Owin vs. EPiServer-integrated Owin with focus on changes in appsettings and web configuration settings.

The solution is built to support business users, not a simple website with several IP-s that are only used to provide user identity and basic info. The membership and role providers are used to serve in case of various EPiServer authorization scenarios.

appSettings default changes

Default changes (for any Owin project) in the code snippet below. The two keys are sometimes not needed, but I'd suggest you put it there (given that the application behaves differently without the settings, based on where the site using Owin runs (IIS, IIS express...)).

Default Owin (non EPi related) appSettings changes

    <!-- Owin Setup -->
    <add key="owin:AppStartup" value="EPi.Owin.Setup.Identity.Startup" />
    <add key="owin:AutomaticAppStartup" value="true" />

appSettings Membership/Role provider related changes

Additional changes I added are:

    <!-- Owin -> EPi integration -->
    <add key="DbNameForContext" value="EPiServerDB" />
    <add key="AllowRolesCreation" value="true" />
    <add key="PrefixForAllowedRoles" value="EPi_" />
    <add key="AdminRole" value="EPi_WebAdmins" />
    <add key="AdminUsers" value="YOUREMAIL@gmail.com" />
    <add key="AllUsersRole" value="EPi_AllUsers" />

Let's review each:


This is the connectionString name where Owin EntityFramework tables will be stored.


This parameter should be set to true, if creating roles in the EF (AspNetRoles) is allowed. Otherwise, creating roles from admin mode will result in NotSupportedException. This parameter might be used with *PrefixForAllowedRoles *(following below).

The parameter would most likely be set to false in case ADFS. When using with Google or other IP-s, it will most probably be set to true.


If creating roles is allowed, it might be convinient to control which roles can or cannot be created through Admin mode. Perhaps, parts of the roles are coming from Google groups (in case of Google as IP) or from some custom logic. It could be that AD gives only organizational roles, then admin and edit roles can be created from admin mode, but still one would want to differenciate them from roles that are created from claims. This way, it's also easier to search from admin mode with all roles with prefix specified.

AdminRole and AdminUsers

While it's easy to continue with using Owin membership/role provider once you are logged in, first time login might be a challenge. Hence, all comma separated users are assigned an AdminRole. Then, these admins can fork :D


Upon login, ex. Google doesn't take ANY authorization into account - meaning that there is no setting I could find that would only log in users from Google project or one domain. Generally speaking, Google (FB, Live, etc) is meant to provide identity - the rest you do yourself (the rest = authorization :)). Given that user can be from any domain, you might want to authorize only users from your own domain for a business app. Once you do any verification of this sort, you'd want to add additional role to a user - for the role that matches the access rights for the application (or part of it that is protected). In the showcase project, this is what AllUsersRole is used for.

web.config changes

Web.config default Owin changes are almost everything that is needed:

Authentication mode

Authentication mode has to be set to None; only then Owin will kick in.

    <authentication mode="None">

Owin membership and role provider setup

Membership and role providers point to Owin membership/role providers. See top image for preview.

Location path allowed roles change

EPi_WebAdmins, EPi_WebEditors need to be added to allowed roles where applicable.

Overriding logout button for edit/admin mode

Last, but not the list, EPiServer logout functionality should be overriden. Instead LogOffHandler kicks in and does a proper AuthenticationManager signout.

  <location path="util">
        <clear />
        <add name="OverrideEpiLogout" path="/util/logout.aspx" verb="GET" type="EPi.Owin.ShowCase.Web.Business.Handlers.LogOffHandler, EPi.Owin.ShowCase.Web, Version=, Culture=neutral" />        

How to use the settings

You might want to go through this article thoroughly and turn on one by one, based on the scenario for your customer. I have tried to make it configurable for various scenarios, however, I have only tested it with Google as IP. Any feedback is greatly appreciated as well as new ideas that might come in handy for speeding up the development process for other IP-s (and combinations).