Utente di sistema
L'utente di sistema è un oggetto di sistema in ThingWorx progettato allo scopo di semplificare la gestione dei permessi per i servizi interni, consentendo al contempo al livello dell'API esterno di ottenere i permessi utente per utente. L'utente di sistema è facoltativo. Se l'utente di sistema non viene assegnato a un servizio, ThingWorx controlla i permessi dell'utente che ha creato la richiesta originale per tutti i servizi di wrapping successivi.
In genere, quando un utente richiama un servizio, tale utente deve disporre del permesso per il servizio chiamato nonché i permessi per eventuali altri servizi chiamati dal servizio chiamato inizialmente. Ad esempio, un utente esegue un servizio denominato GetMachineRunTimeHistory su un oggetto che chiama internamente QueryStreamEntriesWithData e GetDataTableEntryByKey. Senza l'utente di sistema, all'utente che ha chiamato GetMachineRunTimeHistory occorrono anche i permessi espliciti per eseguire QueryStreamEntriesWithData e GetDataTableEntryByKey.
Con l'utente di sistema, se un servizio personalizzato viene chiamato da un servizio o da una sottoscrizione (una chiamata del servizio di wrapping) e all'utente di sistema è consentito eseguire il servizio, l'esecuzione del servizio sarà autorizzata indipendentemente dall'utente che ha inizialmente attivato la serie di eventi, script o servizi. Tuttavia, l'utente non potrà richiamare direttamente il servizio di wrapping (dell'esempio precedente, QueryStreamEntriesWithData o GetDataTableEntryByKey a meno che l'utente non disponga di premesso esplicito).
Questa pratica consente a un amministratore di bloccare le API di superficie accessibili dall'esterno mediante utenti e gruppi con abilitazione di accesso esplicita. Sebbene sia sempre consigliabile dipendere dalla propagazione dell'utente per il wrapping delle chiamate di servizio, l'utente di sistema può facilitare la gestione delle chiamate interne ai servizi dal punto di vista della gestione dei permessi.
L'utente di sistema può essere aggiunto al gruppo di amministratori. In questo modo, a tutti gli utenti è concesso il permesso completo su tutto ciò che è annidato all'interno di una chiamata di servizio; tutti i servizi richiamati all'interno di un servizio personalizzato hanno esito positivo, indipendentemente dai permessi dell'utente che esegue il richiamo.
L'utente di sistema non espande la visibilità di un utente durante l'interrogazione di oggetti. Non può essere utilizzato per recuperare oggetti che un utente non può visualizzare in quanto non dispone del permesso di visibilità. L'esempio riportato di seguito, illustra questa situazione:
1. Sono presenti cinque oggetti, T1, T2, T3, T4, T5, che ereditano il modello di oggetto Template1 e due utenti, User1 e User2.
2. User1 dispone del permesso di visibilità per T1 e T2, mentre User2 dispone del permesso di visibilità per T4 e T5.
3. All'utente di sistema viene concesso il permesso di esecuzione del servizio per QueryImplementingThings per Template1 e viene creato un servizio personalizzato denominato CallQueryImplementingThings, che chiama QueryImplementingThings internamente e fornisce il permesso di esecuzione del servizio a User1 e User2 per il servizio CallQueryImplementingThings.
4. Quando User1 esegue il servizio CallQueryImplementingThings, visualizza T1 e T2 nel risultato.
5. Quando User2 esegue il servizio CallQueryImplementingThings, visualizza T4 e T5 nel risultato.
 |
Non è consigliabile utilizzare l'utente di sistema per ignorare la protezione o per ridurre la necessità di un'attenta progettazione e implementazione di un'applicazione sicura. Le best practice prevedono che si debba limitare il ricorso all'utente di sistema ai casi di utilizzo specifici e non adottarlo come soluzione temporanea generica alle pratiche di propagazione dell'utente.
|
Esempio di utente di sistema
La concessione del permesso utente di sistema per l'esecuzione di un servizio implica che a ogni utente verrà concesso il permesso di eseguire tale servizio da un servizio personalizzato, ma non necessariamente di chiamare direttamente tale servizio. Per usarlo correttamente, attenersi alle indicazioni riportate di seguito.
1. Concedere al sistema il permesso utente per eseguire un servizio, ma limitare i permessi in modo che altri utenti non dispongano del permesso di eseguire tale servizio.
2. Scrivere un servizio personalizzato che chiama il servizio limitato, quindi concedere agli utenti il permesso di eseguire il servizio personalizzato ma non quello con restrizioni.
3. Gli utenti saranno in grado di eseguire tale servizio personalizzato, anche se non dispongono del permesso di eseguire il servizio con restrizioni.
Per illustrare ulteriormente questo concetto utilizzando un esempio, considerare il caso d'uso riportato di seguito.
Si desidera scrivere un servizio personalizzato in cui agli utenti viene mostrato lo stato di un particolare dispositivo connesso, denominato CustomService1. Per fare ciò, CustomService1 potrebbe usare il servizio SearchDevices sulla risorsa DeviceFunctions per esaminare tutti i dispositivi sulla piattaforma, quindi filtrare i risultati per restituire solo il dispositivo specifico.
Tuttavia, i permessi vengono controllati non solo per CustomService1, ma per ogni chiamata di servizio effettuata all'interno di CustomService1. L'utente dovrebbe avere il permesso di eseguire il servizio SearchDevices per chiamare CustomService1, in caso contrario la chiamata a CustomService1 non riesce. Assegnare all'utente il permesso di chiamare SearchDevices non è l'ideale perché potrebbe non essere opportuno che l'utente abbia accesso allo stato di ogni dispositivo, ma solo a quello del dispositivo specifico in questione.
L'utente del sistema può risolvere questo problema. Quando un servizio viene eseguito direttamente, viene verificato se l'utente dispone del permesso necessario. Questo è vero per qualsiasi servizio, inclusi tutti i servizi personalizzati. Tuttavia, quando un servizio viene eseguito all'interno di un servizio personalizzato, di fatto vengono verificati due permessi: quello dell'utente e quello dell'utente di sistema. Se l'utente o l'utente di sistema dispongono del permesso per eseguire il servizio all'interno del servizio personalizzato, il servizio interno viene eseguito come se l'utente avesse il permesso per eseguirlo. Dal momento che SearchDevices viene chiamato solo all'interno di CustomService1 e non direttamente, è possibile concedere all'utente di sistema il permesso di eseguire SearchDevices. Quando l'utente chiama CustomService1, si verifica il controllo di permessi e si rileva che User1 non ha il permesso, ma che invece l'utente di sistema lo ha. Di conseguenza, SearchDevices verrà eseguito come se l'utente avesse il permesso. Se l'utente tenta di chiamare SearchDevices direttamente e non dall'interno di CustomService1, il permesso dell'utente di sistema non è valido e verrà negato all'utente.
