Servizio entitlement
La gestione degli accessi è una funzione fondamentale per qualsiasi servizio o risorsa. Il servizio entitlement consente di controllare chi può usare Azure Data Manager per l'istanza di Energy, cosa possono visualizzare o modificare e quali servizi o dati possono usare.
Struttura e denominazione dei gruppi OSDU
Il servizio entitlement di Azure Data Manager for Energy consente di creare gruppi e gestire le appartenenze dei gruppi. Un gruppo entitlement definisce le autorizzazioni per servizi o origini dati per una partizione di dati specifica in Azure Data Manager per l'istanza di Energy. Gli utenti aggiunti a un gruppo specifico ottengono le autorizzazioni associate. Tutti gli identificatori di gruppo (messaggi di posta elettronica) sono del formato {groupType}.{serviceName|resourceName}.{permission}@{partition}.{domain}
.
È necessario impostare gruppi diversi e diritti utente associati per ogni nuova partizione di dati, anche nella stessa istanza di Azure Data Manager per l'energia.
Tipi di gruppi OSDU
Il servizio entitlement abilita tre casi d'uso per l'autorizzazione:
Gruppi di dati
- I gruppi di dati vengono usati per abilitare l'autorizzazione per i dati.
- I gruppi di dati iniziano con la parola "dati", ad esempio
data.welldb.viewers
edata.welldb.owners
. - I singoli utenti vengono aggiunti ai gruppi di dati, che vengono aggiunti nell'ACL dei singoli record di dati per abilitare
viewer
eowner
accedere ai dati dopo il caricamento dei dati nel sistema. - Per
upload
i dati, è necessario avere diritti di vari servizi OSDU, che vengono usati durante il processo di inserimento. La combinazione di servizi OSDU dipende dal metodo di inserimento. Ad esempio, per l'inserimento di manifesti, vedere Concetti di inserimento basati su manifesto per comprendere i servizi OSDU usati dalle API. L'utente non deve far parte dell'ACL per caricare i dati.
Gruppi di servizi
- I gruppi di servizi vengono usati per abilitare l'autorizzazione per i servizi.
- I gruppi di servizi iniziano con la parola "service", ad esempio
service.storage.user
eservice.storage.admin
. - I gruppi di servizi sono predefiniti quando viene effettuato il provisioning dei servizi OSDU in ogni partizione di dati dell'istanza di Azure Data Manager per l'energia.
- Questi gruppi abilitano
viewer
,editor
eadmin
l'accesso per chiamare le API OSDU corrispondenti ai servizi OSDU.
Gruppi utenti
- I gruppi di utenti vengono usati per il raggruppamento gerarchico di gruppi di utenti e servizi.
- I gruppi di servizi iniziano con la parola "users", ad esempio
users.datalake.viewers
eusers.datalake.editors
.
Gerarchia annidata
Se user_1 fa parte di un data_group_1 e data_group_1 viene aggiunto come membro al user_group_1, il codice OSDU verifica la presenza dell'appartenenza annidata e autorizza user_1 ad accedere ai diritti per user_group_1. Questo è illustrato in OSDU Entitlement Check API e OSDU Retrieve Group API.This is explained in OSDU Entitlement Check API and OSDU Retrieve Group API.
È possibile aggiungere singoli utenti a un oggetto
user group
. L'oggettouser group
viene quindi aggiunto a un oggettodata group
. Il gruppo di dati viene aggiunto all'ACL del record di dati. Abilita l'astrazione per i gruppi di dati perché i singoli utenti non devono essere aggiunti uno alla sola al gruppo di dati. È invece possibile aggiungere utenti auser group
. È quindi possibile usare ripetutamenteuser group
per piùdata groups
. La struttura annidata consente di garantire la scalabilità per gestire le appartenenze in OSDU.
Gruppi predefiniti
- Alcuni gruppi OSDU vengono creati per impostazione predefinita quando viene effettuato il provisioning di una partizione di dati.
- I gruppi di dati di
data.default.viewers
edata.default.owners
vengono creati per impostazione predefinita. - I gruppi di servizi per visualizzare, modificare e gestire ogni servizio,
service.entitlement.admin
ad esempio eservice.legal.editor
vengono creati per impostazione predefinita. - I gruppi di utenti ,
users
users.datalake.viewers
,users.datalake.editors
,users.datalake.admins
,users.datalake.ops
eusers.data.root
vengono creati per impostazione predefinita. - Il grafico dei membri e dei gruppi predefiniti nei gruppi entitlement OSDU con bootstrapped mostra i gruppi di intestazioni di colonna come membro delle intestazioni di riga. Ad esempio,
users
il gruppo è membro didata.default.viewers
edata.default.owners
per impostazione predefinita.users.datalake.admins
eusers.datalake.ops
sono membri delservice.entitlement.admin
gruppo. - Entità servizio o o
client-id
èapp-id
il proprietario predefinito di tutti i gruppi.
Peculiarità del users@
gruppo
- Esiste un'eccezione di questa regola di denominazione del gruppo per il gruppo "users". Viene creato quando viene effettuato il provisioning di una nuova partizione di dati e il relativo nome segue il modello di
users@{partition}.{domain}
. - Include l'elenco di tutti gli utenti con qualsiasi tipo di accesso in una partizione di dati specifica. Prima di aggiungere un nuovo utente a tutti i gruppi entitlement, è necessario aggiungere anche il nuovo utente al
users@{partition}.{domain}
gruppo.
Peculiarità del users.data.root@
gruppo
- users.data.root entitlement group è il membro predefinito di tutti i gruppi di dati quando vengono creati i gruppi. Se si tenta di rimuovere users.data.root da qualsiasi gruppo di dati, viene visualizzato un errore perché questa appartenenza viene applicata da OSDU.
- users.data.root diventa automaticamente il proprietario predefinito e permanente di tutti i record di dati quando i record vengono creati nel sistema, come illustrato in OSDU convalidare l'API di accesso proprietario e l'API di controllo radice dei dati degli utenti OSDU. Di conseguenza, insieme alla verifica dell'appartenenza osDU dell'utente, il sistema controlla anche se l'utente è "DataManager", ovvero parte del gruppo data.root, per valutare l'accesso del record di dati.
- L'appartenenza predefinita a users.data.root è solo l'oggetto
app-id
usato per configurare l'istanza. È possibile aggiungere altri utenti in modo esplicito a questo gruppo per concedere loro l'accesso predefinito dei record di dati.
Come esempio nello scenario,
- Un data_record_1 ha 2 elenchi di controllo di accesso: ACL_1 e ACL_2.
- User_1 è membro di ACL_1 e users.data.root.
Ora, se si rimuove user_1 da ACL_1, user_1 rimane l'accesso al data_record_1 tramite il gruppo users.data.root.
Se ACL_1 e ACL_2 vengono rimossi da data_record_1, users.data.root continua ad avere accesso proprietario dei dati. In questo modo il record dei dati non diventa sempre orfano.
OID sconosciuto
Verrà visualizzato un OID sconosciuto in tutti i gruppi OSDU aggiunti per impostazione predefinita, questo OID fa riferimento a un GUID interno di Azure Data Manager per l'energia usato per la comunicazione interna da sistema a sistema. Questo GUID viene creato in modo univoco per ogni istanza e viene applicato dal sistema per non essere eliminato o rimosso dall'utente.
Utenti
Per ogni gruppo OSDU, è possibile aggiungere un utente come PROPRIETARIO o membro:
- Se si è proprietari di un gruppo OSDU, è possibile aggiungere o rimuovere i membri di tale gruppo o eliminare il gruppo.
- Se si è membri di un gruppo OSDU, è possibile visualizzare, modificare o eliminare il servizio o i dati a seconda dell'ambito del gruppo OSDU. Ad esempio, se si è membri del
service.legal.editor
gruppo OSDU, è possibile chiamare le API per modificare il servizio legale.
Nota
Non eliminare il PROPRIETARIO di un gruppo, a meno che non esista un altro PROPRIETARIO per gestire gli utenti.
API entitlement
Per un elenco completo degli endpoint DELL'API Entitlement, vedere Servizio entitlement OSDU. Alcune illustrazioni su come usare le API Entitlement sono disponibili in Gestire gli utenti.
Nota
La documentazione osDU si riferisce agli endpoint v1, ma gli script annotati in questa documentazione fanno riferimento agli endpoint v2, che funzionano e sono stati convalidati correttamente.
OSDU® è un marchio di The Open Group.
Passaggi successivi
Per il passaggio successivo, vedere:
È anche possibile inserire dati nell'istanza di Azure Data Manager per l'energia: