Em nosso ambiente de desenvolvimento, estamos tendo um problema com nossas Partes Confiantes configuradas no ADFS 2.0 que está me desconcertando. Está agindo como se houvesse uma lista negra de identificadores.
Nós temos 3 desenvolvedores trabalhando contra isso agora (nova configuração no Win2kR2 para ADFS, Win7 Pro / VS2010 / MVC2 / C # para desenvolvedores). O ADFS está em Domain2 , enquanto todas as caixas dev estão em Domain1 . Domain2 confia em Domain1 mas não o contrário (não que isso importe). Eu criei 3 trusts, um para cada desenvolvedor. O endpoint e os identificadores de confiança são os mesmos para cada desenvolvedor ( https://DevBoxFQDN/AppName/ ). Ao configurar isso inicialmente, eu estava usando apenas DevA como um caso de teste até que ele funcionasse. Uma vez que funcionou para DevA , eu adicionei DevB , mas fiz isso incorretamente adicionando DevB's identifier ao DevA RP. O resultado final foi quando você tentou se autenticar no aplicativo DevB's web, quando redirecionado de volta para o aplicativo, foi para DevA's box. Configuração bagunçada, mas eu chamaria isso de um caso de teste de sucesso para a caixa DevB . Depois que percebi isso, removi DevB's identifier do DevA RP e criei os DevB e DevC RPs (apontando para https://DevB.FQDN/AppName/ e https://DevC.FQDN/AppName/ para endpoints e identificadores).
Nesse ponto, algo estranho aconteceu. Isso funcionou apenas para DevC , como acontece para DevA . No entanto, DevB obtém as IDs de evento 184/364 indicando que o identificador DevB está incorreto. Muita depuração e googling de possíveis problemas resultaram em nada útil. Como uma tentativa cega, simplesmente criamos um novo Diretório virtual na caixa DevB para https://DevB.FQDN/AppName2/ (literalmente apenas adicionamos um 2 ao final do diretório virtual / nome do aplicativo - aponta para o mesmo local que o outro um e tem as mesmas configurações) e fez a mesma alteração no arquivo web.config do aplicativo. No ADFS, eu editei o endpoint e o identificador para adicionar o 2 também. Essa alteração e essa alteração sozinhas fazem com que DevB funcione corretamente. Então isso desmascara a maioria das possibilidades que suspeitamos não se aplicam a nós (firewalls, certificados / SPNs, etc.) que os posts do fórum nos deixaram. Se alterarmos isso de volta para remover o 2 , ele será quebrado novamente. Nada muda!
E só para sermos completos, revertemos a máquina DevB de volta para um backup baseado em imagens a partir do momento em que estava "trabalhando", mas sob o DevA RP - nenhuma alteração. Então isso me diz que o problema está em algum lugar na configuração do servidor ADFS ou algo entre, mas não o servidor web.
Então, qual é o problema? Por que o ADFS não funciona com um identificador / ponto de extremidade específico (simplesmente uma URL de cadeia de caracteres, por mais que eu possa dizer), mas se eu simplesmente adicionar um 2 a ele em todos os casos, isso funciona? Existe uma lista negra / cache ou algo que eu preciso limpar?
Dois eventos são registrados: 184 e 364. O 364 não tem interesse, pois simplesmente diz que "algo deu errado", mas o 184 é de interesse. Os detalhes do log de eventos do erro (ID do Evento: 184):
A token request was received for a relying party identified by the key
'https://DevB.FQDN/AppName/', but the request could not be fulfilled
because the key does not identify any known relying party trust.
Key: https://DevB.FQDN/AppName/
This request failed.
User Action
If this key represents a URI for which a token should be issued, verify
that its prefix matches the relying party trust that is configured in
the AD FS configuration database.
E, por último, tenho o identificador duplo / triplo / quintuplicado. É correto sem erros de digitação ou qualquer coisa.
PS: Este é um post-cross de Fóruns da Microsoft para este problema.