ASP.NET MVC 2 e autenticação usando WIF (Windows Identity Foundation)

Question

Existem exemplos decentes do seguinte disponível:

Olhando através o wif sdk, existem exemplos de uso do WIF em conjunto com asp.net usando o WSFederationAuthenticationModule (FAM) para redirecionar para um site ASP.NET pele fina Além de um serviço de token de segurança (STS) que o usuário usa para autenticar (através do fornecimento de um nome de usuário e senha).

Se eu entender o acesso WIF e baseado em reivindicações corretamente, gostaria que meu aplicativo forneça sua própria tela de login, onde os usuários fornecem seu nome de usuário e senha e deixam isso delegado a um STS para autenticação, enviando os detalhes de login para um endpoint por meio de um padrão de segurança (WS-*), e esperando que um token SAML seja devolvido. Idealmente, o SessionAuthenticationModule funcionaria de acordo com os exemplos usando FAM em conjunção com SessionAuthenticationModule ou seja, seja responsável por reconstruir o IClaimsPrincipal A partir da sessão, o cookie de segurança e redirecionou para a minha página de login de aplicativos quando a sessão de segurança expirar.

É o que eu descrevo possível usar FAM e SessionAuthenticationModule com as configurações de web.config apropriadas, ou preciso pensar em escrever um HttpModule eu mesmo para lidar com isso? Como alternativa, está redirecionando para um site fino do STS, onde os usuários fazem login na abordagem de fato em um cenário de solicitante passivo?

Answer 1

Um exemplo de WIF + MVC está disponível neste capítulo do "Guia de identidade de reivindicações":

http://msdn.microsoft.com/en-us/library/ff359105.aspx

Eu sugiro ler os primeiros capítulos para entender todos os princípios subjacentes. Esta postagem do blog cobre os detalhes do MVC + WIF:

http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-and-mvc-how-it-works.aspx

Controlar a experiência de login é perfeitamente bom. Você deve apenas implantar seu próprio STS (em seu domínio, com sua aparência, etc.). Seus aplicativos simplesmente confiam nele para o Authn (é por isso que um aplicativo geralmente é chamado de "festa de confiar").

A vantagem da arquitetura é que o Authn é delegado a 1 componente (o STS) e não se espalha por muitos aplicativos. Mas a outra (enorme) vantagem é que você pode permitir cenários mais sofisticados com muita facilidade. Por exemplo, agora você pode federar com os provedores de identidade de outra organização.

Espero que ajude Eugenio

@RisingStar:

O token (contendo as reivindicações) pode ser opcionalmente criptografado (caso contrário, eles estarão em texto claro). É por isso que o SSL é sempre recomendado para interações entre o navegador e o STS.

Observe que, embora estejam em texto claro, a adulteração não é possível porque o token é assinado digitalmente.

Answer 2

Essa é uma pergunta interessante que você fez. Sei que, por qualquer motivo, a Microsoft lançou essa estrutura "Windows Identity Foundation" sem muita documentação. Sei disso porque fui encarregado de descobrir como usá -lo com um novo projeto e integrá -lo à infraestrutura existente. Estou pesquisando na web há meses procurando boas informações.

Eu tomei um ângulo um pouco diferente para resolver o problema que você descreve.

Peguei um aplicativo de log-on existente e integrou o WIF da Microsoft encanando nele. Com isso, quero dizer que tenho um aplicativo em que um usuário efetua login. O aplicativo de log-o envia as credenciais fornecidas pelo usuário a outro servidor que retorna a identidade dos usuários (ou indica falha de log-on).

Olhando para alguns dos exemplos da Microsoft, vejo que eles fazem o seguinte: Construa um SignInRequestMessage A partir de uma consulta (gerada por um aplicativo de conta de confiar), construa um serviço de token de segurança a partir de uma classe personalizada e, finalmente, ligue para federatedSecurityTokenserviceOperations.processSigninResponse com o atual httpcontext.Response. Infelizmente, não posso realmente explicar bem aqui; Você realmente precisa olhar para as amostras de código.

Alguns do meu código são muito semelhantes ao exemplo de código. Onde você estará interessado em implementar grande parte de sua própria lógica está no GetOutputClaimsIdentity. Essa é a função que constrói a identidade de reivindicações que descreve o usuário logado.

Agora, aqui está o que eu acho que você está realmente interessado em saber. É isso que a Microsoft não diz na documentação deles, Afaik.

Depois que o usuário faz login, eles são redirecionados de volta para o aplicativo da parte que confia. Independentemente de como o aplicativo de log-on funciona, as classes WIF enviarão uma resposta ao navegador do usuário que contém uma entrada HTML "oculta" que contém o certificado de assinatura do token e as reivindicações do usuário. (As reivindicações estarão em texto claro). No final desta resposta, é um redirecionamento para o seu site de conflito. Eu só conheço essa ação porque a capturei com "violinista"

Uma vez de volta ao site da festa de confiar, as classes WIF lidarão com a resposta (antes que qualquer código seja executado). O certificado será validado. Por padrão, se você configurou seu site de confiando em Fedutil.exe (clicando em "Adicionar referência do STS no seu aplicativo de parte do Visual Studio), a classe da Microsoft verificará o certificado Thumbprint.

Finalmente, o WIF Framework define cookies no navegador do usuário (na minha experiência, os nomes de cookies começam com "Fedauth") que contêm as reivindicações dos usuários. Os cookies não são legíveis em humanos.

Quando isso acontece, você pode opcionalmente executar operações nas reivindicações do usuário no site da parte que se contorcendo usando o ClaimsAuthenticationClass. É aqui que seu código está funcionando novamente.

Eu sei que isso é diferente do que você descreve, mas tenho essa configuração funcionando. Eu espero que isso ajude!

ps. Confira as outras perguntas que fiz sobre o Windows Identity Foundation.

ATUALIZAÇÃO: Para responder à pergunta no comentário abaixo:

Uma coisa que deixei de fora é que o redirecionamento para o aplicativo de log-on do STS acontece por meio de um redirecionamento com uma corda de consulta contendo o URL do aplicativo para o qual o usuário está efetuando login. Esse redirecionamento acontece automaticamente na primeira vez que um usuário tenta acessar uma página que requer autenticação. Como alternativa, acredito que você poderia fazer o redirecionamento manualmente com o WSFederationAuthentication módulo.

Eu nunca tentei fazer isso, mas se você quiser usar uma página de log-on no próprio aplicativo, acredito que a estrutura deve permitir que você use o seguinte:

1) encapsular seu código STS em uma biblioteca. 2) Faça referência à biblioteca do seu aplicativo. 3) Crie uma página de log-on em seu aplicativo. Verifique se essa página não requer autenticação. 4) Defina a propriedade do emissor do wsFederation elemento dentro do Microsoft.IdentityModel Seção do seu web.config para a página de login.

Answer 3

O que você quer fazer é uma assinatura ativa. WIF inclui WStrustChannel (fábrica) que permite que você se comunique diretamente com o STS e obtenha um token de segurança. Se você deseja que seu formulário de login funcione dessa maneira, você pode seguir a amostra "WStrustChannel" do WIF 4.0 SDK. Depois de obter o token, o código a seguir pegará esse token e ligará para o manipulador de wif para criar um token de sessão e definir o cookie apropriado:

public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
    var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;            
    var token = handlers.ReadToken(new XmlTextReader(
                                        new StringReader(genericToken.TokenXml.OuterXml)));

    var identity = handlers.ValidateToken(token).First();
    // create session token
    var sessionToken = new SessionSecurityToken(
        ClaimsPrincipal.CreateFromIdentity(identity));
    FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}

Depois de fazer isso, seu site deve se comportar da mesma forma que se houvesse assinatura passiva.

Answer 4

Você pode usar o controle federatedpassignin.

Answer 5

Definir seu cookie como este: federatedauthentication.sessionAthenticationModule.WriteSessionTokentocookie (SessionToken); Não funciona para a SSO para outros domínios.

O cookie deve ser definido pelo STS não no RP.