Multi-inquilino Modelo de usuário

votos
3

Em um sistema multitenant que hospeda várias organizações e aplicações, em que uma organização pode usar várias aplicações hospedadas no sistema, deve ser o meu modelo de usuário e papel ser tal que um único usuário ou papel pode existir em vários aplicativos e organizações? Ou eu deveria limitar uma entidade de usuário para um único par organização / aplicação e, em seguida, definir algum modelo abrangente para amarrar essas entidades usuárias juntos?

Isso é:

  • John Doe é uma pessoa

  • Ele quer usar ApplicationA e ApplicationB

  • Ele trabalha para duas empresas diferentes (apenas paciência comigo), organizationâ e OrganizationB

Caso o modelo do usuário ser:

  1. johndoe @ someuniquesuffix é o seu nome de usuário exclusivo. Isto dá-lhe acesso a ambas as aplicações para ambas as organizações.

  2. johndoe @ ApplicationA @ organizationâ é o seu nome de usuário para ApplicationA em organizationâ. johndoe @ applicationb @ organizationâ é o seu nome de usuário para ApplicationB em organizationâ ... eo mesmo para OrganizationB. Então, alguma lista mestre que diz que todos os 4 contas de usuário para os aplicativos / orgs correspondem à mesma pessoa real, John Doe?

O mesmo cenário (s) descrito acima se aplica à forma como eu vou projetar uma esquema de Papel.

Obrigado por qualquer Assistência!

Publicado 15/08/2010 em 00:23
fonte usuário
Em outras línguas...                            


2 respostas

votos
3

IMO, você deve limitar cada conjunto de credenciais para uma organização. Além disso, você deve habilitar a capacidade para cada aplicação para restringir o que os usuários dentro dessa organização pode fazer com cada aplicação. Ou seja, cada aplicação deve gerir as suas próprias funções de autorização. Você precisa de alguns meios de lidar com o cenário onde Joe deixa Organização A, mas continua a trabalhar para a Organização B.

Respondeu 15/08/2010 em 00:46
fonte usuário

votos
2

Pessoalmente, penso que se manter a par de que John Doe é uma pessoa que trabalha tanto na Organização A e na Organização B complica as coisas de forma significativa, sem adicionar muito valor para a maioria dos casos . A menos que você tenha uma razão de negócio claro para entender em seu modelo que é um John Doe é o mesmo como do B John Doe, eu abster-se dela. Mantendo o seu banco de dados de usuário em todos os orgs, ter que lidar com nomes exclusivos em todo orgs ( 'O que quer dizer que já existe um John Doe? Isso não é comigo!') E tendo o modelo UI isso (por exemplo. Perguntando ao usuário no login ' quer trabalhar em de a hoje de dados ou em dados do B?) só acrescenta complicações significativas.

O único inconveniente da minha recomendação é que se você usar um terceiro autenticador partido como OpenID ou OAuth, em seguida, uma pessoa que tem vários inquilinos tem que entrar com IDs diferentes. Por exemplo. I ingresse em minha google openId eu acabar em dados de A, mas para trabalhar em B que precisam usar minha conta no Twitter, porque o meu id Google já está vinculada a um e só A.

Respondeu 15/08/2010 em 04:20
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more