Como as permissões são determinadas (Master Data Services)
No Master Data Services, a maneira mais simples de configurar a segurança é atribuir permissões de objeto modelo a um grupo do qual o usuário é membro.
A segurança se torna mais complexa quando:
As permissões de objeto modelo e de membro da hierarquia são atribuídas.
O usuário pertence a grupos e a permissão é atribuída ao usuário e aos grupos.
O usuário pertence a grupos e a permissão é atribuída a vários grupos.
Permissões atribuídas a um único grupo ou usuário
Se você atribuir permissões a um único grupo ou usuário, as permissões serão determinadas com base no seguinte fluxo de trabalho.
.gif "Permissões sobrepostas")
Etapa 1: permissões de atributo efetivas são determinadas.
A lista a seguir descreve como as permissões de atributo efetivas são determinadas:
As permissões atribuídas a objetos modelo determinam quais atributos um usuário pode acessar.
Todos os objetos modelo herdam automaticamente a permissão do objeto mais próximo em um nível alto da estrutura do modelo.
Qualquer objeto no mesmo nível da entidade é negado implicitamente.
Qualquer objeto em um nível mais alto recebe acesso de navegação. Para obter mais informações sobre acesso de navegação, consulte Acesso de navegação (Master Data Services).
Neste exemplo, a permissão Somente leitura é atribuída a uma entidade, e essa permissão é herdada por seu atributo que está a um nível inferior na estrutura modelo. O modelo fornece acesso de navegação a essa entidade e seu atributo. A outra entidade no modelo não tem nenhuma permissão explícita atribuída e não herda nenhuma permissão, portanto, é negada implicitamente.
.gif "Herança de permissões de objeto de modelo")
Etapa 2: se permissões de membro de hierarquia forem atribuídas, as permissões de membro efetivas serão determinadas.
A lista a seguir descreve como as permissões de membro da hierarquia efetivas são determinadas:
As permissões atribuídas a nós da hierarquia determinam quais membros um usuário pode acessar.
Todos os nós de uma hierarquia herdam automaticamente a permissão do objeto mais próximo em um nível alto da estrutura da hierarquia.
Qualquer nó no mesmo nível é negado implicitamente.
Qualquer nó em níveis mais altos que não tenha permissões atribuídas é negado implicitamente.
Neste exemplo, a permissão Somente leitura é atribuída a um nó da hierarquia e essa permissão é herdada por um nó em um nível mais baixo na estrutura da hierarquia. A raiz não tem nenhuma permissão atribuída, portanto é negada implicitamente. O outro nó na estrutura da hierarquia não tem nenhuma permissão explícita atribuída e não herda nenhuma permissão, portanto, é negado implicitamente.
.gif "Herança de permissões de membro de hierarquia")
Etapa 3: a interseção de permissões de atributo e de membro é determinada.
Se as permissões de atributo efetivas forem diferentes das permissões de membro efetivas, as permissões deverão ser determinadas para cada valor de atributo individual. Para obter mais informações, consulte Sobrepondo permissões de modelo e membro (Serviços de Dados Mestre).
Permissões atribuídas a vários grupos
Se um usuário pertencer a um ou mais grupos e as permissões forem atribuídas ao usuário e aos grupos, o fluxo de trabalho se tornará mais complexo.
.gif "Permissões sobrepostas")
Nesse caso, a sobreposição das permissões do usuário e do grupo deve ser resolvida antes das permissões do objeto modelo e do membro da hierarquia poderem ser comparadas. Para obter mais informações, consulte Sobrepondo permissões de usuário e grupo (Serviços de Dados Mestre).
Consulte também
Conceitos
Histórico de alterações
Conteúdo atualizado |
|---|
Arte adicionada para ilustrar conceitos e texto do tópico atualizado correspondentemente. |