Role vs. Claims


Quando estamos lidando com a autorização dentro de uma aplicação, é muito comum configurarmos o acesso às seções dentro do mesmo de acordo com o papel (role) em que o usuário está contido. Muitas vezes o papel reflete o departamento ou grupo em que o usuário encontra-se cadastrado dentro da empresa, independentemente se esse controle é realizado através da própria aplicação ou através de algum centralizador, como é o caso do Active Directory (AD).

Mas ao trabalhar com autorização baseada em claims (afirmações), você não está restrito a isso. A autorização pode estar baseada em outras informações, que vão muito além de simples strings. Podemos, por exemplo, conceder o acesso somente aqueles usuários que são maiores de 18 anos, e para isso vamos nos basear na data de nascimento dele.

Ao criar uma claim, devemos especificar o seu tipo (String, Integer, DateTime, Double, etc) e o seu respectivo valor. Além disso, temos a espécie da claim, que podem ser valores predefinidos pelo WIF, e que determinará qual é a finalidade dela, como por exemplo: name, email, role, etc. Como podemos reparar, um papel nada mais é que uma claim, que é inserida dentro do token emitido pelo STS.

Para manter a compatibilidade com a estrutura de autorização do .NET, continuamos recorrendo à tradicional interface IPrincipal, ou melhor, à uma de suas derivações, que é a IClaimsPrincipal. Ao interrogar o método IsInRole, que dado um papel (role), retornará um valor boleano indicando se o usuário está ou não contido nele. Quando você utiliza esse método, o WIF procura dentro da coleção de claims emitidas pelo STS, alguma que corresponda ao papel. Por padrão, ele tenta procurar pela claim com o nome de “role”, mas você pode alterar esse comportamento. Se por algum motivo, a claim que representa o papel é uma outra claim com um outro nome, você pode alterar isso através da propriedade RoleClaimType da interface IClaimsIdentity.

Já se você precisar refinar a sua autorização através de alguma outra claim que não seja o papel do usuário, você pode recorrer a coleção de claims, que também é exposta através da propriedade Claims da interface IClaimsIdentity. Por exemplo, se o STS emitir uma claim que corresponde à data de nascimento do usuário, e quisermos somente conceder o acesso se ele for maior que 18 anos, então podemos utilizar o seguinte código:

IClaimsIdentity identity = Thread.CurrentPrincipal.Identity as IClaimsIdentity;

if (identity != null)
{
    string data =
        (
            fromin claimsIdentity.Claims
            where c.ClaimType == ClaimTypes.DateOfBirth
            select c.Value
        ).SingleOrDefault();

    if (!string.IsNullOrWhiteSpace(data))
    {
        const int IDADE_PERMITIDA = 18;
        DateTime dataDeNascimento = DateTime.MinValue;

        if (DateTime.TryParse(data, out dataDeNascimento))
        {
            this.EntrarNoSite.Enabled =
                (DateTime.Now.Subtract(dataDeNascimento).Days / 365) > IDADE_PERMITIDA;
        }
    }
}

Conclusão: O STS pode emitir claims que descrevem o usuário que ele conhece, sendo essas claims informações que a aplicação pode utilizar como quiser para poder identificar ou refinar a autorização daquele usuário, e como disse anteriormente, nem sempre utilizaremos roles para customizar o acesso. Finalmente, podemos concluir que todo papel (role) é uma afirmação (claim), mas nem toda afirmação é um papel.

Publicidade

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s