Autoryzacja w MVC 5 - ASP.NET Identity

Kiedyś pisałem o MVC 2 później 3, 4 a teraz przyszedł czas na nowości dotyczące 5 wersji frameworka. Wraz z MVC wypuszczono także nową bibliotekę pozwalającą autoryzować użytkowników - Microsoft Identity. Ma ona za zadanie zastąpić przestarzały MembershipProvider i nie końca udany SimpleMembership.
Co tym razem przygotował Microsoft? Możliwości ASP.NET Identity:

• łatwe dodawanie dodatkowych informacji do profilu użytkownika
• domyślnie użycie Entity Framework jako ORM
• kontrola zapisu (możliwość wyboru czy dane mają zostać zapisane w SQL Azure, MS SQL, NOSQL itp)
• wsparcie dla TDD dzięki dużo lepszej architekturze frameworka
• wsparcie dla ról w aplikacji
• system nadawania praw do poszczególnych aspektów aplikacji
• zewnętrzna autoryzacja (Facebook, Twitter itp)

Jak widać całkiem sporo możliwości. Szczególnie ostania opcja jest przydatna w obecnych czasach. Dodatkowo po stworzeniu projektu wszystko co jest potrzebne jest już dla nas stworzone i jedyne co musimy zrobić aby korzystać z np. Twittera jako sposobu autoryzacji to podanie danych do konta naszej aplikacji.
Schemat bazy ASP.NET Identity przedstawia się następująco:

Dużo przyjemniejszy niż w przypadku starego MembershipProvidera. Dodawanie nowych kolumn i informacji o użytkowniku też nie sprawia problemów:
Wystarczy zlokalizować klasę IdentityUser i dodać w niej nowe pole:

Code:

using System;
using Microsoft.AspNet.Identity.EntityFramework;

namespace AuthorizationSample.Models
{
    // You can add profile data for the user by adding more properties to your ApplicationUser class, please visit http://go.microsoft.com/fwlink/?LinkID=317594 to learn more.
    public class ApplicationUser : IdentityUser
    {
        public DateTime? BirthDate { get; set; }
        public string City { get; set; }
    }

    public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
    {
        public ApplicationDbContext()
            : base("DefaultConnection")
        {
        }
    }
}

Jeżeli korzystamy z mechanizmu automatycznych migracji, wystarczy że utworzymy migrację i uaktualnimy bazę danych.

Projekt domyślnie tworzy szablonowe widoki tworzenia i modyfikowania danych użytkownika. Dostajemy gotowe klasy modeli. Jedynie co brakuje to metod odpowiedzialnych za widoki. Jeżeli chcemy użyć innej klasy (np. już istniejącej w systemie) do przechowywania informacji o użytkowniku, wystarczy że zaimplementujemy interfejs IUser:

Code:

  public interface IUser
  {
    /// <summary>
    /// Unique key for the user
    /// </summary>
    /// 
    /// <returns>
    /// The unique key for the user
    /// </returns>
    string Id { get; }

    string UserName { get; set; }
  }

Jak widać Id użytkownika przetrzymywane jest tutaj jako pole typu string - i takiego też typu jest domyślnie tworzone w bazie danych. Czy to dobre rozwiązanie? Moim zdaniem nie do końca. Dużo lepszym rozwiązaniem byłoby pozwolenie deweloperowi wybrania czy Id ma być łańcuchem, Guidem czy też liczbą. W nowej wersji frameworka (beta) poprawiono tę niedogodność.