asp.net mvc autenticação contra shibboleth e autorização

Question

Onde posso obter informações sobre o usuário conectado no momento? Ou seja, como é que shibboleth passar a informação?

Posso definir algumas restrições sobre ações usando [autorizar] atributo com base em dados adquiridos da shibboleth?

Answer 1

Shibboleth publica atributos do usuário associados sessões em cabeçalhos de solicitação HTTP, com base em nomes de cabeçalho definido Em Atributo Política de Aceitação (1.3.x) ou Mapeamento de Atributos (2.x) arquivos. Estes cabeçalhos são transformados em variáveis ??CGI baseados no mapeamento regras definidas pela especificação CGI.

Você deve estar ciente deste aviso de segurança: http://shibboleth.net/community/advisories/secadv_20090615.txt

Answer 2

Eu nunca shibboleth usuário, mas você pode obter informações sobre o usuário de Controller.User propriedade. Ele irá retornar um principal genérica do segmento atual. Usando este princípio é possível verificar se o usuário é autenticado e obter um nome de login do usuário. Isto é devido à razão que, depois de logon um cookie de autenticação é definido e este cookie contém quantidade limitada de informações. E em cada pedido após início de sessão única este cookie é verificado (se ele existe e válida - usuário é autenticado).
Então, se você precisar de alguma informação específica que você pode carregar manualmente um usuário (que é melhor para o cache uso aqui) e verificar o que quiser.
Além disso, você pode criar e anexar o seu próprio capital, com informações necessárias para o segmento no início de um pedido (por exemplo, no início de uma carga de solicitação o usuário de db / cache usando o nome de usuário do principal base, criar e definir o seu próprio diretor de rosca) . Após isso, você pode verificar todas as propriedades do usuário que você precisa.

Answer 3

Onde você anexar o seu próprio diretor? Você diz no início do pedido, mas o que se você não quer que cada ordenador pedido?

Answer 4

Você vai querer criar um método em Global.asax.cs que tem a seguinte assinatura

protected void Application_PostAuthenticateRequest()
{
    //Your code here.
}

Este será chamado automaticamente antes de quase qualquer outra coisa é feito (MVC irá chamar esse método, se existir, você não tem que "ligar" em qualquer lugar), e é aí que você precisa para definir o Principal. Por exemplo, vamos supor que você tem um cabeçalho chamado RolesHeader que tem um valor separado por vírgula de papéis e outro cabeçalho chamado UserId que tem (duh) o ID do usuário.

O seu código, sem qualquer manipulação de erro, poderia ser algo como:

protected void Application_PostAuthenticateRequest()
{
    var rolesheader = Context.Request.Headers["RolesHeader"];
    var userId = Context.Request.Headers["UserId"];
    var roles = rolesheader.Split(',');
    var principal = new GenericPrincipal(new GenericIdentity(userId), roles);
    Context.User = principal;
}

É o director / identidade que usa o atributo [Authorize], assim defini-lo aqui no início do ciclo de vida do pedido significa o atributo [Authorize] irá funcionar corretamente.

O restante deste é opcional, mas eu recomendo-lo:

Eu gosto de criar minhas próprias classes personalizadas que implementam IPrincipal e IIdentity vez de usar o GenericPrincipal e GenericIdentity, para que eu possa encher mais informações de usuário nele. Meu costume Principal e Identity objetos, em seguida, ter informações muito mais rica, como números de filiais ou endereços de e-mail ou qualquer outra coisa.

Então, eu crio um controlador chamado BaseController que tem a seguinte

protected new CustomPrincipal User
{
    get
    {
        return (base.User as CustomPrincipal) ?? CustomPrincipal.GetUnauthorizedPrincipal();
    }
}

Isso me permite acessar todos os meus dados rico, costume principal em vez de apenas o que está definido na IPrincipal. Todos os meus controladores de reais, em seguida, herdam BaseController em vez de diretamente do Controller.

Obviamente, quando se utiliza um costume principal como esta, no método Application_PostAuthenticateRequest (), você deve definir o Context.User para ser seu CustomPrincipal em vez de um GenericPrincipal.