Confiança transitiva do ADFS v.2.0 em um cenário de federação

Question

Atualmente, estou trabalhando com o ADFS para estabelecer uma confiança federada entre dois domínios separados.

Minha pergunta é simples: o ADFS v. 2.0 oferece suporte à confiança transitiva em provedores de identidade federada? Em caso afirmativo, consulte as perguntas abaixo. (Não estou falando sobre relações de confiança de floresta do AD, mas sobre domínios separados completamente usando o ADFS 2.0 puro em um cenário de federação)

Eu sei que o ADFS v 1.0 não, conforme declarado no este documento na página 9 . Mas, ao observar as regras de declarações fornecidas com o ADFS 2.0, parece ser possível, como um parceiro da Microsoft confirmado. No entanto: a documentação sobre este tópico é uma bagunça! Simplesmente não há instruções relacionadas ao ADFS v. 2.0 sobre este tópico que eu consegui encontrar ( SE você obteve alguma documentação sobre isso, POR FAVOR me ajude!).

Para ser mais claro, vamos supor este cenário:

Federation provider (A) trust federation provider (B) which trusts identity provider (C).
So, does (A) trust identities comming from (C) across (B)?

Mais perguntas em caso de suporte à confiança transitiva:

• É possível restringir a confiança transitiva no ADFS de alguma forma? Se sim, como? (Comando Powershell ou ADFS GUI menü entrada onde encontrá-lo)
• Como a confiança transitiva afeta as propriedades do emissor e do OriginalIssuer das reivindicações?
• Se a confiança transitiva é usada junto com as transformações de sinistros e o provedor (B) transformaria declarações de entrada de (C) de forma que elas sejam transformadas em (novas) reivindicações do mesmo tipo um valor, como isso afetaria o Emissor e Propriedades do OriginalIssuer?

IMPORTANTE: quer seja suportado ou não, eu preciso de algumas fontes oficiais sobre isso. No entanto, se ninguém mais puder fornecê-las e alguém puder responder as perguntas com o seu experiência, eu estou disposto a dar a recompensa para ele / ela, mesmo sem fontes oficiais.

    

Answer 1

Bem, como ninguém respondeu, eu arrumei um tempo, configurei um laboratório de teste e cheirei o tráfego HTTPS. Aqui estão os meus resultados de pesquisa no caso de alguém mais se deparar com essa coisa:

• Ainda não tenho uma fonte oficial para essas perguntas
• Primeiramente: sim, a confiança transitiva é possível e não há como bloqueá-la, exceto questões jurídicas. Um SLA propício é a base para qualquer cenário de federação de qualquer maneira.
• Não há uma "configuração" especial para desativá-lo ou ativá-lo, mas usando o mecanismo de regras de declarações, um parceiro confiável pode configurar QUALQUER tipo de declarações de saída SE qualquer tipo de declaração de reconhecimento for detectado, portanto não há como "proteger" acesso ilegal.
• Nos meus testes, nenhum dos modelos de regras fornecidos com o ADFS alterou a propriedade OriginalIssuer das declarações. Alguém pode pensar: Ok, então eu posso usar essa propriedade para verificar a fonte original de qualquer reclamação e construir um filtro para permitir que as reclamações venham diretamente de (e não atravessadas, que por padrão afeta apenas o Emissor, mas não a propriedade OriginalIssuer). parceiro confiável. Mas isso é errado, por quê? Olhe para a próxima linha.
• Como eu disse, os modelos padrão não tocam na propriedade OriginalIssuer. Mas você pode criar regras personalizadas usando o mecanismo de regras. Usando esse, você pode alterar praticamente todo tipo de declaração, valor e suas propriedades. E sim: também o OriginalIssuer. Então, para o provedor de federação, parece que as declarações estão vindo diretamente do parceiro confiável, onde, na realidade, elas só são transformadas lá.

Então, o que eu sugeriria, pelo menos, minimizar cenários "transitivos" se eles não forem desejados, é verificar o OriginalIssuer. Ele não protege de logins transitivos, mas um administrador teria que configurá-lo explicitamente - o que tornaria as afianças legais muito mais fáceis em um caso de violação de SLA. Além disso, eu não estou pensando na possibilidade de mudar o OriginalIssuer como um "bug", na verdade: mesmo sem esse recurso, todo software da terceira parte poderia sempre torná-lo capaz de agir como um proxy entre sistemas backend e o provedor de identidade confiável. . Por exemplo, o IdP poderia criar contas-sombra para o parceiro (C) - assim, sempre haverá uma solução alternativa ao usar a federação, você está dando o controle sobre quem pode delegar direitos de acesso a recursos específicos.

De qualquer forma - se você ficou tão curioso quanto eu sobre como o ADFS 2.0 lida com relações de confiança transitivas, agora você sabe, sem a necessidade de criar um testlab e sniff de tráfego HTTPS.