Compartilhar via

  • Artigo

Este artigo foi traduzido por máquina.

O AD FS 2.0 nas soluções de identidade

Usando os Serviços de Federação do Active Directory 2.0 nas soluções de identidade

Zulfiqar Ahmed

Baixar o código de exemplo

Como desenvolvedor, você provavelmente sabe algo sobre WIF (Foundation de identidade do Windows), anteriormente chamado “ Geneva Framework ”, que fornece uma API eficiente para habilitar declarações seus aplicativos e para criar serviços de token de segurança personalizado. Talvez menos familiar para você é o Active Directory Federation Services versão 2.0 (AD FS 2.0), código originalmente “ Geneva servidor nomeado, ” que é um solução única-sign-on (SSO) e federação prontos para empresas. AD FS 2.0 é uma evolução do AD FS 1.0 e oferece suporte (WS-Trust) ativo e passivos cenários (WS-Federation e SAML 2.0).

Neste artigo, eu iniciar com uma visão geral do AD FS 2.0 e fornecer esclarecimento sobre como os desenvolvedores podem usar AD FS 2.0 em suas soluções de identidade. O foco é a funcionalidade de emissão de token do AD FS 2.0, com base na versão Beta 2. Como você pode ver de do Figura 1, a emissão de token é apenas uma pequena parte do AD FS 2.0, mas é um interesse específico para os desenvolvedores .NET mover em direção a identidade federada. Arquitetura, AD FS 2.0 é criado na parte superior de WIF Windows Communication Foundation (WCF), portanto, se você estiver familiarizado com essas tecnologias, você deve se sentir à direita em casa com AD FS 2.0.


Figura 1 do arquitetura do AD FS 2.0

Visão geral do AD FS 2.0

Em um alto nível AD FS 2.0 é uma coleção de serviços mostrados no do Figura 2.

No núcleo do AD FS 2.0 é um serviço de token de segurança (STS) que usa o Active Directory como seu armazenamento de identidade e do protocolo (LDAP), SQL ou um armazenamento personalizado como um armazenamento de atributo. O STS no AD FS 2.0 pode emitir tokens de segurança para o chamador usando vários protocolos, incluindo WS-Trust, WS-Federation e SAML (Security Assertion Markup Language) 2.0. STS AD FS 2.0 também oferece suporte a formatos de token SAML 1.1 e SAML 2.0.

AD FS 2.0 foi criado com uma separação clara entre protocolos de cabos e o mecanismo interno de emissão de token. Fios diferentes protocolos são transformados em um modelo de objeto padronizada na entrada do sistema enquanto internamente AD FS 2.0 usa o mesmo modelo de objeto para cada protocolo. Essa separação permite AD FS 2.0 oferecer um modelo de extensibilidade limpa, independente da pormenores de fios diferentes protocolos. Mais detalhes do AD FS 2.0 extensibilidade será fornecida no SDK AD FS 2.0 anteriores ao RTM.


Figura 2 do componentes de AD FS 2.0

AD FS 2.0 como um provedor de identidade

Você pode usar AD FS 2.0 em vários cenários comuns. O cenário mais simples e mais comum é usar AD FS 2.0 como um provedor de identidade para que possa emitir tokens SAML para identidades que ele gerencia. Para que, uma nova parte confiante precisa ser criado. Uma parte confiante no AD FS 2.0 é uma representação de um aplicativo (um site ou um serviço Web) e contém todas as informações relacionadas à segurança informações, como o certificado de criptografia, alega regras de transformação e assim por diante.

Configuração de uma parte confiante

Configurar uma nova parte confiante via AD FS 2.0 é fácil. Você pode acessar o Assistente para adicionar festa dependente através do nó de diretiva AD FS 2.0 Management console. Uma vez lá, você ou seu administrador de sistema precisa especificar as fontes de dados apropriado na página Select Data Source do assistente, que é mostrado no do Figura 3.


Figura 3 Assistente Part confiantes plano Select Data Source Page de

As duas primeiras opções permitem configurar automaticamente a parte confiante usando metadados de federação. Se você tiver acesso aos metadados de federação do confiante em uma rede ou em um arquivo local, selecione uma destas duas opções porque eles são menos propensos a erros, eles automatizar todo o processo e eles atualização automática se alterar quaisquer detalhes a parte confiante no futuro. Essas opções são um aprimoramento principal sobre o AD FS 1.0, que não oferece tais processos automatizados.

A terceira opção requer que você insira manualmente todos os detalhes de configuração. Use esta opção somente quando você não tem acesso aos metadados de federação ou você deseja controlar detalhes da configuração de terceiros confiantes.

É instrutivo executado através da opção “ ENTER confiantes festa configuração manualmente ” apenas para que você possa ver todas as etapas necessárias para configurar uma nova parte confiante. Nas próximas páginas do assistente, você será solicitado a escolher um perfil — escolha AD FS 2.0 perfil se desejar oferecer suporte a clientes baseados em navegador tanto baseadas no WCF ou AD FS 1.x perfil se você apenas precisa AD FS 1.x interoperabilidade e não oferecem suporte a clientes do ativo (WCF, CardSpace); configurar o certificado usado para criptografar o token de modo que somente a parte confiante com a chave particular correspondente poderá descriptografar e usar o token emitido; e configurar o identificador que será usado para identificar esta parte confiante em todas as solicitações de emissão de token.

Depois de concluir o Assistente para adicionar festa dependente, abre uma ferramenta Editor de regras. Essa ferramenta, você pode configurar regras de emissão e transformação de declarações. Figura 4 mostra a ferramenta Editor de regras configurada para emitir um token com uma única declaração cujo valor será recuperada do armazenamento do atributo principal. Observe que o atributo displayName é mapeado para a declaração de nome fornecido. AD FS 2.0 introduz um novo idioma específicas de domínio textual que permite que você defina regras simples para derivar o processo de emissão e transformação de declarações. Cada regra consiste em uma condição e uma ação e extremidades — como em [c] = > um; — com um ponto-e-vírgula. A lógica de transformação é uma série de regras que são executados seqüencialmente durante o processo de emissão de token. Do Figura 4, na guia Exibir simples fornece uma interface de usuário para definir essas regras. Na guia Exibir avançada permite autor regras diretamente usando linguagem específica do domínio.


Figura 4 do Ferramenta Editor de regras

Este exemplo ilustrou como é fácil configurar uma terceira parte confiável confiável no AD FS 2.0. Neste ponto, quando AD FS 2.0 recebe uma solicitação de emissão de token, ele extrai um identificador de protocolo físico (por exemplo, o elemento appliesTo em caso de WS-Trust) e usa para pesquisar uma confiante de destino. Depois que uma parte confiante é encontrada, as configurações especificadas no assistente são usadas para derivar a lógica de emissão de token.

Agora examine como você pode usar o WCF para solicitar um token para essa parte confiante de AD FS 2.0 let’s.

Solicitando um token usando WCF

Há duas opções para interação com AD FS 2.0 STS usando WCF:

  • Adquirir explicitamente um token que atua como um cliente do WS-Trust
  • Configurar um cliente WCF para que a infra-estrutura adquire um token implicitamente como parte da chamada

Opção explicit, a classe WSTrustClient fornece uma API simples e direta para tokens de solicitação de um STS usando o protocolo WS-Trust, como mostrado aqui.

string baseUri = "https://bccoss.com/"; 
 
WindowsWSTrustBinding binding = new WindowsWSTrustBinding(SecurityMode.Transport); 
 
WSTrustClient tokenClient = new WSTrustClient(binding, 
    new EndpointAddress(baseUri + "Trust/2005/WindowsTransport/"), 
    TrustVersion.WSTrustFeb2005, 
    new ClientCredentials()); 
 
//create a token issuance issuance 
RequestSecurityToken rst = 
    new RequestSecurityToken(WSTrustFeb2005Constants.RequestTypes.Issue); 
//Relying Party’s identifier 
rst.AppliesTo = new EndpointAddress("http://local.zamd.net/"); 
//call ADFS STS 
SecurityToken token = tokenClient.Issue(rst);

Esse código solicita um token usando a autenticação do Windows com segurança de transporte. Como você pode ver, no modo explícito, obtenha acesso ao token bruto, você pode usar para chamar serviços posteriormente. Por exemplo, em um aplicativo cliente inteligente, você pode adquirir tokens para diferentes serviços em tempo de inicialização ou logon de aplicativo, salvar em um cache de token e usá-las por todo o tempo de vida do aplicativo para chamar serviços back-end diferentes. Também, em um cenário onde muitos serviços moram no mesmo limite de segurança lógica, compartilhando o mesmo certificado, você pode usar o modo explícito para adquirir um único token e usá-lo ao chamar esses serviços.

 Em um ambiente de teste no qual você normalmente têm acesso à chave particular do confiante, você pode usar o seguinte código para extrair uma declaração SAML token retornado.

//Private Key certificate of RP (local.zamd.net) 
X509Certificate2 rpCertificate = new X509Certificate2("zamd.net.pfx", "pwd"); 
string assertion = Util.ExtractSAMLAssertion(token, rpCertificate); 
 
<saml:Attribute AttributeName="givenname" AttributeNamespace="https://schemas.xmlsoap.org/ws/2005/05/identity/claims"> 
    <saml:AttributeValue>Zulfiqar Ahmed</saml:AttributeValue> 
</saml:Attribute>

O token SAML contém declarações configuradas para esse determinado confiante. Consulte volta Figura 4 , que mostra como token de saída desse confiante foi configurado para retornar um único atributo. Você pode editar a configuração do confiante para incluir declarações mais na saída, e você deve ver todos eles refletidas aqui. Você também pode usar declarações diretiva idioma diretamente para definir a transformação rich e lógica de filtragem.

A API WSTrustClient e novas ligações WSTrust são parte de WIF, portanto, para o código anterior trabalhar, WIF devem ser instalados no cliente. Você também pode usar a API do WCF diretamente para adquirir explicitamente um token, mas a simplicidade e facilidade de uso WIF ofertas pode levar a uma tarefa logoff sua lista de tarefas.

O código do Figura 5, IssuedSecurityTokenProvider é o equivalente do WCF de WSTrustClient e normalmente é usado pelo wsFederationBinding ao solicitar tokens em seu nome. Porque é uma API pública, você está livre para usá-lo em seu código deve precisam acessar um token bruto. A CustomBinding é equivalente a WindowsWSTrustBinding.

Figura 5 usando IssuedSecurityTokenProvider para acessar um token RAW

sstring baseUri = "https://bccoss.com/"; 
 
//Limited edition of WSTrustClient:) 
IssuedSecurityTokenProvider provider = new IssuedSecurityTokenProvider(); 
provider.SecurityTokenSerializer = new WSSecurityTokenSerializer(); 
 
//Relying Party's identifier 
provider.TargetAddress = new EndpointAddress(new Uri("http://local.zamd.net")); 
provider.IssuerAddress = new EndpointAddress(new Uri(baseUri + "Trust/2005/WindowsTransport/")); 
 
provider.SecurityAlgorithmSuite = SecurityAlgorithmSuite.Basic256; 
provider.MessageSecurityVersion = MessageSecurityVersion. 
WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10; 
 
HttpsTransportBindingElement tbe = new HttpsTransportBindingElement(); 
tbe.AuthenticationScheme = AuthenticationSchemes.Negotiate; 
CustomBinding stsBinding = new CustomBinding(tbe); 
 
provider.IssuerBinding = stsBinding; 
provider.Open(); 
//Request a token from ADFS STS 
SecurityToken issuedToken = provider.GetToken(TimeSpan.FromSeconds(30));

A opção implícita, você pode usar wsFederationHttpBinding padrão, em cujo caso a infra-estrutura do WCF transparentemente adquire o token e envia para o serviço como parte da chamada. Sempre que você criar um novo proxy do WCF e usá-lo para chamar um serviço, a infra-estrutura busca um novo token para você. Obviamente, isso seria um exagero em alguns cenários. O código do Figura 6 configura um EmployeeService fictício para exigir tokens de AD FS 2.0.

Figura 6 do Using wsFederationHttpBindingto adquirir um token implicitamente

<system.serviceModel>
  <services>
    <service name="EmployeeService.EmployeeService">
      <endpoint address="http://localhost:9990/ES"
        binding="ws2007FederationHttpBinding"
        contract="EmployeeServiceContract.IEmployeeService"
        bindingConfiguration="adfsFed"/>
    </service>
  </services>
  <bindings>
    <ws2007FederationHttpBinding>
      <binding name="adfsFed">
        <security mode="Message">
          <message negotiateServiceCredential="false" >
            <issuer address="https://bccoss.com/Trust13/KerberosMixed"
               binding="customBinding" bindingConfiguration="MixedKerberos"/>
          </message>
        </security>
      </binding>
     </ws2007FederationHttpBinding>
     <customBinding>
       <binding name="MixedKerberos">
         <security authenticationMode="KerberosOverTransport"/>
         <httpsTransport/>
       </binding>
     </customBinding>
   </bindings>
</system.serviceModel>
Mapeamento AD FS 2.0 conceitos para WCF

A responsabilidade de núcleo do AD FS 2.0 é emitir tokens para usuários autenticados. Os usuários podem ser autenticados usando mecanismos de autenticação diferente (como autenticação do Windows). Você pode ver todos os mecanismos de autenticação com suporte, selecionando o nó Endpoints no console de gerenciamento.

Você observará dois conceitos de segurança familiares do WCF como títulos de coluna dentro do nó do Endpoints:

  • Tipo de autenticação é a AD FS 2.0 equivalente da terminologia de clientCredentialType WCF.
  • Opções de modo de segurança são mensagens de transporte ou misto. Misto é a AD FS 2.0 equivalente de TransportWithMessageCredentials do WCF.

Combinações diferentes desses dois valores são expostas usando diferentes pontos de extremidade e escolha um ponto de extremidade específico com base em suas necessidades de autenticação. Por exemplo, se você precisar autenticar usando nome_de_usuário/senha, você escolheria o ponto de extremidade de autenticação Limpar senha.

Para AD FS 2.0 STS, esses conceitos de mapeamento de volta para Address, Binding e Contract (ABC) no WCF, obter equivalentes a seguintes:

  • Endereço = AD FS 2.0 endereço base + caminho de URL do ponto de extremidade
  • Ligação = modo de segurança do Endpoint + tipo de autenticação
  • Contrato = protocolo WS-Trust padrão

Federar AD FS 2.0 com outro STS

Além disso, para criar partes confiantes, você pode estabelecer uma relação de confiança entre AD FS 2.0 e o seu STS personalizado ou outro AD FS 2.0. Por exemplo, se você já tiver um STS que autentica usuários e emite tokens, simplesmente você pode adicioná-lo como um provedor de identidade confiável dentro AD FS 2.0, que aceitará tokens emitidos do STS.

Configuração de um provedor de identidade

Configurando um provedor de identidade confiável, novo no AD FS 2.0 é semelhante ao configurar uma nova parte confiante. O Assistente Adicionar provedor de identidade que você use parece e age muito como Assistente para adicionar festa dependente (consulte volta do Figura 3).

Para obter a identificador de Configurar página, selecione a opção de configuração manual novamente (como fiz no do Figura 3) e selecione AD FS 2.0 perfil na página Escolher perfil. Deixe as configurações padrão na página Configurar URL. Em seguida, escolha um identificador e um certificado de chave pública para seu provedor de identidade e concluir o Assistente para registrar o novo provedor de identidade.

Solicitando um token usando WCF

Depois de registrar um provedor de identidade adicional com AD FS 2.0, arquitetura lógica se parece com a configuração mostrada na do Figura 7.


Figura 7 do arquitetura do AD FS 2.0 com um provedor de identidade adicionais

O código em do Figura 8 permite que você adquirir um token explicitamente, dando a flexibilidade para o token localmente em cache e enviar ao serviço conforme necessário.

Figura 8 usando IssuedTokenWSTrustBinding adquirir um token explicitamente

string adfsStsUri = "http://bccoss.com/Trust/2005/IssuedTokenAsymmetricBasic256";

//binding for local STS(IP-STS)
WSHttpBinding localStsBinding = new WSHttpBinding(SecurityMode.Message);

localStsBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
localStsBinding.Security.Message.EstablishSecurityContext = false;
localStsBinding.Security.Message.NegotiateServiceCredential = false;

EndpointAddress localStsEpr = new EndpointAddress(
   new Uri("http://localhost:9000/STS/"),
   new X509CertificateEndpointIdentity(new X509Certificate2(@"MyCustomSTSPublicKey.cer")));

//This binding will transparently acquire all the intermediate tokens as part of the call. (R-STS)
IssuedTokenWSTrustBinding fedBinding = new IssuedTokenWSTrustBinding(localStsBinding, localStsEpr);
fedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;

EndpointAddress adfsStsEpr = new EndpointAddress(
    new Uri(adfsStsUri),
    new X509CertificateEndpointIdentity(new X509Certificate2("AdfsStsPubicKeyOnly.cer")));

WSTrustClient trustClient = new WSTrustClient(fedBinding, adfsStsEpr, TrustVersion.WSTrustFeb2005,
null);

//Create a security token request
RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue);
//Set Relying Party's identifier accordingly
rst.AppliesTo = new EndpointAddress("http://local.zamd.net");

SecurityToken finalToken = trustClient.Issue(rst);

IssuedTokenWSTrustBinding é muito semelhante ao wsFederationHttpBinding oculta a complexidade de tokens intermediários falando transparente para o IP-STS para adquirir um token intermediário é enviado ao R STS como um token de autenticação.

O código no do Figura 9 usa wsFederationHttpBinding para ativar um cliente WCF adquirir um token implicitamente como parte de uma chamada de serviço.

Observe que Estou usando um customBinding quando falando ao ponto de extremidade /IssuedTokenMixedSymmetricBasic256. WsFederationHttpBinding padrão não funciona aqui porque ele tenta estabelecer uma sessão segura, é incompatível com esta AD FS 2.0 ponto de extremidade. Interajam clientes WCF com AD FS 2.0, você precisa usar um customBinding ou uma das novas ligações baseados em WS-Trust que vem com WIF.

Figura 9 do wsFederationHttpBinding Using para obter um token implicitamente

<system.serivceModel>
   <bindings>
      <wsFederationHttpBinding>
         <binding name="R-STS">
            <security mode="Message">
               <message>
                  <issuer address="https://bccoss.com/Trust/2005/IssuedTokenMixedSymmetricBasic256" binding="customBinding" bindingConfiguration="IP-STS"/>
               </message>
            </security>
         </binding>
      </wsFederationHttpBinding>

      <customBinding>
         <binding name="IP-STS">
            <security authenticationMode="IssuedTokenOverTransport">
               <issuedTokenParameters>
                  <issuer address="http://localhost:9000/CustomSTS" binding="wsHttpBinding"/>
               </issuedTokenParameters>
            </security>
            <httpsTransport/>
         </binding>
      </customBinding>
   </bindings>

   <client>
      <endpoint address="http://localhost:9990/ES" binding="wsFederationHttpBinding" bindingConfiguration="R-STS"
contract="ServiceReference1.IEmployeeService" name="WSFederationHttpBinding_IEmployeeService"/>
      </client>
</system.serviceModel>

Clientes de navegador e AD FS 2.0

AD FS 2.0 tem suporte de primeira classe para Web single sign-on (WebSSO) e federação usando protocolos WS-Federation e SAML 2.0.

Conceitualmente, WS-Federation e protocolo SAML são semelhantes, embora eles têm fios diferentes representações. O formato de fios de WS-Federation está intimamente relacionado ao protocolo WS-Trust, portanto é a opção lógica quando estiver servindo clientes ativos e passivos (baseado em navegador). Protocolo SAML tem melhor interoperabilidade entre fornecedores diferentes. AD FS 2.0 oferece nativamente suporte ambos esses protocolos. É uma boa idéia usar um único protocolo (por exemplo, WS-Federation) dentro de seu limite de segurança e usar AD FS 2.0 como um hub de agente de protocolo para SSOs entradas ou saídas.

Considere um exemplo Let’s. Digamos que você tem um aplicativo ASP.NET simples que fornece funcionalidade somente para usuários autenticados. Como um aplicativo autônomo, lógica de autenticação é implementada como parte do aplicativo e uma interação com este aplicativo seria siga as etapas mostradas no do Figura 10.


Figura 10 do Direct autenticação em um aplicativo ASP.NET simples

Aqui estão sendo implementados os mecanismos de autenticação ASP.NET usuais, como autenticação de formulários. Nosso objetivo é extrair a funcionalidade de autenticação deste aplicativo e usar o AD FS 2.0.

No AD FS 2.0 instalação, que é mostrado no de Figura 11, o aplicativo se torna uma confiante confiável dentro AD FS 2.0 e portanto confia tokens emitidos por AD FS 2.0. O aplicativo usa WIF fazer todo o trabalho pesado de token de análise, extraindo declarações e assim por diante. Informações de identidade são fornecidas para o aplicativo usando as abstrações IIdentity/IPrincipal padrão.

A autenticação distribuída no AD FS 2.0 é muito mais flexível do que a autenticação direta e fornece alguns benefícios principais:

  • Autenticação é externalized do aplicativo, portanto, o mecanismo de autenticação pode ser alterado (por exemplo, de username para Kerberos) sem afetar o aplicativo.
  • A flexibilidade de um modelo baseado em declarações pode fornecer todas as informações necessárias para o aplicativo (como parte do token) diretamente em vez do aplicativo propriamente dito recuperando as informações de fontes diferentes.

Versão Beta 2 do WIF apresentou novos modelos de projeto que tornam fácil externalizar lógica de autenticação do aplicativo para um STS. Como de escrita, esses modelos estão disponíveis somente em translation from VPE for Csharp.


Figura 11 Distributed autenticação no AD FS 2.0

Lógica de autenticação externalizing

Para externalizar lógica de autenticação do aplicativo, use a caixa de diálogo novo site do Microsoft Visual Studio. Selecione o modelo do site ciente de declarações para criar um site da Web ASP.NET padrão que é pré-configurado com WIF.

Para iniciar o Assistente de utilitário de federação, mostrado em de Figura 12, clique com o botão direito do mouse no nó sites no Solution Explorer e selecione modificar STS Reference a partir do menu.


Figura 12 do utilitário de federação

Por exemplo, vamos escolher a opção “ usar um STS existente ” e especificar AD FS 2.0 como o STS. O assistente requer a URL do documento de metadados automatizar as configurações necessárias. A URL do documento de metadados está disponível como um ponto de extremidade dentro AD FS 2.0.

Federação metadados contém informações essenciais, como o STS certificado de assinatura, declarações oferecidas e a URL de emissão de token. Tendo um formato padronizado para essas informações habilita ferramentas para automatizar o estabelecimento de relações de confiança entre um STS e confiar partes.

A página Resumo do assistente resume as alterações forem feitas no arquivo web.config.

O Assistente de utilitário federação configura WIF no seu site para fornecer a seguinte funcionalidade:

  • Todas as solicitações não autenticadas serão redirecionadas para AD FS 2.0.
  • Qualquer solicitação que contém um token válido será processada e informações de identidade serão apresentadas para o aplicativo no formulário ClaimsIdentity/ClaimsPrincipal. O aplicativo continuará a acessar informações de identidade usando as abstrações IPrincipal/IIdentity padrão independentemente da fonte de informações.

Antes de testar o aplicativo, você precisa fazer uma última configuração alterar no AD FS 2.0. Você deve adicionar um ponto de extremidade adicional para a parte confiante para clientes de navegador. Este ponto de extremidade é necessário porque depois AD FS 2.0 tiver processado uma solicitação de emissão de token, duas partes de informações são necessárias antes de ele pode enviar o token de volta para o navegador:

  • O endereço onde o token deve ser enviado
  • O protocolo (SAML ou WS-Federation) através do qual o token deve ser enviado

Você pode adicionar um ponto de extremidade passivo para confiante na guia da caixa de diálogo Propriedades de RP Test Endpoints. Por exemplo, se você selecionar WS-Federation como tipo Endpoint, AD FS 2.0 irá enviar tokens de volta para a parte confiante usando o protocolo WS-Federation. Dentro da terceira parte confiável WIF, que entende nativamente protocolo WS-Federation, processa esses tokens.

Agora quando você tenta navegar para o aplicativo, são automaticamente redirecionados para AD FS 2.0 para autenticação, onde você pode escolher o método de autenticação que deseja usar: Autenticação integrada do Windows, autenticação de certificado ou formulário nome_de_usuário/senha.

Depois que a autenticação é bem-sucedida, você — juntamente com um token emitido por AD FS 2.0 — redirecionado volta para o aplicativo. WIF processa esse token e torna a identidade final (no formulário de declarações) disponíveis para o aplicativo usando mecanismos ASP.NET padrão (por exemplo, Page.User).

Federação com o navegador

Você pode estender um cenário básico de autenticação externa para um cenário de federação, adicionando um provedor de identidade confiável adicionais. Opções de provedor de identidade são mostradas durante o processo de autenticação.

Você pode autenticar com AD FS 2.0 ou outro confiável provedor de identidade. Se você selecionar um provedor de identidade diferente, você é redirecionadas para o provedor de identidade e, após a autenticação bem-sucedida, redirecionada de volta ao AD FS 2.0, então seria autenticar você com base em token emitido pelo provedor de identidade confiável.

Combinação poderosa

Como você viu neste artigo, o STS do AD FS 2.0 fornece um simplesmente e solução pronta para habilitar declarações seus serviços WCF e aplicativos baseados em navegador. STS propriamente dito é apenas uma pequena parte do AD FS 2.0, que também inclui um CardSpace sistema, um mecanismo de transformação de declarações baseado em regra, serviços de infra-estrutura, gerenciamento e configuração do gerenciamento de confiança automáticas e suas respectivas ferramentas de provisionamento. Juntamente com WIF, AD FS 2.0 cria uma combinação poderosa para soluções de identidade do programa na plataforma Windows.

Zulfiqar Ahmed é consultor sênior na equipe UK Application Development Consulting (ADC) e pode ser contactado de http://zamd.net .