Kevin Junghans

Customizing Claims for Authorization in ASP.NET Core 2.0

2017-08-27T21:14:00.000-04:00

There have been some major changes to ASP.NET Identity with the release of Core 2.0, which you can read about here. One of the major changes is that it does not rely on using middleware anymore to customize it. Instead dependency injection is used by configuring via services in the ConfigureServices method of StartUp.cs. There is not much documentation or examples on how to do this so I am going to explore how to customize ASP.NET Identity and publish some examples in this blog. First I wanted to look at how you would add custom claims to the identity and then use those claims for authorization.

To begin create a new ASP.NET Core Web Application project in Visual Studio 2017. Be sure to select .NET Core and ASP.NET Core 2.0 in the two drop downs at the top. Select the template for Web Application (Model-View-Controller) and Change the Authentication to Individual User Accounts. When the project is created you are ready to add some code.

For this example we are simply restricting access to an Administration page to administrators only. To indicate that the user is an administrator add a property to the ApplicationUser which is a boolean named IsAdminsitrator. You will find the ApplicationUser class in Models/ApplicationUser.cs.

    public class ApplicationUser : IdentityUser
    {
        public bool IsAdministrator { get; set; }
    }

Next we need to create a custom UserClaimsPrincipalFactory that creates a new claim that indicates if the user is an administrator or not.

    public class MyClaimsPrincipalFactory<TUser>: UserClaimsPrincipalFactory<TUser> where TUser : ApplicationUser
    {
        public MyClaimsPrincipalFactory(
            UserManager<TUser> userManager,
            IOptions<IdentityOptions> optionsAccessor) : base(userManager, optionsAccessor)
        {
 
        }

        protected override async Task<ClaimsIdentity> GenerateClaimsAsync(TUser user)
        {
            var id = await base.GenerateClaimsAsync(user);
            id.AddClaim(new Claim(MyClaimTypes.IsAdmin, user.IsAdministrator.ToString().ToLower()));
            return id;
        }
    }

Define the claim type in a class so that it can be reused later and avoid the problems caused by magic strings.

 public class MyClaimTypes
 {
     public const string IsAdmin = "http://myclaims.com/claims/isadmin";
 }

Use dependency injection in ASP.NET Core to configure the custom claims principal factory you just created by adding this line the ConfigureServices method of Startup.cs.

  services.AddTransient<IUserClaimsPrincipalFactory<ApplicationUser>, MyClaimsPrincipalFactory<ApplicationUser>>();

Now when the identity pipeline performs authentication it will call the custom claims principal factory and add the custom claims we will need for authorization. With Core we no longer create custom AuthorizeAttributes to handle the claims. Instead you need to create a custom policy. This is a fairly simple policy so we can add it like this in the ConfigureServices method of Startup.cs.

    services.AddAuthorization(options =>
    {
        options.AddPolicy("AdminsOnly", policy => policy.RequireClaim(MyClaimTypes.IsAdmin, "true"));
    });

In this simple policy we are just checking to see if the custom claim of type IsAdmin is set to either true or false. Now to test this add a custom view for Administrators and add an Authorize attribute like this.

    [Authorize(Policy = "AdminsOnly")]
    public IActionResult Administration()
    {
        ViewData["Message"] = "Page for application administration.";
        return View();
    }

Now whenever this view is invoked the AdminsOnly policy will be checked to if the identity has a claim type of IsAdmin that is set to true or not. If it is true the user will have access, otherwise they will not have access. Fire up this web application and try it out. Give the user access to this new view or not by setting the column IsAdministrator in the AspNetUsers table for the user you are testing. When you are testing keep in mind that the change to the user will not take place as soon as the change in the database table. You will need to sign the user out and back in again for it to take affect. There is a way to handle keeping your logged in users in sync with database changes when using Core Identity. We will explore that in future blog posts.

So that is all there is to add a custom claim that we can use for authorization of users. This method using policies for authorization works great if the logic is simple, but you can hit road blocks when the authorization logic gets more complex. Look for future blogs where we will explore how to handle more complex authorizations.

CodePlex is Dead. Long Live GitHub

2017-04-07T15:54:00.000-04:00

I was very sad to hear about the demise of CodePlex. I had a couple of open source projects on their site and I loved the tools provided to manage a project, especially the tight integration with Visual Studio. But alas all good things must come to an end. Always looking for a positive aspect to all situations, I decided that on the plus side this will force me to learn how to use Git for version control.

I have heard for some time all of the buzz around using Git but was quite content with using Team Foundation Version Control (TFVC). But even Microsoft is embracing Git and has offered it as an option in Visual Studio for some time now and seems to get all of the new functionality when it come to version control. Each takes a very different approach to version control, with Git being a distributed solution whereas TFVC is a centralized solution. Microsoft has a good discussion comparing the two and when to use each in this article, Choosing the right version control for your project. I can see where Git can be a better fit for open source projects.

So I am going to revive one of my old open source projects on CodePlex and move it to GitHub. The Project is VoiceModel and you can now find it here on GitHub. The project has been dormant for a while but I have been getting some requests to move it to .NET Core and Visual Studio 2017. I think that will be a great project to make the product more portable and improve performance. With the popularity of Twilio I am also thinking about adding support for this platform.

For those not familiar with VoiceModel it is a project that makes it easier to develop VoiceXML and Tropo speech applications using ASP.Net MVC and Razor. VoiceModel uses the MVVM (Model-View-VoiceModel) design pattern to abstract the voice application to a higher level and decouples the voice user interface from the application domain and call flow. VoiceModel also supports Reusable Dialog Components (RDC) which allow you to build modules that can be reused across voice applications for increased productivity. It also has a built-in easy to use state machine that allow you to easily define your call flow. With VoiceModel you can develop your voice application once and deploy it for any VoiceXML compatible IVR or the Tropo Cloud IVR.

I am excited to revive this project and will be sharing on this blog what I learn about using GitHub for open source projects and moving VoiceModel to .NET Core. So stay tuned. And if you are interested in contributing visit the VoiceModel on GitHub.

Recent Updates to SimpleSecurity

2014-10-06T09:52:00.000-04:00

The latest bits for SimpleSecurity have been updated to include the Manage controller, which allows users to change their password and their external logons. This was a major request by readers of this blog. It will also be the place where users will configure two-factor authentication. This will be the next feature added to SimpleSecurity and it will support email, SMS, and phone.

So watch these pages for a post on how to add two-factor authentication with ASP.NET Identity that supports email, SMS, and phone. With all of the cyber security attacks these days you should seriously consider adding two-factor authentication to your web site.

Using External Logins with ASP.NET Identity

2014-05-03T11:48:00.000-04:00

A feature request for SimpleSecurity has been the ability to support external logins. This has been completed and by default it supports login with a Google account. Google login is enabled because it does not require setup of any accounts on the provider side. In order to enable other social logins, like Facebook, follow this tutorial for ASP.NET Identity, which will work the same way in SimpleSecurity.

As part of this process I have also upgraded SimpleSecurity to ASP.NET Identity 2.0. This version of ASP.NET Identity has added missing features that SimpleSecurity already provided, such as email confirmation and password reset. It has also added some other beneficial features that you can read about here. Watch for future posts in this blog that will compare how the ASP.NET Identity team implemented email confirmation compared to SimpleSecurity, and I explore some of the other new features.

For those that have not been following the evolution of SimpleSecurity it originally was developed as a reference implementation on how to decouple SimpleMembership from an MVC application and to add missing features. To make the transition as easy as possible the API for SimpleSecurity mimicked the WebSecurity class used in SimpleMembership, and just like the original it was made a static class. When ASP.NET Identity became available another implementation was developed with this security framework under the hood, and again the same WebSecurity facade was used. As some readers pointed out making the API with a static class made it next to impossible to use IoC and DI. Therefore the WebSecurity class is no longer static and it inherits from IDisposable for proper cleanup of the UserManager when it is out of scope. Check out these changes and let me know what you think.

Back to external logins. I had one reader ask for a tutorial on how to tie external logins and local logins together. The example given was that a user initially sets up a local account but then decides they would rather use their Facebook account to login. How do we allow the user to now login with the Facebook account and they would still have access to the same profile and user information they had available in the local account. I started to look into this and wondered if other sites allowed for this.

I found an example in CodePlex, where SimpleSecurity can be found. I have had a local CodePlex account for years and they recently added the ability to logon with your Microsoft Live account. I tried creating a login with Microsoft Live. After logging in with Microsft Live I was prompted to either login with my local CodePlex account, to tie the two together, or register as a new user. I found the user experience to be very good. But I did not complete the process because I am still concerned about the use of social logins.

What do you think? Is this good way to implement this feature that is secure? Is this a useful feature? Some people even question the benefits of social logins and believe they are not secure. Think about it. If someone hacks into your social account now they have access to every system that you login with that account. Don't think it can happen to you? Read about this person's nightmare here. What are your thought? I am interested in hearing from you.

Performing Authorization In Class Libraries Without Coupling Security in ASP.NET Identity

2014-03-15T16:40:00.000-04:00

Most of the time it makes sense to perform authorization at the Controller or Web API level in an ASP.NET MVC application using an AuthorizeAttribute on the controller or action. This handles at least 95% of the scenarios but occasionally it makes sense to handle authorization down in a class library or it needs to be handled in code for more complex situations. An example might be an application that allows users to create folders and files that have individual permissions. In this scenario the resource being acted upon must be determined at run-time and therefore we cannot use a static AuthorizeAttribute.

So how do we determine permissions on a dynamic resource without coupling security with our application domain. This is a good time to use a custom ClaimsAuthorizationManager. A ClaimsAuthorizationManager will allow a class library to loosely couple authorization in our application domain and configure it at deployment. Here is an example on using the ClaimsAuthorizationManager that I added to the SimpleSecurity project using ASP.NET Identity. You can get the source code for this example here.

Here is how we would insert an authorization check in our class library.

    public class FakeService
    {
        public static void MyMethod()
        {
            //Here is where we would check access to perform operations in this method.
            ClaimsPrincipalPermission.CheckAccess(AppResources.Foo.ToString(), Operations.Read.ToString());
            //If we made it this far we were authorized and we would perform the actual operations here.
        }
    }

When calling the ClaimsAuthorizationManager you invoke the CheckAccess method which expects two parameters; a resource and an action. This provides context to the ClaimsAuthorizationManager on what to authorize. In this contrived example the resource and action are static, but as you can imagine they could just as easily have been derived from something like a database query or other application logic. Notice that the resource and action passed in fit nicely with the concepts I presented in an earlier article on decoupling the security model from your MVC application. If the authorization fails the ClaimsAuthorizationManager throws a SecurityException which we can handle in our controller or Web API.

What makes this method of authorization even more flexible is that we configure which ClaimsAuthorizationManager to use in the web.config. Here is what the configuration looks like for this example.

 <system.identityModel>
    <identityConfiguration>
      <claimsAuthorizationManager type="SimpleSecurity.AspNetIdentity.SimpleAuthorizationManager, SimpleSecurity.AspNetIdentity"/>
    </identityConfiguration>
  </system.identityModel>

This allows us to configure different ClaimsAuthorizationManagers for different web applications, further decoupling the authorization process from our application domain.

Here is what the code look like for this custom ClaimsAuthorizationManager.

    public class SimpleAuthorizationManager : ClaimsAuthorizationManager
    {
        public override bool CheckAccess(AuthorizationContext context)
        {
            string resourceStr = context.Resource.First().Value;
            string actionStr = context.Action.First().Value;
            int resourceId;
            Operations operationId;
            try { resourceId = Int32.Parse(resourceStr); }
            catch { throw new Exception("Invalid resource. Must be a string representation of an integer value."); }
            try { operationId = (Operations)Enum.Parse(typeof(Operations),actionStr); }
            catch { throw new Exception("Invalid action/operation. Must be a string representation of an integer value."); }

            //Get the current claims principal
            var prinicpal = (ClaimsPrincipal)Thread.CurrentPrincipal;
            //Make sure they are authenticated
            if (!prinicpal.Identity.IsAuthenticated)
                return false;
            //Get the roles from the claims
            var roles = prinicpal.Claims.Where(c => c.Type == ClaimTypes.Role).Select(c => c.Value).ToArray();
            //Check if they are authorized
            return ResourceService.Authorize(resourceId, operationId, roles);
        }
    }

This authorization process gets the roles from the current authenticated users claims and checks in the database if any of those roles are associated with the resource and operation/action that is being performed. The resource and action passed in are strings so I need to convert them to the integer ID and enumerated operation used in the database.

If the authorization process fails a SecurityException is thrown. Here is how we can catch the exception and handle it in the controller.

        public ActionResult UseClaimsAuthorization()
        {
            try
            {
                FakeService.MyMethod();
            }
            catch (SecurityException ex)
            {
                Response.Redirect(loginUrl(Url.Action("UseClaimsAuthorization", "Home")));
            }
            ViewBag.Message = "Test Claims Authorization";
            return View();
        }

        public string loginUrl(string returnUrl)
        {
             return "../Account/Login?ReturnUrl=" + HttpUtility.UrlEncode(returnUrl);
        }

In this example I handle the SecurityException just like forms authentication would and redirect to the login page. In a Web API you could return an HTTP Unauthorized error.

You can try this out by downloading the source code from SimpleSecurity, compiling and running the application. The example MVC application is in AspNetIdentity\SimpleSecurity.AspNetIdentity.RefApp. The database is seeded with a user who has a user name of "user" and password of "password" that has the role for the resource/operation authorized in this example.

I think this is a good method for handling security in your class libraries and lower layers of the application without tightly coupling your security model. What do you think? Can you think of some applications for this technique.

Migrating an Existing Website from SimpleMembership to ASP.NET Identity (Update)

2014-02-16T11:16:00.000-05:00

In a previous post I describe how to move the data from a SimpleMembership database to an ASP.NET Identity database. After some more research I found that the ASP.NET Identity Team has put together a sample solution for migrating from SimpleMembership to ASP.NET Identity that includes some SQL scripts to assist with the migration. Be sure to check out this solution on CodePlex if you are migrating your SimpleMembership website.

I also realized in my previous post that I did not mention the benefit of using SimpleSecurity in your migration. SimpleSecurity contains an implementation of ASP.NET Identity that has an API that is a super-set of the WebSecurity class used in SimpleMembership. This will allow you to plug in ASP.NET Identity into your existing code base with little to no changes. In addition it provides features such as email confirmation during registration and password reset that are not available in the initial release of ASP.NET Identity.

Happy Migrations.

Migrating an Existing Website from SimpleMembership to ASP.NET Identity

2014-02-15T13:21:00.000-05:00

ASP.NET Identity is replacing SimpleMembership as the security/membership framework to use when creating ASP.NET applications. If you are moving to MVC 5 and Visual Studio 2013 the ASP.NET templates generate code that uses ASP.NET Identity. ASP.NET Identity is much more extensible than SimpleMembership is and it uses the new OWIN architecture available in MVC 5. I think that ASP.NET Identity is an improvement over SimpleMembership and the old membership provider model that historically was used with ASP.NET applications. The main problem I have with it is the lack of documentation that is currently available. One article I was looking for in particular was how to migrate an existing website that uses SimpleMembership to ASP.NET Identity. You can move to MVC 5 and keep using SimpleMembership as I wrote about here. But what if you wanted to take advantage of benefits and features of ASP.NET Identity in a legacy website. Microsoft wrote about Migrating an Existing Website from SQL Membership to ASP.NET Identity, and Migrating Universal Provider Data for Membership and User Profiles to ASP.NET Identity, but nothing on migrating SimpleMembership.

So I researched this more and it turns out to be very simple (no pun intended) to migrate from SimpleMembership to ASP.NET Identity. The main issue with migrating is that you will need to move your existing membership data to the new database schema used by ASP.NET Identity. And the password hash used by SimpleMembership must match the one used by ASP.NET Identity. More on the password hash later.

To move your data over you first need to create a custom ApplicationUser that has the same properties as your UserProfile in SimpleMembership. For example, if your UserProfile looked like this;

    public class UserProfile
    {
        [Key]
        [DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
        public int UserId { get; set; }
        public string UserName { get; set; }
        public string Email { get; set; }
    }

Then your new ApplicaitonUser class will look like this;

    public class ApplicationUser : IdentityUser
    {
        public string Email { get; set; }
        public string ConfirmationToken { get; set; }
        public bool IsConfirmed { get; set; }
        public string PasswordResetToken { get; set; }
    }

In this example the custom property added to UserProfile is Email. You will notice that I did not add the properties UserId and UserName to the new ApplicationUser class. That is because they are already defined in the class it inherits, IdentityUser. The definition of IdentityUser looks like this.

   public class IdentityUser : IUser
    {
        public IdentityUser();
        public IdentityUser(string userName);

        public virtual ICollection<IdentityUserClaim> Claims { get; }
        public virtual string Id { get; set; }
        public virtual ICollection<IdentityUserLogin> Logins { get; }
        public virtual string PasswordHash { get; set; }
        public virtual ICollection<IdentityUserRole> Roles { get; }
        public virtual string SecurityStamp { get; set; }
        public virtual string UserName { get; set; }
    }

UserName is a direct map from UserProfile to ApplicationUser. You will notice that the Id for IdentityUser is a string. You will have to account for this in the scripts or application used to import the existing data when you map UserProfile.UserId to ApplicationUser.Id.

ASP.NET Identity flattens the table layout by keeping all of the membership data in a single table called AspNetUsers. In SimpleMembership there were two tables, UserProfile and webpages_Membership. webpages_Membership contained information like the Password, IsConfirmed and ConfirmationToken. So when mapping passwords you will need to map webpagesMembership.Password to AspNetUsers.PasswordHash. SimpleMembership had a PasswordSalt field, but it was never used. More on that later. The IsConfirmed and ConfirmationToken are not available in IdentityUser so that is why I added them to the ApplicationUser class. You only need to add these if you are using email confirmation in SimpleMembership or are planning on using it going forward. The same goes for PasswordResetToken used for password resets.

Once you have ApplicationUser defined to mimic your custom UserProfile in SimpleMembership, create the new database, and run your import script or application. If you were using roles you will need to import the role data as well. It is pretty straight map from wepages_Roles to AspNetRoles except while the id's for webpages_Roles is an int they id in AspNetRoles is nvarchar(128). The same applies when mapping wepages_UsersInRoles to AspNetUserRoles.

So now you have all of your old SimpleMembership data in your shiny new ASP.NET Identity tables will it work without further modifications. This will only work if the password hash used by SimpleSecurity is the same as ASP.NET Identity. Well it turns out they are the same.

At first glance I thought they were different because entering the same password in SimpleSecurity gave different results when entered into ASP.NET Identity. The fact that the PasswordSalt field was empty should have been a clue to what I was seeing. I did some research and found that SimpleMembership uses System.Web.Helpers.Crypto to hash and verify the passwords. To hash the password the method HashPassword is used. The password hash is generated with the RFC 2898 algorithm using a 128-bit salt, a 256-bit subkey, and 1000 iterations. The format of the generated hash bytestream is {0x00, salt, subkey}, which is base-64 encoded before it is returned. So the reason it was different each time was that this method creates a new salt each time and it is encoded in what I thought was just the straight password hash. I then ran a quick test to validate that ASP.NET Identity could verify a password hash from SimpleMembership and it worked perfectly.

What if they did use different password hash algorithms. It is very easy to plug in your own password hasher in ASP.NET Identity. First you just write a class that implements the IPasswordHasher interface. Here is one that uses the password hasher used by SimpleMembership.

 
    public class SimplePasswordHasher : IPasswordHasher
    {
        public string HashPassword(string password)
        {
            return Crypto.HashPassword(password);
        }

        public PasswordVerificationResult VerifyHashedPassword(string hashedPassword, string providedPassword)
        {
            if(Crypto.VerifyHashedPassword(hashedPassword, providedPassword))
                return PasswordVerificationResult.Success;
            else return PasswordVerificationResult.Failed;
        }
    }

And here is how we plug it into the AccountController.

 
        public AccountController(UserManager<ApplicationUser> userManager)
        {
            userManager.PasswordHasher = new SimplePasswordHasher();
            UserManager = userManager;
        }

So all we have to do to migrate our SimpleMembership website to ASP.NET Identity is create an ApplicationUser class that mimic the old UserProfile class and move the data over. Simple, isn't it.

Checkout an update to this article here.

Using Claims in ASP.NET Identity

2013-12-05T14:34:00.000-05:00

Claims can simplify and increase the performance of authentication and authorization processes. I wrote about how you can use the roles stored as claims to eliminate back-end queries every time authorization takes place. ASP.NET Identity has good support for claims-based identity and it creates several claims for you automatically when you create a new identity. Here is how we create the identity for a new user during the log-in process

UserManager<applicationuser> userManager = new UserManager<applicationuser>(new UserStore<applicationuser>(new SecurityContext()));
ClaimsIdentity identity = userManager.CreateIdentity(user, DefaultAuthenticationTypes.ApplicationCookie);

If you inspect the Claims property of ClaimsIdentity after calling CreateIdentity you will see that there are there are three or more claims. There is a claim for the user ID, user name, identity provider and one for each role assigned. So what if you want to add some more claims? Here is an example of how to add the email as a claim.

var user = userManager.Find(userName, password);
identity.AddClaim(new Claim(ClaimTypes.Email, user.Email));

ClaimTypes is an object that contains constant strings that represent the claim type. These are usually in the format of a URI. For example the Email type is "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress". If you want to add a claim that is not represented in the ClaimTypes object then you can use your own string to represent the type. I usually create a static object of my own to store any custom types. You will need to know what that constant string is when you query for the claim. Here is how we get the email claim from an identity.

var prinicpal = (ClaimsPrincipal)Thread.CurrentPrincipal;
var email = prinicpal.Claims.Where(c => c.Type == ClaimTypes.Email).Select(c => c.Value).SingleOrDefault();

So how was the custom email claim saved in the CurrentPrincipal and persisted in the cookie? It is when we call the SignIn method to complete the log-in process, passing in the identity we created with the custom claim added.

AuthenticationManager.SignIn(new AuthenticationProperties() { IsPersistent = persistCookie }, identity);

Using claims-based identity is very easy in ASP.NET Identity. But don't get carried away shoving everything about the user in as a claim. I would only keep it to items needed for authorization or that are accessed often in the application for the current user. How would you use claims-based identity in your applications?

Returning 401 HTTP Status Code on Authentication Failure in MVC 5 Web API's

2013-12-05T11:42:00.000-05:00

The behavior of how a Web API responds to authentication/authorization exceptions has significantly changed in MVC 5. First, a little background. In a previous article I demonstrated how to create a custom AuthorizeAttribute that mixes basic authentication with forms authentication when using Web API's. This custom attribute was designed to return an HTTP status code of 401 (Unauthorized) if authentication failed and a 403 (Forbidden) if the user is not authorized. The example code was written as part of the SimpleSecurity Project, which was originally written to decouple and enhance the ASP.NET membership provider SimpleMembership. I recently ported this code to work with the new ASP.NET Identity which replaces SimpleMembership in MVC 5. It turns out that during my testing of the port I did not do a good job of testing error conditions. Bad tester.

The security pipeline in OWIN and MVC 5 has changed and the custom attribute was no longer returning 401 and 403 status codes. Instead it was returning a 200 status code and inserting some additional information in the header.

X-Responded-JSON: {"status":401,"headers":{"location":"http:\/\/localhost:59540\/Account\/Login?ReturnUrl=%2Fapi%2FTestBasic"}}

So now the status code is in the header as part of this JSON object and it also contain the URL for the login page so that we can redirect to it. We could just change the logic in our client JavaScript to support this change and just get the status from the header and handle it accordingly. But if you want your application to behave the same way it was in MVC 4 there is a solution. I found the solution in this article.

You need to modify the code in your Startup.Auth.cs file to have it return the status codes you set in the response. Here is what the updated code looks like.

    public partial class Startup
    {
        private static bool IsAjaxRequest(IOwinRequest request)
        {
            IReadableStringCollection query = request.Query;
            if ((query != null) && (query["X-Requested-With"] == "XMLHttpRequest"))
            {
                return true;
            }
            IHeaderDictionary headers = request.Headers;
            return ((headers != null) && (headers["X-Requested-With"] == "XMLHttpRequest"));
        }

        // For more information on configuring authentication, please visit http://go.microsoft.com/fwlink/?LinkId=301864
        public void ConfigureAuth(IAppBuilder app)
        {
            // Enable the application to use a cookie to store information for the signed in user
            app.UseCookieAuthentication(new CookieAuthenticationOptions
            {
                AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
                LoginPath = new PathString("/Account/Login"),
                Provider = new CookieAuthenticationProvider
                {
                    OnApplyRedirect = ctx =>
                    {
                        if (!IsAjaxRequest(ctx.Request))
                        {
                            ctx.Response.Redirect(ctx.RedirectUri);
                        }
                    }
                }
            });
            // Use a cookie to temporarily store information about a user logging in with a third party login provider
            app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);

        }
    }

Now our application behaves like it did before we upgraded to MVC 5. I have updated the SimpleSecurity reference application with this modification. If you prefer to handle this change in your client code you can just remove this modification.

Decoupling ASP.NET Identify From Your MVC 5 Application

2013-11-08T09:04:00.000-05:00

For many of the same reasons I created class library that abstracts SimpleMembership I have created a class library for ASP.NET Identity. I used the same interface I used in SimpleSecurity, which is basically the interface used by the class WebSecurity in SimpleMembership. The beauty of this approach is that I could take my old models, views, and controllers from an application that used SimpleMembership and now just plugin the new ASP.NET Identity. The main difference is that anywhere that the user ID that uniquely defines a member is used it is now a string instead of an integer, because that is the default for ASP.NET Identity. There are methods to have it use an integer as well and I am debating incorporating that into this class library.

All of the code for this is open source and available on the SimpleSecurity Project. Just go to the Source Code page and download it. The class library is located in AspNetIdentity\SimpleSecurity.AspNetIdentity. The filters for authorization are located in AspNetIdentity\SimpleSecurity.AspNetIdentity.Filters and there is a reference application in AspNetIdentity\SimpleSecurity.AspNetIdentity.RefApp. The reference application demonstrates how to setup migrations, email confirmation during registration, password reset with a token, using basic authentication on Web API's, how to create an authorization attribute that uses ASP.NET Identity, and how to decouple your security model from your application model.

To use this in a new project it will have to be an MVC 5 application. If you have an existing MVC 4 application there are instruction for upgrading to MVC 5 here. You get the new MVC 5 assemblies with NuGet. You will also need to use NuGet to get the assemblies for OWIN and ASP.NET Identity. You can use the reference application to see exactly what assemblies are required. You will also need to incorporate Startup.Auth.cs in your App_Start directory and Startup.cs in the root of your application. Again, use the reference application to get the content of these classes. You will also need to configure the database initializer for migrations of SimpleSecurity database in your web.config.

I hope this helps you get a jump start on using ASP.NET Identity. The lack of documentation is rather frustrating at this time and hopefully these examples will help. I also think that using SimpleSecurity is a better approach to using ASP.NET Identity rather than the code that is generated by the T4 template that peppers your application code with Entity Framework and data storage details that should not be part of your application domain. And since ASP.NET Identity is still in flux it gives you one class library to update rather than finding code scattered in your MVC application.

As always, I am interested in ways to make SimpleSecurity better and I am interested in your comments. You can comment on this blog or on the Issues page in the SimpleSecurity project.

Adding Email Confirmation to ASP.NET Identity in MVC 5

2013-10-26T12:50:00.000-04:00

In a previous article I demonstrated how to customize the user profile information in ASP.NET Identity. Specifically I showed how to add capturing an email address for the user. We will expand on this work and add email confirmation to the registration process. This process will send an email to the user with a link they can click on to confirm their registration and log in to the system. Prior to confirmation they will not be able to log in. This process will be similar to the one I described for adding email confirmation to SimpleMembership.

First we need to modify the user information to store a the confirmation token and a flag indicating whether confirmation was completed or not. So now our ApplicationUser looks like this.

    public class ApplicationUser : IdentityUser
    {
        public string Email { get; set; }
        public string ConfirmationToken { get; set; }
        public bool IsConfirmed { get; set; }
    }

If you have already made changes to the ApplicationUser before you will need to enable migrations and add a migration for these changes to take affect. Now we can capture this information during the registration process and send the email.

        private string CreateConfirmationToken()
        {
            return ShortGuid.NewGuid();
        }

        private void SendEmailConfirmation(string to, string username, string confirmationToken)
        {
            dynamic email = new Email("RegEmail");
            email.To = to;
            email.UserName = username;
            email.ConfirmationToken = confirmationToken;
            email.Send();
        }

        //
        // POST: /Account/Register
        [HttpPost]
        [AllowAnonymous]
        [ValidateAntiForgeryToken]
        public async Task<ActionResult> Register(RegisterViewModel model)
        {
            if (ModelState.IsValid)
            {
                string confirmationToken = CreateConfirmationToken();
                var user = new ApplicationUser()
                {
                    UserName = model.UserName,
                    Email = model.Email,
                    ConfirmationToken = confirmationToken, 
                        IsConfirmed = false };
                var result = await UserManager.CreateAsync(user, model.Password);
                if (result.Succeeded)
                {
                    SendEmailConfirmation(model.Email, model.UserName, confirmationToken);
                    return RedirectToAction("RegisterStepTwo", "Account");
                }
                else
                {
                    AddErrors(result);
                }
            }

            // If we got this far, something failed, redisplay form
            return View(model);
        }

To generate the token I use a class called ShortGuid that takes a GUID and encodes it so that it is shorter and is URL safe. I got the code for this class from this blog. I add the generated token to the new user and set IsConfirmed to false. Then I send the email. I use Postal to generate the emails. Postal uses the Razor engine to create your dynamic email content that can include content such as the user name and the custom URL with the confirmation token. The redirect to the RegisterStepTwo action just displays a view to the user that tells them to look for the email to complete the registration process.

Once the user gets the email they click on the link that will take us back to the controller action RegisterConfirmation.

        private bool ConfirmAccount(string confirmationToken)
        {
            ApplicationDbContext context = new ApplicationDbContext();
            ApplicationUser user =  context.Users.SingleOrDefault(u => u.ConfirmationToken == confirmationToken);
            if (user != null)
            {
                user.IsConfirmed = true;
                DbSet<ApplicationUser> dbSet = context.Set<ApplicationUser>();
                dbSet.Attach(user);
                context.Entry(user).State = EntityState.Modified;
                context.SaveChanges();

                return true;
            }
            return false;
        }

        [AllowAnonymous]
        public ActionResult RegisterConfirmation(string Id)
        {
            if (ConfirmAccount(Id))
            {
                return RedirectToAction("ConfirmationSuccess");
            }
            return RedirectToAction("ConfirmationFailure");
        }

The method ConfirmAccount does a query to see if we can find a user with the confirmation token that was passed in the URL. If we find a user we set IsConfirmed to true and return true from the method; otherwise we return false. If the user is confirmed they will be able to log in. To make sure that the user could not log in before confirmation we need to make a small change to the Login action.

        [HttpPost]
        [AllowAnonymous]
        [ValidateAntiForgeryToken]
        public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)
        {
            if (ModelState.IsValid)
            {
                var user = await UserManager.FindAsync(model.UserName, model.Password);
                if (user != null && user.IsConfirmed)
                {
                    await SignInAsync(user, model.RememberMe);
                    return RedirectToLocal(returnUrl);
                }
                else
                {
                    ModelState.AddModelError("", "Invalid username or password.");
                }
            }

            // If we got this far, something failed, redisplay form
            return View(model);
        }

All we do is check that if we find a user that the IsConfirmed flag is set to true. If it is false then we do not log the user in and generate an error message.

That is all there is to setting up email confirmation using ASP.NET Identity in MVC 5. You can get the source code for this example from the SimpleSecurity Project. You can find it in the AspNetIdentity folder.

One observation is that I had to make low level EF calls using the DbContext to make this work. The UserManager provided by ASP.NET Identity to encapsulate EF and provide access to ApplicationUser did not provide me with enough control to do what I needed to accomplish. It makes sense to me to add another layer on top of ASP.NET Identity that makes it easier to use and decouples it from the web application. I decoupled SimpleMembership from the web application and it worked well. Look for something like this for ASP.NET Identity in the future that will be open source and available in the SimpleSecurity Project.

Upgrading a Web Application Using SimpleMembership to ASP.NET MVC 5

2013-10-25T11:33:00.000-04:00

I recently tried to upgrade the SimpleSecurity reference application from MVC 4 to MVC 5 and ran into some issues. SimpleSecurity encapsulates and decouples SimpleMembership from your ASP.NET application and the underlying issue was compatibility with the WebMatrix assemblies that SimpleMembership uses and the new assemblies for MVC version 5, Web API version 5, and Razor version 3.

I followed the instruction for upgrading to MVC 5 that are posted here and received this error on application start.
Attempt by security transparent method 'WebMatrix.WebData.PreApplicationStartCode.Start()' to access security critical method 'System.Web.WebPages.Razor.WebPageRazorHost.AddGlobalImport(System.String)' failed.

I did some research and found that others were having the same issue. Well it turns out I did not follow the instructions exactly. Here is one note in the instructions I did not pay close attention to.

Note: Microsoft-Web-Helpers has been replaced with Microsoft.AspNet.WebHelpers. You should remove the old package first, and then install the newer package.

I opened up the NuGet Package Manager and installed the package Microsoft.AspNet.WebHelpers and things started to work. Note that when you create a new MVC 5 application and try to incorporate SimpleSecurity or SimpleMembership you will hit the same issue because Microsoft.AspNet.WebHelpers is not installed by default. It has to be present for SimpleMembership to run correctly.

I verified that all of the features in the reference application are working correctly after the upgrade. Even the generation of the emails using Postal worked, which I was not sure of because of the upgrade of Razor as well.

One change I needed to make to the SimpleSecurity assembly was to remove the filters AuthorizeAttribute and BasicAuthorizeAttribute and put them in a separate assembly. I did this because they are dependent upon MVC and Web API assemblies. So now there is a version for MVC 4 and another for MVC 5.

You can get the source code for the MVC 5 version of the Reference Application from the SimpleSecurity Project Source Code page. You will find it under SimpleSecurityMVC5\SeedSimpleUpgradeTo5.

Customizing ASP.NET Identity in MVC 5

2013-10-21T15:40:00.000-04:00

For those of you that follow my Blog you know that one of the subjects I write a lot about is customizing SimpleMembership for ASP.NET security in web applications and some of you have been asking if I have tried using it with Visual Studio 2013 RC or Preview. Recently I have taken the time to explore using SimpleSecurity and SimpleMembership with VS 2013 RC and more recently the final release now available to MSDN Subscribers. The short of it is there are problems with upgrading to MVC 5, which was released to coincide with VS 2013, as described in this StackOverflow QA. You can still develop your MVC 4 applications in VS 2013 but you will miss out on some of the new features available in MVC 5 and Razor 3.

The other problem is that SimpleMembership is going away in MVC 5 as the provider for ASP.NET security. Microsoft has gone to another membership provider called ASP.NET Identity. In this article I will start looking at how to customize ASP.NET Identity and contrast that with using SimpleMembership. There are a number of new features and benefits in ASP.NET Identity that you can read about here. The benefits and the fact that this is the chosen direction for ASP.NET security make a compelling reason to look into using this going forward.

It turns out that it is quite simple to customize the user profile in ASP.NET Identity. First I started by creating a new MVC 5 application. You no longer select whether you want an Internet or Intranet application, you just select the MVC template and select the authentication type you want to use. For an Internet type application you select Individual User Accounts. Once your web application is created open IdentityModels.cs in the Models directory. You will see a class called ApplicationUser which is analogues to the UserProfile in SimpleMembership. It is an empty class that inherits from IdentityUser which has these properties.

    public class IdentityUser : IUser
    {
        public IdentityUser();
        public IdentityUser(string userName);

        public virtual ICollection<identityuserclaim> Claims { get; }
        public virtual string Id { get; set; }
        public virtual ICollection<identityuserlogin> Logins { get; }
        public virtual string PasswordHash { get; set; }
        public virtual ICollection<identityuserrole> Roles { get; }
        public virtual string SecurityStamp { get; set; }
        public virtual string UserName { get; set; }
    }

What you will notice from this implementation is that the Id is no longer an integer as it was SimpleMembership. It now uses a string which the default implementation stuffs with a GUID. In this example I will just add an email address to the user so we can look at adding email confirmation in a later article. Here is what it looks like.

    public class ApplicationUser : IdentityUser
    {
        public string Email { get; set; }
    }

Now to allow the user to enter their email address during registration I first update the registration model.

    public class RegisterViewModel
    {
        [Required]
        [Display(Name = "User name")]
        public string UserName { get; set; }

        [Required]
        [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
        [DataType(DataType.Password)]
        [Display(Name = "Password")]
        public string Password { get; set; }

        [DataType(DataType.Password)]
        [Display(Name = "Confirm password")]
        [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
        public string ConfirmPassword { get; set; }

        [Required]
        [Display(Name = "Email address")]
        public string Email { get; set; }

    }

And then I update the View to include a label and text box for the email.

   <div class="form-group">
        @Html.LabelFor(m => m.Email, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.TextBoxFor(m => m.Email, new { @class = "form-control" })
        </div>
    </div>

To test this out I changed the About page to display the current users email. This also shows how we can access user information in the application.

    public ActionResult About()
    {
        ViewBag.Message = "Your application description page.";
        UserManager<ApplicationUser> UserManager = new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()));         
        var user = UserManager.FindById(User.Identity.GetUserId());
        if (user != null)
            ViewBag.Email = user.Email;
        else
            ViewBag.Email = "User not found.";

        return View();
    }

That is all there is to customizing the user information you can store when using ASP.NET Identity. In a future article I will look at how we can add email confirmation to ASP.NET Identity.

Also follow this Blog for future updates as I continue to investigate if you can upgrade an existing MVC 4 application with SimpleMembership to MVC 5. It would be nice to migrate an existing application to MVC 5 without throwing away your whole security model and database.

Improving Performance of SimpleMembership By Using Claims-Based Access Control

2013-10-01T09:17:00.000-04:00

Claims-based identity and access control became first class citizens with the introduction of .NET version 4.5. This along with integrating Windows Identify Foundation (WIF) has added some very powerful security features to .NET 4.5. In this article I will look how we can make a simple changes to SimpleSecurity to make it more efficient and reduce the number of times we need to hit the database during authorization by retrieving some of the information we need from claims. If you are not familiar with claims there is a good introduction here.

I originally introduced the idea of decoupling the security model from the application by creating a custom AuthorizeAttribute that accepted a resource and operation instead of a role. You can read more about it here and some later improvements here. In these designs I override the OnAuthorization method and it looked like this.

   public override void OnAuthorization(AuthorizationContext actionContext)
   {
       base.Roles = ResourceService.GetRolesAsCsv(_resourceId, _operation);
       base.OnAuthorization(actionContext);
   }

This was implemented by getting a list of roles as a comma separated string that was added to the base Roles property and then called the base OnAuthorization method to complete the authorization process. Pretty straight forward. The problem I found is that calling the base OnAuthorization method requires two database calls; one to get the user ID from the user name of the current principal and then look up in the webpages_UsersInRoles table and the joined webpages_Roles table to see if there is a match with the list of roles provided to the OnAuthorization method.

It turns out that is completely unnecessary because the claims in the current principal already contain the roles for the user. And this information is persisted in the authentication cookie so that it does not have to hit the database for every HTTP request. So how do we take advantage of this. First of all in our custom AuthorizeAttribute we override the AuthorizeCore method instead of the OnAuthorization method. It looks like this:

protected override bool AuthorizeCore(HttpContextBase httpContext)
{
    //Get the current claims principal
    var prinicpal = (ClaimsPrincipal)Thread.CurrentPrincipal;
    //Make sure they are authenticated
    if (!prinicpal.Identity.IsAuthenticated)
        return false;
    //Get the roles from the claims
    var roles = prinicpal.Claims.Where(c => c.Type == ClaimTypes.Role).Select(c => c.Value).ToArray();
    //Check if they are authorized
    return ResourceService.Authorize(_resourceId, _operation, roles);
}

The steps are described in the comments. First we get the ClaimsPrincipal of the current user. Then we check to make sure they are authenticated. If they are not then we just return false and the authorization will fail. Next we query the claims using LINQ to get a string array of roles. This is then passed to a method to see if we have can match any of the user's roles to roles assigned to the resource/operation. If there is a match it returns true, if not it returns false. We still have to do a database look-up to get the roles assigned to the resource/operation, but we have eliminated several queries to get the users roles.

Now you might be thinking, why don't we put the roles for all of the resources and operations in the claims also. It turns out that .NET 4.5 makes it easy to put additional claim information into the current principal and even handles breaking the information into multiple cookies if it gets too large. But that is a topic for a future article. Adding this information to the claims would depend on the application and the number of resources, operations, and roles used. We do not want to make the cookie too large and pass it around all of the time.

I will tackle adding more claims in another article because there is other useful information we can add to the claims. For example, the user ID, which is the foreign key in a lot of other databases/tables for tying user information to other information in the system. Usually when you want to query information based on the current user you get the user name from the principal, do a database query to get the user ID, and then query for the information we a looking for. We can eliminate this intermediate step by putting the user ID in the claims.

You can get the source code and example application from the SimpleSecurity Project on CodePlex. Just go to the Source Code tab and select the download link.

Decoupling Your Security Model Revisited

2013-09-30T11:48:00.002-04:00

I while back I wrote an article "Decoupling You Security Model From The Application Model With SimpleMembership". In this article I proposed a design change to how the AuthorizeAttribute is used that provides a decoupled security model that is more flexible as your ASP.NET MVC application evolves. One reader provided good comments on what he did not like about the design, with one major issues being the use of magic strings to define the resources and operations that we are authorizing against. If you recall from the previous article we define the custom AuthorizeAttribute like this.

    [SimpleAuthorize(Resource = "UserProfile", Operation = "modify")]
    public ActionResult ModifyUserProfile()
    {
        ViewBag.Message = "Modify Your Profile";
        return View();
    }

This is a valid concern so I revisited this design and came up with a solution that eliminates magic strings and will actually perform better. Here is what our SimpleAuthorize looks like now.

    [SimpleAuthorize(AppResources.UserProfile, Operations.Update)]
    public ActionResult ModifyUserProfile()
    {
        ViewBag.Message = "Modify Your Profile";
        return View();
    }

In the old design there was an Operations table that contained all of the operations for each resource. This normalized design was very flexible and allowed for unlimited operations per resource. But in reality there are usually just a few operations used and they are mostly for your CRUD operations. In the new design I eliminated the Operations table and added them directly to the Resource table as an enumerated type. Here is how I defined my Operations.

    [Flags]
    public enum Operations : int
    {
        None = 0,
        Create = 1,
        Read = 2,
        Update = 4,
        Delete = 8,
        Execute = 16,
        All = 31
    }

Notice that I have defined this enum as Flags. This allows me to store any combination of operations in this enumerated type using bit operations. I can also use the Enum.HasFlag method to see if an individual operation is in an instance of the enum. I added the types None and All for ease of initialization; they are not considered valid operations.

I also changed the identifier for the Resource table to not be generated by the database. This way the developer can use an enumerated type or static object with constants to define the resources available in their application. Here is how the I initialized the resources and operations in the Seed method of the database initializer used in the SeedSimple example application.

    //Build the operations available for this resource
    Operations operations = Operations.Read;
    operations |= Operations.Create;
    //Add the resource
    ResourceService.AddResource(AppResources.Foo, "Foo", operations);
    //Map the resource/operation to the roles
    ResourceService.MapOperationToRole(AppResources.Foo, Operations.Read, "User");
    ResourceService.MapOperationToRole(AppResources.Foo, Operations.Create, "Admin");

Unfortunately we still have to use magic strings for the roles because Microsoft designed it that way. Besides eliminating the magic strings for SimpleAuthorize filter this design will perform better because we do not have to join the Resource and Operations tables and we are performing look-ups on integers instead of strings.

As always you can get this code from the SimpleSecurity Project on CodePlex to look into more of the details and play around with the code. Let me know what your thoughts are in the comments on whether this is a better design or not.

Multiple Recordings and Copying Recordings in VoiceModel

2013-09-13T09:23:00.001-04:00

I had a couple of enhancement requests in the VoiceModel Project around making user recordings. The first request was to allow the directory that holds the recordings to be specified as a file structure or file share. And the second request was to allow multiple recordings in a single session. I finally got some time to look at implementing these enhancements and was pleasantly surprised that the features were already in place because of the flexibility in the VoiceModel architecture and state machine. Well, for the most part. I will explain one little change I had to make to VoiceModel to get this to work.

To test this out I updated the RecordingExample project in the VMWithExamples solution. You can get the source code here. Basically my solution was to add an On-Exit-Action to the recording state that copies the recorded file to another location. This satisfies the request to be able to put recording in another location, including a file share. Here is what the On-Exit-Action looks like.

flow.AddState(ViewStateBuilder.Build("getRecording", "playback",
    new Record("getRecording", "Please record your information after the beep.  Press the pound key when you are finished."))
    .AddOnExitAction(delegate(CallFlow cf, State state, Event e)
    {
        VoiceModel.Logger.ILoggerService logger = VoiceModel.Logger.LoggerFactory.GetInstance();
        try
        {
            //Copy last recording to another location
            string recordingPhysicalPath = Server.MapPath(RecordingPath);
            string recordingFileName = recordingPhysicalPath + "//" + cf.SessionId + ".wav";
            logger.Debug("Copying recording " + recordingFileName);
            System.IO.File.Copy(recordingFileName, "c://tmp//" + cf.SessionId + "_first.wav");
        }
        catch (Exception ex)
        {
            logger.Error("Error copying recording: " + ex.Message);
        }
    }), true);

That is all that is required to copy your recording to any location and even rename them. You will notice that I kept the session ID in the name to make sure the file name was unique and would not be copied over by another call into the system. You can use any scheme you would like to manage these file. For example, maybe you collected a unique caller identifier earlier in the voice application that you could use to organize recordings by caller.

It turns out this helps satisfy the second requirement for multiple recordings. Since we can copy the recording to another location for safe keeping we can just add another Record object in the application and it will replace the original recording. Then you just copy it again to another location using a different file name. I tested this out in the example and it works fine. The first recording I named [SessionId]_first.wav and the second recording I named [SessionId]_second.wav.

But I did find a problem on playback of the recordings. The URI for audio recording for the first and second recordings are the same since the file name is solely base on the session ID. I used Voxeo Cloud VoiceXML Platform to test this and it does an excellent job of caching audio files which I did not want in this case. This caused the application to voice back the first recording when the caller should have been listening to the second recording. I solved this by changing VoiceModel to specify not the use cache in the HTML header when retrieving audio recordings. You can get the latest release of VoiceModel with this fix on NuGet. This would have also been an issue if you are setting up something like a voice mail system with VoiceModel, where you give the caller a chance to re-record what they have already recorded. Playback would always just used the first recording.

This example also demonstrates how easy it is to add logging to your VoiceModel applications. This proved invaluable when troubleshooting initial issues when trying to copy recordings. The only other thing you need to do to add this logging is make sure you have a log4net config file in the root of your application directory.

I love it when enhancement requests can be handled with very little change to the code.

SessionAuthenticationModule Causes Strange Redirect Behavior

2013-08-08T11:19:00.000-04:00

I was working on a web project using ASP.NET MVC 4 when I started seeing some strange behavior. Some of my AJAX calls to ASP.NET Web API services were getting redirected back to the same URL. The only difference between the original URL used to make the call and the redirected URL was changes in case sensitivity. While this could just be annoying and cause some performance issues this was causing my application real issues because the redirected web request was missing some header information. Specifically I was using basic authentication on the calls to the Web API's and the header was missing the authentication information and therefore this was causing the requests to fail authentication/authorization. For the life of me I could not figure out what was causing the redirects.

Then I started thinking back to what had changed in the application that may have introduced this behavior. I had added the use of the SessionAuthenticationModule so that I could store claim information in cookies. This allowed me to keep important information in the claim principal without having to transform it on every request and therefore hitting my back-end database every time. You can read about adding this valuable feature to your web application in this great article by Dominick Baier. If you have access to PluralSight I would also recommend viewing Dominick's training course Identity and Access Control in ASP.NET 4.5 which also covers this topic in great detail.

So to find a solution I Googled SessionAuthenticationModule and redirect and came across this article that described my problem to a tee. Apparently this is a known behavior of using the SessionAuthenticationModule. If you use this module and you use the wrong case for the URL it will redirect back to the same URL using the proper case. And as I pointed out it will leave some header information out of the new web request. Why they worried about case sensitivity when IIS does not is beyond my comprehension.

So the solution was to fix the case of any URLS in any AJAX calls and any client requests for server resources to match what the web application uses. Problem solved. I thought this experience was worth repeating since finding this obscure issue can be hard to troubleshoot.

Decoupling You Security Model From The Application Model With SimpleMembership

2013-08-03T11:44:00.000-04:00

One of the peeves I have with ASP.NET MVC and how security is handled is that you have to design your security model up front while you are designing your web application. You have to determine which roles you need to have while implementing your application so that you can add them to the Authorize attribute on the controllers actions. Here is an example of how you control access to controller actions.

   [Authorize(Roles = "admin,user")]
    public ActionResult DoSomething()
    {
        ViewBag.Message = "Do something really spectacular.";
        return View();
    }

Now when we want to change our security model, such as adding new roles, we have to go through the whole application changing these Authorize attributes, recompile the application, and redeploy. This coupling causes a lot of inefficiencies.

But you can customize SimpleMembership to handle this in a better way that decouples the security model form your application domain. I will demonstrate how to do this based on the work that has already been started on customizing SimpleMembership in the SimpleSecurity project. This is an open source project you can find on GitHub which demonstrates methods to enhance SimpleMembership. The design of this enhancement is to use a customized Authorize attribute that does not take roles as parameters; instead it uses a resource parameter and an operation parameter. A resource is an abstract representation of an item in your application domain. An operation is an action you are going to perform on that resource, such as read, write or modify. An example might be that you have a web application that lets a user modify their profile. In this case you could label the resource as "UserProfile" and the operation would be "modify". Here is an example of what our new Authorize attribute will look like.

    [SimpleAuthorize(Resource = "UserProfile", Operation = "modify")]
    public ActionResult ModifyUserProfile()
    {
        ViewBag.Message = "Modify Your Profile";
        return View();
    }

It is important to point out that MVC 4 has two types of Authroize attributes; one used for controller's that manage views (System.Web.Mvc.AuthorizeAttribute) and one used for Web API controllers (System.Web.Http.AuthorizeAttribute). Each has very different behavior because of what they are controlling. For this article we discussing how to customize the Authorize attribute for controllers that manage views. We will look at customizing the one for Web API's in a later article.

So how is resource and operation used to determine what controller actions a user has access to. Users are still assigned to roles, but now we map the roles to resource/operations. For a user to have access the resource/operation must have a role assigned that the user has. Now when we change our security model we do not have to modify any code, instead we configure it in our database. To implement this design we need to customize the SimpleMembership database. Here is what the new database looks like.

We have added a new table called Resources which contains all of the resources for the application and Operations which contains all of the operations for a resource. The relationship between operations and resources is one resource to many operations. Operations are then mapped to roles in the OperationsToRoles table. This is a many-to-many relationship. To see how these tables were added to the SimpleMembership database look at the source code in the SimpleSecurity project. The new entities are defined in SimpleSecurity\Entities. This project uses a Repository and Unit of Work design pattern and you can see the implementation for this in SimpleSecurity\Repositories. The details for the entities configuration and relationships are done using the Fluent API and can be found in SimpleSecurity\Repositories\ModelConfiguration.

So how did we customize the Authorize attribute to work with resource and operations instead of roles. Lets take a look at the code.

    [AttributeUsageAttribute(AttributeTargets.Class | AttributeTargets.Method, Inherited = true,
    AllowMultiple = true)]
    public class SimpleAuthorize : AuthorizeAttribute
    {
        public string Resource { get; set; }
        public string Operation { get; set; }

        public override void OnAuthorization(AuthorizationContext actionContext)
        {
            base.Roles = ResourceService.GetRolesAsCsv(Resource, Operation);
            base.OnAuthorization(actionContext);
        }

    }

We inherit from the standard AuthorizeAttribute and override the OnAuthorization method. The implementation is pretty straight forward. Now we just get a list of the roles assigned to the resource/operation by calling ResourceService.GetRolesAsCsv (Csv stands for comma separated values) and pass these roles to the base AuthorizeAttribute class. ResourceService is an application domain layer on top of the repositories for handling resources and operations.

You can test this out in the example project in SimpleSecurity called SeedSimple. Download the source code for this project and run it to see how it works. I have added two new actions to the HomeController.

    [SimpleAuthorize(Resource = "Foo", Operation = "Read")]
    public ActionResult ReadFoo()
    {
        ViewBag.Message = "Read Foo";
        return View();
    }

    [SimpleAuthorize(Resource = "Foo", Operation = "Write")]
    public ActionResult WriteFoo()
    {
        ViewBag.Message = "Write Foo";
        return View();
    }

I also modified how the database is seeded to add the resources/operations and their role mapping.

        protected override void Seed(SecurityContext context)
        {

            WebMatrix.WebData.WebSecurity.InitializeDatabaseConnection("SimpleSecurityConnection",
               "UserProfile", "UserId", "UserName", autoCreateTables: true);
            var roles = (WebMatrix.WebData.SimpleRoleProvider)Roles.Provider;
            var membership = (WebMatrix.WebData.SimpleMembershipProvider)Membership.Provider;

            if (!roles.RoleExists("Admin"))
            {
                roles.CreateRole("Admin");
            }
            if (!roles.RoleExists("User"))
            {
                roles.CreateRole("User");
            }
            if (!roles.RoleExists("SuperUser"))
            {
                roles.CreateRole("SuperUser");
            }
            if (!WebSecurity.FoundUser("test"))
            {
                WebSecurity.CreateUserAndAccount("test", "password", "test@gmail.com");
            }
            if (!roles.GetRolesForUser("test").Contains("Admin"))
            {
                roles.AddUsersToRoles(new[] { "test" }, new[] { "admin" });
            }
            if (!WebSecurity.FoundUser("joe"))
            {
                WebSecurity.CreateUserAndAccount("joe", "password", "joe@gmail.com");
            }
            if (!roles.GetRolesForUser("joe").Contains("User"))
            {
                roles.AddUsersToRoles(new[] { "joe" }, new[] { "User" });
            }
            List<operation> operations = new List<operation>();
            operations.Add(new Operation() {Name = "Read"});
            operations.Add(new Operation() {Name = "Write"});
            ResourceService.AddResource("Foo", operations);
            ResourceService.MapOperationToRole("Foo", "Read", "User");
            ResourceService.MapOperationToRole("Foo", "Write", "Admin");
 
        }

As you can see from this code the resource/operation Foo/Read is assigned to the role of User and Foo/Write is assigned to the role of Admin. The user joe is assigned the role User and the user test is assigned to the role Admin.

Run the application and select the tab Read Foo. If you are not logged in you will be taken to the logon page. Log in as joe with the password of password. You will be redirected to the Read Foo page because joe has authorization for this page. Now select the Write Foo tab and again you will be redirected to the logon page because joe does not have authorization for this page. Log in as the user test and you will be redirected to the Write Foo page because user test does have authorization.

So now we can use SimpleMembership without worrying about our security model changing. We can change our security model by just changing our database configuration instead of making code changes, recompiling them and redeploying. Another benefit is we can defer designing our security model until we are ready to deploy. We no longer have to design our security model while we are implementing the application. What do you think about this design? Please let me know your thoughts in the comments.

Using Code-First Migration With SimpleMembership

2013-04-25T10:59:00.000-04:00

In previous posts I have written about customizing and seeding SimpleMembership, the newest membership provider used in ASP.NET MVC 4 Internet applications. In the example in this previous post we setup a database initializer that can be set to either to a type of DropCreateDatabaseAlways or DropCreateDatabaseIfModelChanges. As the name implies DropCreateDatabaseAlways will drop the database and recreate it every time the initializer is called, which is at application start, and will run the method to seed the database after creation. DropCreateDatabaseIfModelChanges varies in that it will only recreate the database if the database model changes in your code. Both of these approaches work great during development and unit testing but you would not want to deploy the solution this way for production. This is where code-first migration comes in.

Code-first migration allows you to update the database without having to recreate it and therefore loosing the data that is already in the database. An obvious must have for production systems. To show how we can implement this in SimpleMembership I will start with the decoupled version of SimpleMembership called SimpleSecurity. You can read about SimpleSecurity and the concept behind it here. It turns out that adding migration is fairly straight forward. To follow along you can download the project for SimpleSecurity here. Note that if you get the latest version it will already have migration enable, but I will cover the steps here so that you can do this from scratch if needed.

To enable migrations go to the Package Manager Console and make sure your default project in the console is set to the project that contains your data layer (i.e. DbContext). For SimpleSecurity the project with the data layer is also called SimpleSecurity. Then enter the command "enable-migrations". This will create a new folder in your data layer project called Migrations and it will contain a new file named Configurations.cs. If Entity Framework can find your database and detect any changes it will also create a CSharp file that contains code for the initial migration. The Configuration file contains this code.

    internal sealed class Configuration : DbMigrationsConfiguration<SimpleSecurity.Repositories.SecurityContext>
    {
        public Configuration()
        {
            AutomaticMigrationsEnabled = true;
        }

        protected override void Seed(SimpleSecurity.Repositories.SecurityContext context)
        {
            //  This method will be called after migrating to the latest version.

            //  You can use the DbSet<T>.AddOrUpdate() helper extension method 
            //  to avoid creating duplicate seed data. E.g.
            //
            //    context.People.AddOrUpdate(
            //      p => p.FullName,
            //      new Person { FullName = "Andrew Peters" },
            //      new Person { FullName = "Brice Lambson" },
            //      new Person { FullName = "Rowan Miller" }
            //    );
            //
        }
    }

This is the new database initializer that will be used for database migration. When EF creates this the setting for AutomaticMigrationsEnabled is set to false. I changed this to true so we can start with automatic migrations. The other type of migration is called code-based migrations. Code-based migration is much more powerful and the likely choice for production system because of the control it provides. But it is a much larger topic that we will have to cover in later posts. So for this article we will just cover automatic migrations.

If you recall from the article on Seeding & Customizing ASP.NET MVC SimpleMembership we set which initializer to use in code using the SetInitializer method.

 Database.SetInitializer<userscontext>(new InitSecurityDb());
 UsersContext context = new UsersContext();
 context.Database.Initialize(true);
 if (!WebSecurity.Initialized)
    WebSecurity.InitializeDatabaseConnection("DefaultConnection",
         "UserProfile", "UserId", "UserName", autoCreateTables: true);

We cannot do that with the Configuration class because it is defined as internal sealed. If we wanted to set it programmatically there is no problem with changing to the definition of Configuration to public. But the better way to do this is to set it in the web.config like this.

  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
    <contexts>
      <!--Use this initializer if you want to use datbase migration-->
      <context type="SimpleSecurity.Repositories.SecurityContext, SimpleSecurity" disableDatabaseInitialization="false">
        <databaseInitializer
          type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[SimpleSecurity.Repositories.SecurityContext, SimpleSecurity],
               [SimpleSecurity.Migrations.Configuration,  SimpleSecurity]], EntityFramework" />
      </context>
      <!--Use this initializer if you are testing and want to create a new database for each test.-->
      <!--<context disabledatabaseinitialization="false" type="SimpleSecurity.Repositories.SecurityContext, SimpleSecurity">
        <databaseInitializer
          type="SimpleSecurity.DropCreateSecurityDb, SimpleSecurity" />
      </context>-->
    </contexts>
  </entityFramework>

You will notice that I have two initializers set in this configuration with one being commented out. The one that is not commented is the one for migrations, the one that is commented out is for an initializer that performs a drop-create. This way I can easily switch between the initializers since I may want to use the drop-create initializer during testing. Now we can easily set our initializers through a configuration change. Just be sure to remember to remove Database.SetInitializer from your code.

Now when you have it configured for automatic migrations any changes to your model will automatically update the database with these changes without loosing your data, with one exception. If you remove a property from the model and there is data in the corresponding column in a table the migration will throw an exception. If you want to allow the removal of a column with data you need to set AutomaticMigrationDataLossAllowed to true in the Configuration class constructor.

Automatic migration is a powerful feature of Entity Framework. Look for future posts where we will discuss code-based migrations.

Using SimpleMembership With Mobile Applications In ASP.NET MVC 4

2013-04-22T21:17:00.000-04:00

Someone recently asked on StackOverflow if you can use the SimpleMembership provider in a mobile application generated by the mobile template for ASP.NET MVC 4. The shell of the mobile application generated by this template generates basic security, such as logging in, logging out, registration and password reset, but it uses the older ASP.NET membership and role providers. So I thought this would be a good exercise to see if I could use the open source project SimpleSecurity to switch the mobile application to use the SimpleMembershipProvider. SimpleSecurity helps decouple SimpleMembership from an MVC application. It turns out that it was quite easy to add SimpleMembership to an ASP.NET MVC mobile application when using SimpleSecurity.

First add the SimpleSecurity assembly as a reference in your mobile project. You will also need to add WebMatrix.Data and WebMatrix.WebData as references. In the properties for these two assemblies set the property Copy Local to true.

Next modify your web.config to use the SimpleMembership providers. Replace the settings for the providers in the template generated web.config to the following.

    <roleManager enabled="true" defaultProvider="SimpleRoleProvider">
      <providers>
        <clear/>
        <add name="SimpleRoleProvider" type="WebMatrix.WebData.SimpleRoleProvider, WebMatrix.WebData"/>
      </providers>
    </roleManager>
    <membership defaultProvider="SimpleMembershipProvider">
      <providers>
        <clear/>
        <add name="SimpleMembershipProvider" type="WebMatrix.WebData.SimpleMembershipProvider, WebMatrix.WebData" />
      </providers>
    </membership>

Add the following line to the Application_Start method in the Global.asax to register SimpleSecurity.

    WebSecurity.Register();

Finally we need to modify the actions in the AccountController that were generated by the mobile template. Here are the modifications to the POST Login action.

        [AllowAnonymous]
        [HttpPost]
        [ValidateAntiForgeryToken]
        public ActionResult Login(LoginModel model, string returnUrl)
        {
            if (ModelState.IsValid)
            {
                if (WebSecurity.Login(model.UserName, model.Password, model.RememberMe))
                {
                    if (Url.IsLocalUrl(returnUrl))
                    {
                        return Redirect(returnUrl);
                    }
                    else
                    {
                        return RedirectToAction("Index", "Home");
                    }
                }
                else
                {
                    ModelState.AddModelError("", "The user name or password provided is incorrect.");
                }
            }

            // If we got this far, something failed, redisplay form
            return View(model);
        }

And here are the changes to the LogOff action.

       public ActionResult LogOff()
       {
           WebSecurity.Logout();

           return RedirectToAction("Index", "Home");
       }

You will also need to change the Register action.

        [AllowAnonymous]
        [HttpPost]
        [ValidateAntiForgeryToken]
        public ActionResult Register(RegisterModel model)
        {
            if (ModelState.IsValid)
            {
                // Attempt to register the user
                bool createdUser = false;
                string errMessage = string.Empty;
                try
                {
                    WebSecurity.CreateUserAndAccount(model.UserName, model.Password, model.Email);
                    createdUser = true;

                }
                catch (Exception ex)
                {
                    errMessage = ex.Message;
                    createdUser = false; 
                }

                if (createdUser)
                {
                    if (WebSecurity.Login(model.UserName, model.Password))
                        return RedirectToAction("Index", "Home");
                    else
                        ModelState.AddModelError("", "Error logging user in with that username/password.");

                }
                else
                {
                    ModelState.AddModelError("", errMessage);
                }
            }

            // If we got this far, something failed, redisplay form
            return View(model);
        }

And lets not forget the ChangePassword action.

        [HttpPost]
        [ValidateAntiForgeryToken]
        public ActionResult ChangePassword(ChangePasswordModel model)
        {
            if (ModelState.IsValid)
            {

                // ChangePassword will throw an exception rather
                // than return false in certain failure scenarios.
                bool changePasswordSucceeded;
                try
                {
                    UserProfile currUser = WebSecurity.GetCurrentUser();
                    changePasswordSucceeded = WebSecurity.ChangePassword(currUser.UserName, model.OldPassword, model.NewPassword);
                }
                catch (Exception)
                {
                    changePasswordSucceeded = false;
                }

                if (changePasswordSucceeded)
                {
                    return RedirectToAction("ChangePasswordSuccess");
                }
                else
                {
                    ModelState.AddModelError("", "The current password is incorrect or the new password is invalid.");
                }
            }

That is it. Your mobile application will now use the SimpleMembership provider instead of the old-style ASP.NET providers. If you would like the source code for this example you can get it here.

Password Reset with SimpleMembership

2013-04-11T11:21:00.001-04:00

SimpleMembership is the new security provider that is bundled with ASP.NET MVC 4 when you use the Internet Template to create a new application. In this article I will demonstrate how to add password reset to your MVC application using SimpleMembership. For this demonstration I will use SimpleSecurity, an open source project that decouples SimpleSecurity from your MVC application. The concepts in this article still apply if you do not use SimpleSecurity and you just want to use SimpleMembership directly.

The basic steps for changing a password when using SimpleMembership is to first generate a unique token that is emailed to the user as a link. Then the user clicks on the link passing the token in the query string. The user is presented with a web page to enter the new password and when they submit it the token is verified and if it passes the new password is updated in the users membership information. This method of password reset is very flexible since it can be used to just change the password, as well as allow a user to reset their password if they forgot it.

This method of password reset only works if we confirmed the email address during the registration process. Read this article to see how to add email confirmation to the registration process. The advantage of using SimpleSecurity is that it is already configured to support email confirmation. Just as in the email confirmation for registration we will use Postal to send the email for password reset.

To start the password reset process I added an action link to the log-in page for the user to click on.

When the user clicks on the link they are taken to another page which asks them to enter their user name and press the Reset Password button.

Pressing this button sends control to the action PasswordReset.

        [AllowAnonymous]
        [HttpPost]
        public ActionResult ResetPassword(ResetPasswordModel model)
        {
            string emailAddress = WebSecurity.GetEmail(model.UserName);
            if (!string.IsNullOrEmpty(emailAddress))
            {
                string confirmationToken =
                    WebSecurity.GeneratePasswordResetToken(model.UserName);
                dynamic email = new Email("ChngPasswordEmail");
                email.To = emailAddress;
                email.UserName = model.UserName;
                email.ConfirmationToken = confirmationToken;
                email.Send();

                return RedirectToAction("ResetPwStepTwo");
            }

            return RedirectToAction("InvalidUserName");
        }

First this method gets the user email address based on the user name. Note that in this example I am using SimpleSecurity.WebSecurity instead of WebMatrix.WebData.WebSecurity, which has methods for retrieving the email address. If you are using straight SimpleMembership you will need to develop your own methods to do this, which is described in this article. If we do not get an email then the user name is invalid and we present the user with a view that lets them know. If we have a good email we generated the password reset token by calling WebSecurity.GeneratePasswordResetToken with the user name, then create and send the email using Postal. If this is successful we take the user to view that lets them know an email has been sent to them with further instructions for resetting the password.

When the user clicks on the link in the email they are directed to the action ResetPasswordConfirmation.

        [AllowAnonymous]
        public ActionResult ResetPasswordConfirmation(string Id)
        {
            ResetPasswordConfirmModel model = new ResetPasswordConfirmModel() { Token = Id };
            return View(model);
        }

This action gets the token from the query string and puts it in the ResetPasswordConfirmationModel that is passed to the view which allows the user to enter the new password. The new password is entered twice to make sure they entered it correctly. When they submit this information they are taken to the POST version of this action.

       [AllowAnonymous]
        [HttpPost]
        public ActionResult ResetPasswordConfirmation(ResetPasswordConfirmModel model)
        {
            if (WebSecurity.ResetPassword(model.Token, model.NewPassword))
            {
                return RedirectToAction("PasswordResetSuccess");
            }
            return RedirectToAction("PasswordResetFailure");
        }

This action gets the token and new password from the model passed back from the view and calls WebSecurity.ResetPassword to do the actual password reset. If it is successful the user is presented with a view letting them know that the password was reset and that they should log on with their new password. If it fails they are presented with a view that tells them as such.

That is the fundamentals of adding a password reset to an ASP.NET MVC application with SimpleMembership. If you would like the complete source code for this example you can get it here.

Retrieving Confirmation Token in SimpleMembership

2013-04-02T11:36:00.005-04:00

A reader commented on my blog "Adding Email Confirmation to SimpleMembership" that they would like the ability to resend the email confirmation to users that did not receive it for whatever reason. This seemed like a reasonable request and it is actually asked a lot on various forums. The problem is that WebMatrix.WebData.WebSecurity does not provide a method to retrieve the confirmation token so that you can resend the email. The token is only provided when you call CreateUserAndAccount and set requireConfirmationToken to true. It turns out the only way to get the confirmation token in SimpleMembership is to directly query the webpages_Membership table. I have encapsulated this functionality in the open source project called SimpleSecurity.

SimpleSecurity encapsulates WebSecurity and adds missing features like getting the confirmation token. It also decouples the security model from the ASP.NET MVC framework. Now you can just call SimpleSecurity.WebSecurity.GetConfirmationToken with the user name as a parameter and it will return the confirmation token. I have added an example of how to resend the registration email in the reference application in this project which is called SeedSimple.

In the example I use the login page to allow the user to resend the email. When the user logs in, if they fail authentication then I check if the user is in the system and if they have not completed the confirmation process. If they are not confirmed I provide them with a message informing them to look for the email to complete the registration process or to resend the email. Here is what that page looks like.

Here are the modifications to the Login action to make this work.

       public ActionResult Login(LoginModel model, string returnUrl)
        {
            string errorMsg = "The user name or password provided is incorrect.";

            if (model.IsConfirmed)
            {
                if (ModelState.IsValid && WebSecurity.Login(model.UserName, model.Password, persistCookie: model.RememberMe))
                {
                    return RedirectToLocal(returnUrl);
                }
                else if (WebSecurity.FoundUser(model.UserName) && !WebSecurity.IsConfirmed(model.UserName))
                {
                    model.IsConfirmed = false;
                    errorMsg = "You have not completed the registration process. To complete this process look for the email that provides instructions or press the button to resend the email.";
                }

            }
            else //Need to resend confirmation email
            {
                ResendConfirmationEmail(model.UserName);
                errorMsg = "The registration email has been resent. Find the email and follow the instructions to complete the registration process.";
                model.IsConfirmed = true;
            }

            // If we got this far, something failed, redisplay form
            ModelState.AddModelError("", errorMsg );
            return View(model);
        }

I modified the LoginModel to include a flag named IsConfirmed which lets me manage the state of the view that is displayed and whether I should try to authenticate the user or resend the email confirmation. The method to resend the email confirmation look like this.

        private void ResendConfirmationEmail(string username)
        {
            string email = WebSecurity.GetEmail(username);
            string token = WebSecurity.GetConfirmationToken(username);
            SendEmailConfirmation(email, username, token);
        }

There were also some changes to the Login view to make this work. You can get the source code for this project here. And if you have any suggestion on how to improve SimpleSecurity you can post them here or just comment on this blog.

Create Proactive Notification Applications with VoiceModel

2013-03-26T12:27:00.001-04:00

The latest release of VoiceModel now provides support for developing Proactive Notification Applications using a telephone. Proactive notifications are used to notify customers of important events or information that they are interested in. The media channel currently supported by VoiceModel is voice over the telephone. Some notification systems also support channels such as SMS and email. An example application would be a pharmacy notifying you that your prescription is ready for pickup. With VoiceModel you can develop a notification system once and it will run on any VoiceXML compatible IVR or Tropo.

I personally find notification systems very useful. I like being kept being informed on events like, my Amazon order was delivered, my flight was delayed, or my kid should be bringing home a report card today. This type of notification is beneficial, but I do not like SPAM. Do not bombard my phone with sales and advertising. Not only is this annoying, it is illegal. Be sure to understand the Federal rules and regulations around notifications via the telephone before developing a notification system, or you could be slapped with a very large fine. There, I warned you.

Now that we have the legal issues out of the way lets see how you implement a notification application. VoiceModel has a new object/model called Call. Call accepts as parameters the phone number to dial, the phone number the call is from that will show up in the Caller ID (optional), and the URI for the controller that contains the voice application to play when the call is answered. Here is what a simple application might look like.

    public class CallMeController : VoiceController
    {
        public override CallFlow BuildCallFlow()
        {
            string phoneNumber = ConfigurationManager.AppSettings["phoneNumber"];
            string callerId = ConfigurationManager.AppSettings["callerId"];
            string dialogUri = this.ApplicationUri + "Outbound";
            CallFlow flow = new CallFlow();
            flow.AddState(ViewStateBuilder.Build("call", new Call("callMe", phoneNumber, callerId, dialogUri)), true);
            return flow;
        }
    }

In this example I am getting the phone number to call and caller ID from configuration settings in the web.config. The dialogUri is the explicit path for the MVC/VoiceModel controller that contains the voice application I want to play to the caller when they answer. There is a new example project in the source code called OutboundCall that demonstrates how to implement this simple notification system.

This simple example demonstrates the basics for outbound notification but is not very useful for a production application. I am adding to the Road Map for VoiceModel a project that demonstrates how to manage a list of people to notify. This can be challenging because it is a queue that has temporal information (time windows for notification so we do not call in the middle of the night) and information for retries on failed calls. We are always looking for contributors if you want to tackle this interesting project. Just contact me on CodePlex if you are interested.

Another feature I would like to add for proactive notification is using a different voice application dependent upon whether a machine or a human answers. If a machine answers (i.e. voice mail) then it does not make sense to have the voice application ask for information (ex: "Would you like to continue getting updates on our progress on getting the power outage in your area fixed?") when the machine will not respond. In this case you may want to play a different message that provides a phone number for them to dial for an inbound IVR application. The challenge is that VoiceXML applications are pretty good at determining whether a machine or human has answered, whereas Tropo does not distinguish between the two. This puts a kink in my vision of developing an application once and having it behave the same on a VoiceXML IVR as it does on Tropo. And perhaps Twilio in future versions.

One of the reasons that VoiceXML does much better at determining whether a human or machine answered is that the calls are initiated using Call Control XML (CCXML). CCXML provide much better call control and call progress analysis. Which brings up an important point when deploying VoiceModel notification systems. When configuring an application that uses VoiceXML for the voice application you need to configure the starting app as CCXML with the URL for the Controller that has the Call object. For Tropo you configure it as any Tropo application , again using the URL for the Controller that has the Call object.

And how do we initiate the call since the application is not being triggered by an incoming phone call? If you are using Tropo's development environment you first need to get permission from Voxeo Customer Support to make outbound calls from their system by creating a support ticket making the request. Once you have permission you go to where you defined your application in the Tropo Development Web Site and there will be a section called Outbound Tokens. Click on the one that says Voice and this will bring up a dialog that you click on the Launch Token button. This will start your outbound application. Voxeo Prophecy for VoiceXML works in much the same way when using their development environment. This will work fine when you are testing. If you want to automate this process for production you will need to develop an application that makes HTTP requests that passes this token in. It is basically a REST API that is documented on their web sites.

Decoupling SimpleMembership From Your ASP.NET MVC Application

2013-03-08T14:42:00.001-05:00

I recently came across a question in StackOverflow on making SimpleMembership "N-Tier Friendly". The author of the question correctly pointed out that the code generated by the Internet template tightly couples SimpleMembership with the rest of the web application, peppering the application with code at the database level. What the author was really looking for was if anyone had taken the time to write SimpleMembership as a separate layer that he could reuse. My answer was that SimpleMembership was designed to be highly customizable and therefore any library written to decouple SimpleMembership from the application would not be reusable. That being said I thought it would be a good exercise to provide an example of how you could go about writing a library that abstracts SimpleMembership and has the features that we have covered so far in this blog, such as email confirmation and basic authentication. And since I am making the source code available anyone can take this code as a starting point and customize it to their application requirements.

I have put the VS 2012 projects for each tutorial on SimpleMembership in GitHub where anyone can download them.

So what did I mean when I stated that the template generated code peppers the application code with database specific information. One example is in the initialization code for InitializeSimpleMembershipAttribute.

private class SimpleMembershipInitializer
{
    public SimpleMembershipInitializer()
    {
        Database.SetInitializer<userscontext>(null);

        try
        {
            using (var context = new UsersContext())
            {
                if (!context.Database.Exists())
                {
                    // Create the SimpleMembership database without Entity Framework migration schema
                    ((IObjectContextAdapter)context).ObjectContext.CreateDatabase();
                }
            }

            WebSecurity.InitializeDatabaseConnection("DefaultConnection", "UserProfile", "UserId", "UserName", autoCreateTables: true);
        }
        catch (Exception ex)
        {
            throw new InvalidOperationException("The ASP.NET Simple Membership database could not be initialized. For more information, please see http://go.microsoft.com/fwlink/?LinkId=256588", ex);
        }
    }
}

As you can see from this code DbContext and other EF classes are called directly to setup initialization of the database. When I write MVC applications I like to use several design patterns to encapsulate the database layer from the application domain. One is the Repository Design Pattern, which encapsulates which ORM we are using. This allows for easily swapping out EF for another ORM, and for using mock-ups during unit testing. And I usually use Unit of Work Design Pattern to handle transactions. With this in mind I created an assembly called SimpleSecurity which encapsulates SimpleMembership using these design patterns. If you look at the SimpleSecurity source code you will see a Repositories folder/namespace that contains a repository for UserProfile and a unit of work class. We will add more repositories in later posts that will add more functionality for SimpleSecurity.

SimpleSecurity is an application layer that encapsulates the methods in WebSecurity as well as access to the UserProfile. So what does our initialization process look like when using SimpleSecurity. We remove the use of InitializeSimpleMembershipAttribute and put it in the Global.asax Application_Start method

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();

    WebApiConfig.Register(GlobalConfiguration.Configuration);
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);
    AuthConfig.RegisterAuth();
    WebSecurity.Register();
}

As you can see from this example you just call WebSecurity.Register. SimpleSecurity uses the same class name of WebSecurity as WebMatrix so you just have to change the uses clauses to SimpleSecurity and remove WebMatrix and most of the code will work the same as in your original app. So here are the steps for using SimpleSecurity.

Include SimpleSecurity in your MVC project
Remove all uses statements for WebMatrix and replace them with SimpleSecurity.
Remove InitializeSimpleMembershipAttribute.cs from your MVC project.
Remove the reference to InitializeSimpleMembershipAttribute in the AccountConroller.
Add WebSecurity.Register() to the Global.asax, as shown above.
Remove UsersContext and UserProfile classes from AccountModels.cs.
Remove all references to UsersContext in the AccountController and replace them with a SimpleSecurity.WebSecurity method.

On the last item you will find code like this in the AccountController

   // Insert a new user into the database
    using (UsersContext db = new UsersContext())
    {
        UserProfile user = db.UserProfiles.FirstOrDefault(u => u.UserName.ToLower() == model.UserName.ToLower());
        // Check if user already exists
        if (user == null)
        {
            // Insert name into the profile table
            db.UserProfiles.Add(new UserProfile { UserName = model.UserName });
            db.SaveChanges();

            OAuthWebSecurity.CreateOrUpdateAccount(provider, providerUserId, model.UserName);
            OAuthWebSecurity.Login(provider, providerUserId, createPersistentCookie: false);

            return RedirectToLocal(returnUrl);
        }
        else
        {
            ModelState.AddModelError("UserName", "User name already exists. Please enter a different user name.");
        }
     }

Which now becomes this.

        try
        {
            WebSecurity.CreateUser(new UserProfile() 
                { UserName = model.UserName });
            OAuthWebSecurity.CreateOrUpdateAccount(provider, providerUserId, model.UserName);
            OAuthWebSecurity.Login(provider, providerUserId, createPersistentCookie: false);
        }
        catch (Exception ex)
        {
            ModelState.AddModelError("UserName", "User name already exists. Please enter a different user name.");
        }

And when we need to get information on the current user it will look like this.

  var user = WebSecurity.GetCurrentUser();
  ViewBag.Email = user.Email;

Now we have a clean layer that decouples our security data from the rest of the MVC application. I will use this as a basis for future enhancements to SimpleMembership going forward. For example, I discussed a bug when deleting users when using WebMatrix.WebSecurity. Now we can implement a new version of DeleteUser in SimpleSecurity.WebSecurity that fixes this issue. Watch this blog for further enhancements to SimpleSecurity.

Trouble Deleting Users in SimpleMembership

2013-03-06T16:08:00.000-05:00

I came across a question in StackOverflow the other day where someone was having trouble deleting a user in the SimpleMembership provider that is now the default provider in ASP.NET MVC 4 Internet Applications. The problem he was having was that when he called SimpleMembershipProvider.DeleteUser it was deleting the data in the UserProfile table and not in the webpages_Membership table. First a little bit on what these two tables are about.

SimpleMembership is designed to put the user information in these two tables, which have a one-to-zero-or-one relationship. The UserProfile table has a unique UserId and a UserName, and UserProfile can be customized by the developer. This UserId is a foreign key for the webpages_Membership table, which contains the password and other security information in it. The reason for keeping information in these table separate is that the data in webpages_Membership is not required if OAuth is being used. If OAuth is being used then the password and other security details will be on another system.

Now back to the problem. I found it hard to believe that using DeleteUser did not remove both tables because here is what the documentation says.

This method deletes the entry in the membership account table (by default, webpages_Membership). If deleteAllRelatedData is true, all user data that is stored in the user table is also deleted.

So here is the quick and dirty test I ran.

var roles = (SimpleRoleProvider)Roles.Provider;
var membership = (SimpleMembershipProvider)Membership.Provider;

if (membership.GetUser("test", false) == null)
{
    membership.CreateUserAndAccount("test", "test");
}

bool wasDeleted = membership.DeleteUser("test", true);

I stepped through with the debugger after the CreateUserAndAccount and saw an entry for the user in both tables. Then I stepped over DeleteUser and checked the database again. The entry in UserProfile was gone but the one in webpages_Membership was still there. This was a far cry from what the documentation described as the behavior for this method and verified what the person asking the question in StackOverflow observed.

So I thought I would try something else to see if I could come up with a workaround for this issue. Here is the code I tried.

var roles = (SimpleRoleProvider)Roles.Provider;
var membership = (SimpleMembershipProvider)Membership.Provider;

if (membership.GetUser("test", false) == null)
{
    membership.CreateUserAndAccount("test", "test");
}

bool wasDeleted = membership.DeleteAccount("test");

wasDeleted = membership.DeleteUser("test", true);

Now when I stepped through with the debugger when I hit DeleteAccount the entry from webpages_Membership was removed and then when I hit DeleteUser the entry in UserProfile was removed. Now we do not have any orphans hanging around. Not sure if and when Microsoft will fix this bug but at least there is a workaround.

I should also point out that if you have a user mapped to roles using DeleteUser will throw a foreign key exception. You have to remove any mapped roles before you can use it.