Serviço de direitos

  • Artigo

O gerenciamento de acesso é uma função crítica para qualquer serviço ou recurso. O serviço de direitos permite controlar quem pode usar seu Azure Data Manager for Energy por exemplo, o que eles podem ver ou alterar e quais serviços ou dados podem usar.

Estrutura e nomenclatura de grupos OSDU

O serviço de direitos do Azure Data Manager for Energy permite criar grupos e gerenciar associações dos grupos. Um grupo de direitos define permissões em serviços ou fontes de dados para uma partição de dados específica em sua instância do Azure Data Manager for Energy. Os usuários adicionados a um grupo específico obtêm as permissões associadas. Todos os identificadores de grupo (e-mails) são do formato {groupType}.{serviceName|resourceName}.{permission}@{partition}.{domain}.

Grupos diferentes e direitos de usuário associados devem ser definidos para cada nova partição de dados, mesmo na mesma instância do Azure Data Manager for Energy.

Tipos de grupos OSDU

O serviço de direitos permite três casos de uso para autorização:

Grupos de dados

  • Os grupos de dados são usados para habilitar a autorização de dados.
  • Os grupos de dados começam com a palavra "dados", como data.welldb.viewers e data.welldb.owners.
  • Usuários individuais são adicionados aos grupos de dados, que são adicionados na ACL de registros de dados individuais para habilitar viewer e owner acessar os dados depois que os dados são carregados no sistema.
  • Para upload os dados, você precisa ter direitos de vários serviços OSDU, que são usados durante o processo de ingestão. A combinação de serviços OSDU depende do método de ingestão. Por exemplo, para ingestão de manifesto, consulte Conceitos de ingestão baseada em manifesto para entender os serviços OSDU usados pelas APIs. O usuário não precisa fazer parte da ACL para carregar os dados.

Grupos de serviços

  • Os grupos de serviços são usados para habilitar a autorização de serviços.
  • Os grupos de serviços começam com a palavra "serviço", como service.storage.user e service.storage.admin.
  • Os grupos de serviços são predefinidos quando os serviços OSDU são provisionados em cada partição de dados da instância do Azure Data Manager for Energy.
  • Esses grupos habilitam viewer, editore admin acesso para chamar as APIs OSDU correspondentes aos serviços OSDU.

Grupos de utilizadores

  • Os grupos de usuários são usados para agrupamento hierárquico de grupos de usuários e serviços.
  • Os grupos de serviços começam com a palavra "usuários", como users.datalake.viewers e users.datalake.editors.

Hierarquia aninhada

  • Se user_1 fizer parte de um data_group_1 e data_group_1 for adicionado como membro ao user_group_1, o código OSDU verificará a associação aninhada e autorizará user_1 a acessar os direitos para user_group_1. Isso é explicado em OSDU Entitlement Check API e OSDU Retrieve Group API.

  • Você pode adicionar usuários individuais a um user grouparquivo . O user group é então adicionado a um data grouparquivo . O grupo de dados é adicionado à ACL do registro de dados. Ele permite a abstração para os grupos de dados porque os usuários individuais não precisam ser adicionados um a um ao grupo de dados. Em vez disso, você pode adicionar usuários ao user group. Em seguida, você pode usar o repetidamente user group para vários data groups. A estrutura aninhada ajuda a fornecer escalabilidade para gerenciar associações no OSDU.

Grupos padrão

  • Alguns grupos OSDU são criados por padrão quando uma partição de dados é provisionada.
  • Os grupos de dados de data.default.viewers e data.default.owners são criados por padrão.
  • Grupos de serviços para visualizar, editar e administrar cada serviço, como service.entitlement.admin e service.legal.editor são criados por padrão.
  • Os grupos de usuários de users, users.datalake.viewers, users.datalake.editors, users.datalake.admins, users.datalake.opse users.data.root são criados por padrão.
  • O gráfico de membros e grupos padrão em grupos de direitos OSDU Bootstrapped mostra os grupos de cabeçalhos de coluna como o membro de cabeçalhos de linha. Por exemplo, users grupo é membro de data.default.viewers e data.default.owners por padrão. users.datalake.admins e users.datalake.ops são membros do service.entitlement.admin grupo.
  • A entidade de serviço ou o client-id ou o app-id é o proprietário padrão de todos os grupos.

Peculiaridade do users@ grupo

  • Há uma exceção desta regra de nomenclatura de grupo para o grupo "usuários". Ele é criado quando uma nova partição de dados é provisionada e seu nome segue o padrão de users@{partition}.{domain}.
  • Ele tem a lista de todos os usuários com qualquer tipo de acesso em uma partição de dados específica. Antes de adicionar um novo usuário a qualquer grupo de direitos, você também precisa adicionar o novo usuário ao users@{partition}.{domain} grupo.

Peculiaridade do users.data.root@ grupo

  • O grupo de direitos users.data.root é o membro padrão de todos os grupos de dados quando os grupos são criados. Se você tentar remover users.data.root de qualquer grupo de dados, você receberá um erro, uma vez que essa associação é imposta pelo OSDU.
  • users.data.root torna-se automaticamente o proprietário padrão e permanente de todos os registros de dados quando os registros são criados no sistema, conforme explicado na API de acesso de proprietário OSDU valide e na API de verificação de raiz de dados dos usuários OSDU. Como resultado, independentemente da associação OSDU do usuário, o sistema verifica se o usuário é "DataManager", ou seja, parte do grupo data.root, para conceder acesso ao registro de dados.
  • A associação padrão em users.data.root é apenas a app-id que é usada para configurar a instância. Você pode adicionar outros usuários explicitamente a esse grupo para dar-lhes acesso padrão de registros de dados.

Como exemplo no cenário,

  • Um data_record_1 tem 2 ACLs: ACL_1 e ACL_2.
  • User_1 é membro do ACL_1 e users.data.root.

Agora, se você remover user_1 do ACL_1, resta user_1 ter acesso ao data_record_1 através do grupo users.data.root.

E se ACL_1 e ACL_2 forem removidos do data_record_1, users.data.root continuará a ter acesso de proprietário dos dados. Isso preserva o registro de dados de ficar órfão nunca.

OID desconhecido

Você verá um OID desconhecido em todos os grupos OSDU adicionados por padrão, esse OID refere-se a uma ID de instância interna do Azure Data Manager for Energy que é usada para comunicação entre sistemas. Este OID é criado exclusivamente para cada instância.

Utilizadores

Para cada grupo OSDU, você pode adicionar um usuário como PROPRIETÁRIO ou MEMBRO:

  • Se você for um PROPRIETÁRIO de um grupo OSDU, poderá adicionar ou remover os membros desse grupo ou excluir o grupo.
  • Se você for um MEMBRO de um grupo OSDU, poderá visualizar, editar ou excluir o serviço ou os dados, dependendo do escopo do grupo OSDU. Por exemplo, se você for um MEMBRO do service.legal.editor grupo OSDU, poderá chamar as APIs para alterar o serviço jurídico.

Nota

Não exclua o PROPRIETÁRIO de um grupo, a menos que haja outro PROPRIETÁRIO para gerenciar os usuários.

APIs de direito

Para obter uma lista completa dos pontos de extremidade da API de Direito, consulte Serviço de direitos OSDU. Algumas ilustrações de como usar APIs de direitos estão disponíveis em Gerenciar usuários.

Nota

A documentação OSDU refere-se a pontos de extremidade v1, mas os scripts observados nesta documentação referem-se a pontos de extremidade v2, que funcionam e foram validados com êxito.

OSDU™ é uma marca comercial do The Open Group.

Próximos passos

Para a próxima etapa, consulte:

Você também pode ingerir dados em sua instância do Azure Data Manager for Energy: