Customizando perfis do ASP.NET Identity

Por que customizar o ASP.NET Identity

No entanto, ao desenvolver sistemas, muitas vezes você precisa de dados que não existem nas tabelas padrão. Para contornar essa limitação, o ASP.NET Identity permite estender as classes do modelo e, assim, adicionar colunas novas.

Você faz essa personalização com herança e com os parâmetros genéricos do IdentityDbContext. Portanto, você não precisa reescrever o Identity, apenas informar quais classes ele deve usar no lugar das versões padrão.

A mesma técnica vale para outras entidades do ASP.NET Identity. Por exemplo, você pode adicionar o nome completo ao usuário, uma descrição à role ou metadados aos claims.

Neste artigo, o foco fica na relação entre usuário e role, porque é nela que mora a regra de vigência. Mesmo assim, os passos de herança, contexto e migration se repetem para qualquer outra customização do ASP.NET Identity.

Removendo as migrations antigas

Para garantir que todas as mudanças cheguem ao banco, remova as migrations geradas pelo template. Isso é necessário porque o template as gerou para o SQLite, que usa TEXT como tipo da chave primária.

Se você executar os comandos a seguir sem remover as migrations antigas, ou sem ajustá-las para uniqueidentifier, erros podem ocorrer na criação da migration.

dotnet ef migrations add UpdateIdentityUserRole
dotnet ef database update

Esses comandos geram a migration com os novos campos e aplicam a atualização no banco. Ao final, a tabela AspNetUserRoles passa a ter as colunas StartDate e EndDate.

Criação do ApplicationSignInManager

Para isso, crie uma classe chamada ApplicationSignInManager, que herda de SignInManager<ApplicationUser>. Essa abordagem permite sobrescrever o método de login do ASP.NET Identity sem alterar as páginas geradas pelo template.

A classe precisa receber todas as dependências da classe base e repassá-las ao construtor dela. Além disso, injete o contexto do banco e o RoleManager, que participam da validação das datas.

public class ApplicationSignInManager : SignInManager<ApplicationUser>
{
    private readonly ApplicationDbContext _context;
    private readonly RoleManager<IdentityRole<Guid>> _roleManager;

    public ApplicationSignInManager(
        UserManager<ApplicationUser> userManager,
        IHttpContextAccessor contextAccessor,
        IUserClaimsPrincipalFactory<ApplicationUser> claimsFactory,
        IOptions<IdentityOptions> optionsAccessor,
        ILogger<SignInManager<ApplicationUser>> logger,
        IAuthenticationSchemeProvider schemes,
        IUserConfirmation<ApplicationUser> confirmation,
        ApplicationDbContext context,
        RoleManager<IdentityRole<Guid>> roleManager)
        : base(userManager, contextAccessor, claimsFactory, optionsAccessor, logger, schemes, confirmation)
    {
        _context = context;
        _roleManager = roleManager;
    }

    public override async Task<SignInResult> PasswordSignInAsync(
        string userName, string password, bool isPersistent, bool lockoutOnFailure)
    {
        // A implementação do login vem a seguir
    }
}

A classe base já expõe as propriedades UserManager e Context. Por isso, não é preciso guardar uma cópia própria do UserManager em um campo privado.

Validando usuário e senha no ASP.NET Identity

Com as dependências configuradas, o fluxo de login começa pela busca do usuário a partir do nome informado. Em seguida, o código valida a senha.

var user = await UserManager.FindByNameAsync(userName);
if (user is null)
    return SignInResult.Failed;

// Valida a senha respeitando bloqueio e confirmação de conta
var check = await CheckPasswordSignInAsync(user, password, lockoutOnFailure);
if (!check.Succeeded)
    return check;

No exemplo original, o código conferia a senha com UserManager.CheckPasswordAsync. Nesta versão, o método CheckPasswordSignInAsync da própria classe base faz a mesma conferência e também respeita o bloqueio por tentativas e a exigência de conta confirmada.

Consultando as roles válidas no ASP.NET Identity

Se a senha estiver correta, o próximo passo é descobrir quais roles do usuário continuam válidas. Para isso, consulte a tabela ApplicationUserRoles e filtre os registros ativos.

var now = DateTime.UtcNow;

// Roles ativas: começaram até agora e ainda não terminaram
var userRoles = await _context.ApplicationUserRoles
    .Where(ur => ur.UserId == user.Id &&
                 ur.StartDate <= now &&
                 ur.EndDate > now)
    .Select(ur => ur.RoleId)
    .ToListAsync();

Uma role fica ativa quando a StartDate é menor ou igual à data atual e a EndDate é posterior a ela. Guardar a data em uma variável garante que as duas comparações usem exatamente o mesmo instante.

Gerando os claims e autenticando o usuário

Com a lista de roles válidas em mãos, gere os claims essenciais do usuário. Neste caso, são o nome de usuário e o identificador.

var claims = new List<Claim>
{
    new(ClaimTypes.Name, user.UserName!),
    new(ClaimTypes.NameIdentifier, user.Id.ToString()),
    // Mantém o security stamp usado pelo Identity na revalidação do cookie
    new(Options.ClaimsIdentity.SecurityStampClaimType, await UserManager.GetSecurityStampAsync(user))
};

O claim de security stamp não estava no exemplo original. Ele é recomendado porque o Identity compara esse valor periodicamente para invalidar sessões quando a senha ou as permissões mudam.

Caso existam roles válidas, percorra a lista e adicione o claim de role correspondente.

foreach (var roleId in userRoles)
{
    var role = await _roleManager.FindByIdAsync(roleId.ToString());
    if (role is not null)
        claims.Add(new Claim(ClaimTypes.Role, role.Name!));
}

Por fim, os claims formam uma ClaimsIdentity, que por sua vez gera um ClaimsPrincipal. Com esse principal, o método SignInAsync do contexto HTTP autentica o usuário.

var identity = new ClaimsIdentity(claims, IdentityConstants.ApplicationScheme);
var claimsPrincipal = new ClaimsPrincipal(identity);

await Context.SignInAsync(IdentityConstants.ApplicationScheme, claimsPrincipal, new AuthenticationProperties
{
    IsPersistent = isPersistent
});

return SignInResult.Success;

A constante IdentityConstants.ApplicationScheme vale "Identity.Application", o mesmo texto usado no exemplo original. Usar a constante evita erros de digitação no nome do esquema.

Se quiser se aprofundar na criação e na leitura desses valores, o artigo sobre claims customizados no ASP.NET mostra outras formas de trabalhar com eles.

Registrando o SignInManager customizado

Para que a implementação customizada seja usada, registre a classe no container de injeção de dependências. A forma mais direta é trocar a chamada AddSignInManager no registro do ASP.NET Identity.

builder.Services.AddIdentityCore<ApplicationUser>(options =>
        options.SignIn.RequireConfirmedAccount = true)
    .AddRoles<IdentityRole<Guid>>()
    .AddEntityFrameworkStores<ApplicationDbContext>()
    .AddSignInManager<ApplicationSignInManager>() // versão customizada
    .AddDefaultTokenProviders();

O original registrava o serviço com AddScoped<SignInManager<IdentityUser<Guid>>, ApplicationSignInManager>(). Contudo, o tipo correto do serviço é SignInManager<ApplicationUser>, pois é ele que as páginas do template injetam.

Com isso, a aplicação passa a resolver o ApplicationSignInManager sempre que alguém pedir um SignInManager<ApplicationUser>. Dessa forma, o fluxo de autenticação considera os campos StartDate e EndDate das roles.

Atribuindo uma role com período no ASP.NET Identity

O método UserManager.AddToRoleAsync não conhece os novos campos. Por isso, para gravar uma role com período, crie a entidade ApplicationUserRole diretamente pelo contexto.

var role = await roleManager.FindByNameAsync("premium");

// Concede a role por 30 dias a partir de agora
context.ApplicationUserRoles.Add(new ApplicationUserRole
{
    UserId = user.Id,
    RoleId = role!.Id,
    StartDate = DateTime.UtcNow,
    EndDate = DateTime.UtcNow.AddDays(30)
});

await context.SaveChangesAsync();

Lembre que a chave da tabela é composta por UserId e RoleId. Então, para renovar um período, atualize o registro existente em vez de inserir um novo, ou o banco vai rejeitar a chave duplicada.

Esse mesmo código pode virar um serviço da aplicação, chamado após a confirmação de um pagamento ou a matrícula em um curso. Dessa forma, a regra de vigência fica concentrada em um único lugar.

Validando o comportamento na interface

Devido ao tamanho do código, o exemplo completo dos testes está no GitHub, com o link ao final do artigo. A seguir, está o resumo do que ele valida.

Agora que as roles possuem os campos StartDate e EndDate, é importante verificar o comportamento na prática. Para isso, a página de teste permite alterar a role do usuário autenticado e conferir se a lógica de datas funciona.

A interface tem dois botões. O primeiro atribui uma role válida ao usuário, enquanto o segundo atribui uma role com período vencido.

Depois de cada alteração, faça logout e login novamente. Assim, você confirma que apenas a role dentro do período aparece nos claims do usuário autenticado.

Limitações da validação no login

A validação acontece apenas no momento do login. Portanto, se uma role expirar enquanto o usuário estiver autenticado, ela continua no cookie até a próxima autenticação.

Se o seu cenário exige corte imediato, combine essa abordagem com uma revalidação periódica. Uma opção é atualizar o security stamp do usuário quando a role vencer, o que força o Identity a invalidar a sessão.

Repositório do projeto

Por se tratar de um exemplo extenso, o artigo omite algumas partes do código para facilitar a leitura. O repositório completo está disponível no GitHub e é acessível a todos.

• Repositório completo: Customizando perfis do ASP.NET Identity
• Página de teste da implementação