Reivindicações personalizadas com estrutura de Genebra e como “sincronizar” usuários em seu aplicativo

Question

Talvez esta pergunta destaque o quão pouco eu sei sobre gerenciamento de identidade de sinistros, mas aqui vai.

Se estiver usando WIF em um aplicativo que usa um STS de terceiros para identidade e que usa declarações personalizadas para autorização (algo pertinente e específico para o aplicativo, como CanCreateFooBar)

1) Como faço para gerenciar os usuários?Ou seja, os usuários do AD ou de outro provedor de associação podem ser identificados, mas internamente em meu sistema eu preciso saber sobre eles e ter mais informações do usuário que não tenham nada a ver com identidade (então realmente não faria sentido ter essas informações disponíveis fora do sistema), e que as informações sobre o usuário devem ser persistidas,
A questão é: Como posso gerenciar e criar os dados do meu sistema (começando pelos Ids) de maneira inteligente?
O cenário exato que tenho em mente é: um novo funcionário é adicionado à empresa, o administrador do sistema cria o usuário para o domínio com uma função específica. Como meu sistema pode ficar ciente desse fato?(eu provavelmente gostaria que o sistema solicitasse uma ação ao administrador do sistema

2) Onde estão armazenados os valores de declaração desses usuários e funções e como posso modificá-los?Idealmente, quero poder alterar as permissões de um usuário e ação específicos.Existe alguma orientação sobre isso?

Posso ver que essas são perguntas provavelmente muito idiotas, mas quando penso em como resolver o problema, encontro soluções complicadas ou que exigem muita duplicação (ou seja, criar o usado em dois lugares), então tenho certeza de que simplesmente não estou pensando sobre esse problema da maneira certa

Obrigado

Answer 1

1) Você não gerencia os usuários, na verdade não.Você simplesmente pega o IClaimsIdentity e o usa como fonte para sua autorização.Na minha opinião, você não deveria persistir nas reivindicações se puder escapar sem fazê-lo - as reivindicações devem ser a fonte das informações do seu usuário.

Se você quiser desenvolver as declarações, obtenha uma referência exclusiva da identidade das declarações, digamos endereço de e-mail ou hash Ppid/chave de assinatura OU e use-a para criar seu próprio banco de dados e adicionar suas próprias informações.

No entanto, seu sistema nunca ficará isento de alterações em uma metabase de identidade de terceiros - não até que um novo token SAML seja emitido e analisado em seu aplicativo.

2) Os valores das declarações não são armazenados em lugar nenhum, a menos que você os armazene.Como você traduz isso em permissões depende de você - mas geralmente você executa a transformação de declarações para pegar as declarações externas e mapeá-las para declarações internas ao seu aplicativo que você usa para permissões.Como as reivindicações vêm de provedores externos, você não pode alterá-las – você não tem conexão com esses provedores.

Answer 2

Como você pode ver, a federação não alivia necessariamente a necessidade de provisionamento.Este é um insight importante que não é imediatamente óbvio.

Existem várias maneiras de resolver isso, incluindo:

1. O uso de um produto de diretório meta ou virtual ou
2. Usando "provisionamento JIT" (também conhecido como "provisionamento dinâmico" ou "provisionamento instantâneo").

Deixe-me explicar o último.Esta solução, que também descrevo no meu blog, inclui dois STSs, um IP-STS e um RP-STS.O primeiro autentica apenas o usuário;a segunda é específica para sua aplicação e sabe quais declarações são necessárias para autorizar os usuários desse sistema.O IP-STS não pode emitir esses atributos específicos de aplicativos, pois isso exigiria que seu serviço de diretório corporativo ficasse sobrecarregado com todos os tipos de informações específicas de aplicativos.Em vez disso, os atributos para usuários mantidos nesse armazenamento e emitidos pelo IP-STS são de natureza geral e aplicáveis ​​ao usuário, independentemente da aplicação que ele esteja usando.Após a autenticação no IP-STS e a obtenção de solicitações somente de identidade, o token é repassado ao RP-STS.Este serviço de token está fortemente acoplado ao seu aplicativo.Ele sabe quais declarações os usuários precisam para acessar diferentes recursos.Ele pode converter as declarações somente de identidade nas necessárias para tomar essa decisão de controle de acesso.Portanto, o RP-STS é um transformador de declarações que mapeia declarações relacionadas à identidade em declarações específicas do aplicativo.

Como o RP-STS provisiona o usuário?Suponha que um novo funcionário seja criado, como no exemplo acima.Quando o usuário acessar seu aplicativo, ele será encaminhado para o RP-STS.Ele não estará logado lá, então será transferido para o IP-STS.O administrador do sistema criou uma conta para ele, para que ele possa fazer login e seu navegador o retornará ao RP-STS.O RP-STS irá quebrar o token, obter o ID do usuário (e-mail, PPID, etc.) e verificar se não sabe quem é o usuário.Assim, o RP-STS irá provisionar o usuário.Isso será feito exibindo uma página da Web, por exemplo.Pode coletar informações que o ajudem a determinar a função desse usuário ao acessar o RP.Após isso, o usuário será provisionado (ou seja, será criado um registro em seu banco de dados contendo valores de reivindicação para ele), e o RP-STS emitirá um token específico para sua aplicação e o redirecionará de volta para lá.A aplicação não saberá que acabou de ser provisionado;ele apenas usará as declarações como sempre faz.(Veja por que chamei isso de provisionamento JIT?)

E se as coisas mudarem depois que o usuário foi provisionado?OK.Imagina isto:o usuário foi criado no armazenamento de diretório há muito tempo e foi provisionado conforme descrito acima no RP-STS e ele usa o sistema com satisfação há muito tempo.Depois, há uma mudança de política que exige que os usuários do seu aplicativo aceitem os novos termos e condições (T&Cs).Na próxima vez que o usuário fizer login no aplicativo, ele será redirecionado para o RP-STS, para o IP-STS, ele será autenticado e devolvido ao seu RP-STS.Nesse ponto, ele perceberá que o usuário deve aceitar os novos T&Cs, portanto mostrará ao usuário uma página da Web e obterá sua concordância.Posteriormente, o RP-STS emitirá um token de segurança e o redirecionará para o seu aplicativo.Seu aplicativo irá, como sempre, lidar com as reivindicações e fazer o que for necessário para autorizar o acesso.Não saberá e não vai se importar que o usuário tenha sido "re-provisionado". Como alternativa, você pode manter as alterações na sincronização entre o armazenamento de identidade (ou seja, seu diretório corporativo) e a loja de reivindicações do seu RP-STS usando um produto como ILM (ou FIM, como agora é chamado).Dependendo do seu sistema, um produto que faça sincronização de canal de retorno como este pode ser mais apropriado.

Aliás, essas não são perguntas "fracassadas"!Existem questões muito perspicazes que refletem um pensamento profundo e uma reflexão inteligente sobre um problema muito complicado.Outros que você precisará responder incluem:

• Como os administradores do seu aplicativo atualizam sua política (por exemplo, alteram os T&Cs)?Qual UI/API você deve criar?A UI está integrada àquela usada para gerenciar a política do IP-STS?
• Que tipo de relações de confiança devem existir para que tal sistema funcione?
• E se o sujeito não estiver usando o perfil passivo?E se ele estiver usando o perfil ativo e/ou não houver UI?
• Como e onde as chaves estão localizadas?Quais permissões são necessárias para usar essas chaves?Como eles são revisados, distribuídos e como os administradores de sistema são alertados quando estão prestes a expirar?

É realmente fácil demonstrar esse material em reuniões de grupos de usuários e conferências, mas na realidade é um material muito avançado.Se você tiver outras dúvidas, sinta-se à vontade para publicá-las aqui ou entre em contato comigo diretamente.