Sometimes you need a Stuntman before you send in real, unsuspecting users!

So what is Stuntman?

Stuntman is a library for impersonating users during development leveraging .NET Claims Identity. Used primarily in web environments like ASP.NET MVC, ASP.NET Web Forms, and OWIN applications that serve HTML. This allows you to test different user scenarios that exist in your application with minimal friction. It also allows you to share those scenarios with other team members via source control.

Install the package:

PM> Install-Package RimDev.Stuntman

Startup / Middleware registration

Stuntman uses OWIN and is registered as middleware, and allows for programmatically preset user scenarios, in the form of claims identities. These presets can be utilized by you or other team members working on the same code base.

// OWIN Startup class
public class Startup
    public static readonly StuntmanOptions StuntmanOptions = new StuntmanOptions();

    public void Configuration(IAppBuilder app)
            .AddUser(new StuntmanUser("user-1", "User 1")
                .AddClaim("given_name", "John")
                .AddClaim("family_name", "Doe"));

        // Optionally assign a user an access token.
            .AddUser(new StuntmanUser("user-2", "User 2")
                .AddClaim("given_name", "Mary")
                .AddClaim("family_name", "Smith"));

        // You can also add users using HTTP/HTTPS or the file system!

        // Optional alignment of user picker
        // Supported options are:
        // - StuntmanAlignment.Left (default)
        // - StuntmanAlignment.Center
        // - StuntmanAlignment.Right

        // Only show when debug is true in Web.config.
        if (System.Web.HttpContext.Current.IsDebuggingEnabled)


Here’s how to use Stuntman in a Razor view to show the user picker (assuming the application Startup class has StuntmanOptions that can be used).

@* Only show when debug is true in Web.config. *@
@if (System.Web.HttpContext.Current.IsDebuggingEnabled)


Stuntman supports bearer-tokens based on a user’s access-token (StuntmanUser.SetAccessToken). There is nothing special about the value and no additional encoding/decoding is necessary. Upon successful authentication, the value is added as a claim. Leveraging the previous Startup code, you could construct an HTTP-request to utilize User 2’s access-token:

> curl -i -H "Authorization: Bearer 123" http://localhost:54917/secure
HTTP/1.1 200 OK

Basic format-checking is done on the value:

> curl -i -H "Authorization: Bearer not-real" http://localhost:54917/secure
 HTTP/1.1 403 options provided does not include the requested 'not-real' user.
> curl -i -H "Authorization: Bearer abc 123" http://localhost:54917/secure
HTTP/1.1 400 Authorization header is not in correct format.

Remote users

Users can be populated from remote locations using one or more of the following:

From the file system


From a web url to a JSON file


From a web url to a Stuntman instance with a running server

// On the server

// On the client
// or, if you prefer to not throw an exception
// and have the users silently not added
// if the server is unavailable:

Example users JSON

Here’s an example users JSON that can be consumed by StuntmanOptions.AddUsersFromJson(string pathOrUrl):

  "Users": [
      "Id": "user-1",
      "Name": "User 1"
      "Id": "user-2",
      "Name": "User 2"