Month: July 2014

External Auth in ASP.Net MVC/SPA/Web API apps

July 31, 2014 Coding 3 comments ,

Out of the box, Visual Studio 2013 comes with a number of templates for ASP.Net to cover most scenarios. The issue is that if you want registered users, you have a choice between Individual User Accounts, Organizational Accounts or Windows Authentication.

VS 2013 ASP.Net Options

While “Individual User Accounts” sounds like the only option for apps that aren’t using Azure AD or Windows Auth, the trouble is that it brings in all of ASP.Net Identity, which includes a local user database. If you look at the description above, it seems like this is the option to use for external/social logins, but as we’ll discuss shortly, it’s a red herring.

There are a few reasons why it’s not a good idea to mix your user database with your main app:

  • Single Responsibility Principle. This is the “S” in SOLID, and it applies to your application/service as a whole, not just your classes. Your application should be great at what it does. Your services should be granular and each do a single thing. Your app is the best thing since sliced bread. What it doesn’t need, is to manage users.
  • Security is hard. If you look at the template code generated by the ASP.Net wizards for “Individual User Accounts,” you’ll see tons of code in the AccountController class. Go ahead, take a look, I’ll wait. Back yet? That code is now on you to understand and work with as after creation, it’s no longer a library. As you go about adjusting the templates, and views, you need to make sure you don’t accidentally introduce any issues. And you will need to be touching that code as the templates are not complete; they’re a getting-started point.
  • Higher Risk. Even though the password field in ASP.Net Identity is salted and hashed, there’s still a lot of juicy information in your users table that a 1337 [email protected] would love to get their hands on. You don’t want that 3am phone call.

Now that you’re hopefully thoroughly convinced that you do not want to implement your own authentication, you’re wondering what can you do now? The answer is to use an external authentication provider. Facebook is one, Microsoft Account another, and Google yet another. There’s no shortage of external authentication providers these days. If you’re thinking that “Individual User Accounts” with ASP.Net Identity does this for you (it’s in the description and template code!), don’t lose sight of the fact that it’s really creating new identities in your app and simply linking external logins. See Brock Allen’s detailed description on how it all works. It’s the same core issue where your app is now managing identities.

Returning to that initial ASP.Net Authentication options dialog, there’s one option that’s conspicuously absent: External Identity Provider. This is one option that really needs to be present in the dialog—a set of templates that are geared around validating external claims that aren’t part of Azure AD.

For Web API apps validating a Bearer token, this comes down to a single line of code (with Thinktecture’s OWIN component):

app.UseJsonWebToken({issuerId}, {audience}, {appSecret});

With that one line, your Web API can rely on true external security.

To be clear, relying an an external provider does not mean that you need to give up the idea of having “local users,” or multiple social logins like Facebook either. If you don’t want to be tied to a single provider, you can use a service like Auth0 or an configurable identity app like Identity Server. Either of those options provides an appropriate architectural separation of concerns and lets the experts handle the authentication. Your app becomes a Relying Party to the external authentication service, receiving, and validating, a set of claims (such as an email address or unique user id in their system).

The key difference between ASP.Net Identity’s assumptions and templates and using an external provider is who owns the claims. ASP.Net Identity translates external claims into its own identity system and issues its own new set of claims and tokens. My recommendation is that this extra layer is unnecessary and your application should use externally provided claims primarily.

There’s one area that I haven’t covered yet: what if you have your Web API and MVC content (even a SPA) in the same site? You’d like your login mechanism to work for both your web UI and your API. This is an area that has caused much confusion in current incarnations as Web API and MVC each do authentication a bit differently. For web browsers, you need some form of cookie auth while still having bearer tokens available for your API. This is exactly the situation I was in where I fell into the ASP.Net Identity trap. I’ll talk more about what happened and how I solved it next time.

To sum up, if you’re not sure whether to use ASP.Net Identity, this flow chat might help:

Special thanks to Barry Dorrans for reviewing this content prior to release.

Fluent Assertions 3.1 for Xamarin

July 29, 2014 Coding No comments ,

I’m happy to announce that Dennis Doomen and I have coordinated to sim-ship Xamarin support for Fluent Assertions 3.1 along with the main Fluent Assertions release. This release works well with xUnit for Xamarin or Xamarin’s existing nUnit/nUnitLite.

You can find the main release notes here.

To use Fluent Assertions with your Xamarin Unit Test project, just add a NuGet reference to FluentAssertions.Xamarin.

Happy testing!

Getting Started with xUnit for Xamarin

July 10, 2014 Coding 3 comments , , ,

xUnit.net 2.0 supports both Portable Class Library (PCL) and platform specific projects for iOS and Android.
Unit tests for Xamarin have two main components, which may reside in the same assembly. This post will show you how to get started.

Requirements

  • Xamarin Studio 5.0
  • Visual Studio 2013 Update 2 with the latest Xamarin for Visual Studio

Architecture

Xamarin support consists of two logical components, which may be in the same assembly or may be split:
1. Assemblies containing tests. This may be either a Xamarin project or a PCL. This assembly contains your test classes.
2. App for running tests on a device or simulator. This bootstraps the tests. It’s important that you set any permissions, such as internet access, geo locations, notifications, etc, if your app requires it.

The Goods

For simplicity here, we’ll put both pieces in the same project, but you can also put your tests in a separate library and reference it in your runner app. We’ll use Android as an example, but it’s exactly the same for iOS.

  1. Create a new blank Android project:

  2. Add the NuGet references for xUnit and xunit.runner.xamarin. Make sure the Prerelease option is enabled as xUnit 2.0 is still in beta.


  3. After installing the package, you’ll see a file MainActivity.cs.txt (on Android or AppDelegate.cs.txt for iOS). Copy/paste the contents of that file into your real MainActivity.cs file. Congratulations, your runner app is now ready, you just need to add some tests!

  4. Create a new test class and start creating your tests. For more info on xUnit, check out the Getting Started page.

  5. When you’re ready to run your tests, just debug/run your app as you would any other. You can use a device or simulator.

Current status on the Runners

The runners today are functional, but they’re not pretty. The iOS and Android runners do share quite a bit of code, but the UI is duplicated as it was created before Xamarin.Forms was announced. There’s a ton of room for improvement and I welcome any help in the form of a Pull Request. The code is all on GitHub here.