Aplicações de partidos de gestão
Atualizado: 19 de junho de 2015
Aplica-se a: Azure
Uma aplicação por parte dependente (também conhecida como aplicação de sinistros ou aplicação baseada em sinistros) é uma aplicação ou serviço que se baseia em pedidos de autenticação. Em Microsoft Azure Ative Directory Controlo de Acesso (também conhecido como Serviço de Controlo de Acesso ou ACS), uma aplicação de parte de gestão é um site, uma aplicação ou um serviço que utiliza ACS para implementar a autenticação federada.
Pode criar e configurar as aplicações do partido manualmente, utilizando o Portal de Gestão ACS, ou programáticamente, utilizando o Serviço de Gestão ACS.
No Portal de Gestão acs, a aplicação de partidos que adiciona e configura é uma representação lógica do seu site, aplicação ou serviço que confia num espaço de nome Controlo de Acesso específico. Você pode adicionar e configurar muitas aplicações de partidos em cada Controlo de Acesso espaço de nome.
Configuração no Portal de Gestão ACS
Pode utilizar o Portal de Gestão ACS para configurar as seguintes propriedades de uma aplicação de parte em confiança:
Modo
URL de reino e retorno
URL de erro (opcional)
Formato Token
Política de Encriptação token
Duração do Token
Fornecedores de Identidade
Grupos de Regras
Assinatura simbólica
Encriptação simbólica
Modo
A propriedade Mode determina se configura manualmente as definições da aplicação da sua parte de suporte ou especifica um documento de metadados WS-Federation que define as definições da aplicação.
Um documento de metadados WS-Federation normalmente contém o reino de uma aplicação e URL de retorno. Também pode incluir um certificado de encriptação opcional que é usado para encriptar os tokens que ACS emite para a aplicação. Se um documento WS-Federation for especificado e os metadados contiverem um certificado de encriptação, a definição de Política de Encriptação token não é necessária encriptação. Se o valor da definição de Política de Encriptação Token for Requerição de Encriptação, mas o documento de metadados WS-Federation não incluir um certificado de encriptação, tem de carregar manualmente um certificado de encriptação.
Se a sua aplicação de partidos de gestão estiver integrada com Windows Identity Foundation (WIF), a WIF cria automaticamente um documento de metadados WS-Federation para a sua aplicação.
URL de reino e retorno
A propriedade Realm define o URI em que os tokens emitidos pela ACS são válidos. O URL de devolução (também conhecido como endereço AnswerTo) define o URL para o qual são enviadas as fichas emitidas pela ACS. Quando é solicitado um token para acesso à aplicação da parte de gestão, a ACS emite o símbolo apenas quando o reino no pedido simbólico corresponde ao reino da aplicação da parte que conta.
Importante
Em ACS, os valores do reino são sensíveis ao caso.
No Portal de Gestão acs, pode configurar apenas um reino e um URL de retorno em cada Controlo de Acesso espaço de nome. No caso mais simples, o reino e a URL de retorno são idênticos. Por exemplo, se o URI raiz da sua aplicação for https://contoso.com, o URL real e de retorno da aplicação do partido em gestão são https://contoso.com.
Para configurar mais de um URL de retorno (Endereço AnswerTo) para uma aplicação de parte dependente, utilize a entidade RelyingPartyAddress no Serviço de Gestão ACS.
Quando um token é solicitado à ACS ou um token é colocado na ACS de um fornecedor de identidade, a ACS compara o valor do reino no pedido simbólico aos valores do reino para as aplicações do partido. Se o pedido simbólico utilizar WS-Federation protocolo, o ACS utiliza o valor real no parâmetro wtrealm . Se o símbolo utilizar o protocolo OAuth WRAP, o ACS utiliza o valor do reino no parâmetro applies_to . Se o ACS encontrar um reino correspondente nas definições de configuração para uma aplicação de parte de gestão, cria um símbolo que autentica o utilizador para a aplicação da parte de gestão e envia o token para o URL de retorno.
O processo é semelhante quando a parte de confiante tem mais de um URL de retorno. ACS obtém o URL de redirecionamento do parâmetro wreply . Se o URL de redirecionamento for um dos URLs de retorno para a aplicação do partido de gestão, a ACS envia a resposta a esse URL.
Os valores do reino são sensíveis a casos. O token só é emitido se os valores do reino forem idênticos ou o valor real para a aplicação do partido em gestão é um prefixo do reino no pedido simbólico. Por exemplo, o valor do reino da aplicação da parte de gestão de funções corresponde http://www.fabrikam.com a um valor real de pedido simbólico de, mas não corresponde a um reino de http://www.fabrikam.com/billingpedido simbólico v de https://fabrikam.com.
URL de erro (opcional)
O URL de erro especifica um URL para o qual o ACS redireciona os utilizadores se ocorrer um erro durante o processo de início de sessão. É uma propriedade opcional da aplicação do partido dependente.
O valor URL de erro pode ser uma página personalizada hospedada pela aplicação do partido, como http://www.fabrikam.com/billing/error.aspx. Como parte do redirecionamento, a ACS fornece detalhes sobre o erro para a aplicação do partido de suporte como um parâmetro HTTP URL codificado por JSON. A página de erro personalizada pode ser concebida para interpretar as informações de erro codificadas pelo JSON, para tornar a mensagem de erro real e/ou para exibir texto de ajuda estática.
Para obter mais informações sobre a utilização do URL de erro, consulte a Amostra de Código: ASP.NET MVC 2 simples.
Formato Token
A propriedade de formato Token determina o formato dos tokens que a ACS emite para a aplicação do partido. A ACS pode emitir fichas SAML 2.0, SAML 1.1, SWT ou JWT. Para obter mais informações sobre formatos simbólicos, consulte Formatos Token Suportados em ACS.
A ACS utiliza protocolos padrão para devolver os tokens a uma aplicação ou serviço web. Quando mais de um protocolo é suportado para um formato simbólico, o ACS usa o mesmo protocolo que foi usado para o pedido simbólico. A ACS suporta as seguintes combinações de formato/protocolo simbólico:
A ACS pode devolver fichas SAML 2.0 utilizando protocolos WS-Trust e WS-Federation.
A ACS pode devolver fichas SAML 1.1 utilizando WS-Federation e protocolos de WS-Trust relacionados.
A ACS pode devolver fichas SWT usando protocolos WS-Federation, WS-Trust, OAuth-WRAP e OAuth 2.0.
A ACS pode emitir e devolver fichas JWT usando protocolos WS-Federation, WS-Trust e OAuth 2.0.
Para obter mais informações sobre protocolos padrão que o ACS utiliza, consulte Protocolos Suportados em ACS.
Ao escolher um formato simbólico, considere como o seu Controlo de Acesso espaço de nome assina os tokens que emite. Todos os tokens emitidos pela ACS devem ser assinados. Para mais informações, consulte Token Signing.
Além disso, considere se quer que os tokens sejam encriptados. Para mais informações, consulte a Política de Encriptação Token.
Política de Encriptação token
A política de encriptação token determina se os tokens que os problemas de ACS para a aplicação do partido em gestão são encriptados. Para necessitar de encriptação, selecione o valor de encriptação requere.
No ACS, pode configurar uma política de encriptação apenas para fichas SAML 2.0 ou SAML 1.1. O ACS não suporta a encriptação dos tokens SWT ou JWT.
O ACS encripta os tokens SAML 2.0 e SAML 1.1 utilizando um certificado X.509 contendo uma chave pública (ficheiro .cer). Estes tokens encriptados são então desencriptados usando uma chave privada possuída pela aplicação do partido. Para obter mais informações sobre a obtenção e utilização de certificados de encriptação, consulte Certificados e Chaves.
Configurar uma política de encriptação nos seus tokens emitidos pela ACS é opcional. No entanto, uma política de encriptação deve ser configurada quando a sua aplicação de partidos em funções é um serviço web que está a usar fichas de comprovação de posse ao longo do protocolo WS-Trust. Este cenário específico não funciona corretamente sem fichas encriptadas.
Duração do Token
A propriedade token lifetime especifica o intervalo de tempo (em segundos) durante o qual o sinal de segurança que ACS emite para a aplicação do partido de gestão é válido. O valor predefinido é de 600 (10 minutos). No ACS, o valor de vida simbólica deve ser entre zero (0) e 86400 (24 horas) inclusive.
Fornecedores de Identidade
A propriedade dos fornecedores de identidade especifica os fornecedores de identidade que podem enviar reclamações para a aplicação do partido que conta. Estes fornecedores de identidade aparecem na página de login da ACS para a sua aplicação ou serviço web. Todos os fornecedores de identidade configurados na secção de fornecedores de identidade do portal ACS constam da lista de fornecedores de identidade. Para adicionar um fornecedor de identificação à lista, clique em Fornecedores de Identidade.
Cada aplicação de partidos em gestão pode ser associada a fornecedores de identidade zero ou mais. As aplicações do partido em gestão num espaço de nome Controlo de Acesso podem ser associadas ao mesmo fornecedor de identidade ou a diferentes fornecedores de identidade. Se não selecionar nenhum fornecedor de identidade para uma aplicação de parte de confiança, deve configurar uma autenticação direta com ACS para a aplicação da parte de confiança. Por exemplo, pode utilizar identidades de serviço para configurar uma autenticação direta. Para mais informações, consulte as Identidades de Serviço.
Grupos de Regras
A propriedade do Grupo Regra determina quais as regras que a aplicação do partido que conta usar no processamento de reclamações.
Cada pedido de partido de gestão acs deve ser associado a pelo menos um grupo de regras. Se um pedido simbólico corresponder a uma aplicação de parte que não tenha grupos de regras, a ACS não emite um símbolo para a aplicação ou serviço web.
Todos os grupos de regras configurados na secção grupos regra do portal ACS aparecem na lista de grupos de regras. Para adicionar um grupo de regras à lista, clique em Grupos de Regras.
Quando se adiciona uma nova aplicação de partidos dependentes no Portal de Gestão ACS, a opção Criar Nova Regra é selecionada por padrão. Recomenda-se vivamente que crie um novo grupo de regras para a sua nova aplicação do partido. No entanto, pode associar a sua candidatura do partido a um grupo de regras existente. Para tal, limpe a opção Criar Nova Regra Grupo e selecione o grupo de regras pretendido.
Pode associar uma aplicação do partido dependente a mais de um grupo de regras (e associar um grupo de regras com mais do que uma aplicação de partidos). Se uma aplicação de partidos dependentes estiver associada a mais do que um grupo de regras, a ACS avalia recursivamente as regras em todos os grupos de regras como se fossem regras num único grupo de regras.
Para obter mais informações sobre regras e grupos de regras, consulte Os Grupos de Regras e Regras.
Assinatura simbólica
A propriedade de definição de definições token especifica como os tokens de segurança que as questões acs são assinadas. Todos os tokens emitidos pela ACS devem ser assinados.
As opções de assinatura simbólicas disponíveis dependem do Formato Token da aplicação do partido. (Para obter mais informações sobre formatos simbólicos, consulte o Formato Token.)
Fichas SAML: Use um certificado X.509 para assinar fichas.
Fichas SWT: Use uma chave simétrica para assinar fichas.
Fichas JWT: Utilize um certificado X.509 ou uma chave simétrica para assinar fichas.
Opções de certificado X.509. As seguintes opções estão disponíveis para fichas assinadas com um certificado X.509.
Utilize o certificado de espaço de serviço (standard)— Se selecionar esta opção, a ACS utiliza o certificado para o Controlo de Acesso espaço de nome para assinar fichas SAML 1.1 e SAML 2.0 para a aplicação da parte que conta. Utilize esta opção se planeia automatizar a configuração da sua aplicação web ou serviço utilizando metadados WS-Federation, porque a chave pública do espaço de nome é publicada no WS-Federation metadados para o seu Controlo de Acesso espaço de nome. O URL do documento WS-Federation Metadados aparece na página de Integração de Aplicações do Portal de Gestão acs.
Utilize certificado dedicado — Se selecionar esta opção, a ACS utiliza um certificado específico para a aplicação para assinar tokens SAML 1.1 e SAML 2.0 para a aplicação do partido. O certificado não é utilizado para outras aplicações de partes dependentes. Depois de selecionar esta opção, navegue por um certificado X.509 com uma chave privada (ficheiro.pfx) e introduza a palavra-passe para o ficheiro .pfx.
Nota
JWT Tokens. Quando configurar uma aplicação de parte de confiança para usar o certificado X.509 para o Controlo de Acesso espaço de nome para assinar fichas JWT para uma aplicação de partidos, links para o certificado de Controlo de Acesso namespace e a chave Controlo de Acesso namespace aparecem na página para a aplicação do partido de suporte no Portal de Gestão ACS. No entanto, a ACS utiliza apenas o certificado de espaço de nome para assinar fichas para a aplicação do partido.
Espaços de nome geridos. Quando estiver a adicionar uma aplicação de parte a um espaço de nome gerido, como um espaço de nome Service Bus, não introduza certificados ou teclas específicos para aplicações (dedicados). Em vez disso, selecione as opções que direcionam o ACS para a utilização dos certificados e chaves configurados para todas as aplicações no espaço de nome gerido. Para mais informações, consulte Espaços de Nome GeridosPara obter mais informações sobre certificados e chaves partilhados e dedicados, consulte Certificados e Chaves.
Opções-chave simétricas
Como uma boa prática de segurança, ao utilizar chaves simétricas, crie uma chave dedicada para cada aplicação do partido, em vez de usar a chave simétrica partilhada para o Controlo de Acesso espaço de nome. Se introduzir ou gerar uma chave dedicada, a ACS utiliza uma chave dedicada para assinar fichas para a aplicação do partido, desde que a chave dedicada seja válida. No entanto, se a chave dedicada expirar e não for substituída, a ACS utiliza a chave de espaço de nome partilhado para assinar fichas para a aplicação do partido.
Se optar por utilizar a chave simétrica partilhada, copie os valores da chave 'Serviço Namespace ' a partir da página certificados e teclas e cole-os nos campos na secção assinatura token da página de aplicações do partido Relying .
As seguintes opções estão disponíveis para fichas assinadas com teclas simétricas.
Tecla de assinatura de token — Introduza uma tecla simétrica de 256 bits ou clique Gerar para gerar uma tecla simétrica de 256 bits.
Data efetiva — Especifica a data de início do intervalo de datas durante o qual a tecla simétrica é válida. A partir desta data, a ACS utiliza a chave simétrica para assinar fichas para a aplicação do partido. O valor padrão ACS é a data atual.
Data de validade: Especifica a data de finalização do intervalo de datas durante o qual a tecla simétrica é válida. A partir desta data, a ACS não utiliza a chave simétrica para assinar fichas para a aplicação do partido. Não há valor padrão. Como boas práticas de segurança, as chaves simétricas devem ser substituídas todos os anos ou de dois em dois anos, dependendo dos requisitos da aplicação.
Encriptação simbólica
A opção de certificado de encriptação simbólica especifica o certificado X.509 (.cer ficheiro) que é usado para encriptar fichas para a aplicação do partido. Em ACS, pode encriptar apenas fichas SAML 2.0 ou SAML 1.1. O ACS não suporta a encriptação de fichas SWT ou JWT.
Especifica certificados para encriptação simbólica na secção Certificados e Chaves do portal ACS. Quando clicar no link Clique aqui na secção Política de Encriptação Token da página de aplicação do partido Decretado, abre-se a página de Certificados e Chaves do Certificado de Encriptação De Token . Utilize esta página para especificar um ficheiro de certificado.
Para mais informações, consulte a Política de Encriptação Token. Para obter mais informações sobre a obtenção e adição de certificados de encriptação, consulte Certificados e Chaves.