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.

por Israel Aéce

Quando estamos lidando com a autorização dentro de uma aplicação, é muito comum configurarmos o acesso às seções dentro domesmo 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 comautorizaçã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.Identityas IClaimsIdentity;

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

if (!string.IsNullOrWhiteSpace(data))
{
const intIDADE_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.