Partilhar via


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 de modelo a um grupo do qual o usuário é membro.

A segurança se torna mais complexa quando:

  • As permissões para o objeto do modelo e para o 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 fluxo de trabalho a seguir.

mds_conc_security_no_overlap

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 de modelo determinam quais atributos um usuário pode acessar.

  • Todos os objetos de modelo herdam automaticamente a permissão do objeto mais próximo em um nível mais alto na estrutura do modelo.

  • Todos os objetos no mesmo nível da entidade são negados implicitamente.

  • Todos os objetos em um nível mais alto recebem acesso de navegação. Para obter mais informações sobre acesso de navegação, consulte o 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á em um nível inferior na estrutura do modelo. O modelo fornece acesso navegacional 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, ela é negada implicitamente.

mds_conc_inheritance_model

Etapa 2: Caso as permissões de membros da hierarquia sejam atribuídas, serão determinadas as permissões efetivas desses membros.

A lista a seguir descreve como as permissões efetivas de membro da hierarquia são determinadas:

  • As permissões atribuídas aos nós de hierarquia determinam quais membros um usuário pode acessar.

  • Todos os nós em uma hierarquia herdam automaticamente a permissão do objeto mais próximo em um nível mais alto na estrutura da hierarquia.

  • Todos os nós no mesmo nível são negados implicitamente.

  • Todos os nós nos níveis superiores que não têm permissões atribuídas são recusados 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 inferior na estrutura da hierarquia. A raiz não tem nenhuma permissão atribuída, portanto, ela é negada implicitamente. O outro nó na estrutura de hierarquia não tem nenhuma permissão explícita atribuída e não herda nenhuma permissão, portanto, ela é negada implicitamente.

mds_conc_inheritance_hierarchy

Etapa 3: A interseção de permissões de atributo e 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 Permissões Sobrepostas de Modelo e Membro no Master Data Services.

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.

mds_conc_security_group_overlap

Nesse caso, as permissões de usuário e grupo sobrepostas devem ser resolvidas antes que as permissões de membro de objeto e hierarquia de modelo possam ser comparadas. Para obter mais informações, consulte Permissões sobrepostas de usuário e grupo (Master Data Services).

Consulte Também

Permissões sobrepostas de usuários e grupos (Master Data Services)Permissões sobrepostas de modelo e membro (Master Data Services)