Concessione di diritti condizionati

• Tipo non definito

Questo documento è destinato agli amministratori di sicurezza, ai manager funzionali e agli integratori. Presenta il principio dei diritti condizionali, la loro valutazione, l'interfaccia di gestione e la relativa facciata amministrativa.

1. Qual è lo scopo di un diritto condizionale?

Un diritto condizionato concede il permesso a un gruppo solo quando l'utente ha già un altro permesso sullo stesso oggetto sicuro.

Nella configurazione di sicurezza, questo comportamento è rappresentato da un ConditionalPermissionGrant, chiamato Servizio condizionale nell'interfaccia. Questo oggetto non contiene una lista di dispositivi: descrive una regola riutilizzabile collegando:

• Un titolo e una descrizione che spiegano lo scopo del suo business.
• un gruppo beneficiario;
• Un tipo di oggetto sicuro.
• permesso concesso;
• un permesso richiesto, che deve già essere valido sullo stesso oggetto.

La regola portata da questo oggetto è la seguente:

SI l’utilisateur appartient au groupe bénéficiaire
ET s’il possède la permission requise sur l’objet X
ALORS il reçoit la permission accordée sur ce même objet X

Immaginiamo il seguente caso in Immersive: un utente deve consultare le mappe del proprio perimetro e gestire solo i file dei dispositivi che è già autorizzato a vedere.

I suoi diritti si basano su tre famiglie di gruppi indipendenti:

• Il profilo di sicurezza Gestione della quotazione rappresenta la capacità funzionale di gestire i record delle apparecchiature;
• Il Gruppi geografici, organizzata a livello nazionale alle regioni, dipartimenti e stazioni, determina le mappe e i luoghi a cui può accedere;
• Il Gruppi di Equipaggiamento, come Illuminazione, CMV oppure Ascensore, determina le famiglie di apparecchiature su cui è stato concesso il permesso See è efficace.

Due membri del Gestione della quotazione possono quindi avere perimetri diversi: si possono vedere le apparecchiature di illuminazione di una regione, mentre un altro può vedere gli ascensori di un singolo reparto.

La domanda commerciale diventa quindi: Come dare il permesso ai membri della Gestione delle Carte Modify senza ampliare il loro ambito See ?

Un primo approccio sarebbe concedere direttamente Modify al gruppo Gestione della quotazione su tutte le famiglie di apparecchiature. Tuttavia, questo diritto sarebbe troppo ampio: tutti i gestori di file potrebbero modificare tutte le famiglie interessate, indipendentemente dal proprio perimetro di visibilità.

Vedi il documento Permessi e diritti degli oggetti sicuri

Sarebbe possibile concedere il Modify a ogni utente su ogni apparecchiatura che vedeva. Tuttavia, questa soluzione richiederebbe una manutenzione considerevole e ogni modifica dei diritti diventerebbe una potenziale fonte di errori.

Qui è dove il Servizio condizionale. Per il gruppo Gestione della quotazione, la regola recita come segue:

• se l'utente appartiene al gruppo Gestione della quotazione ;
• E se già l'ha fatto See su un apparecchiatura;
• Allora concediglielo Modify Sullo stesso equipaggiamento.

Gestione della quotazione può quindi rimanere un gruppo puramente funzionale. L'appartenenza a questo gruppo non espande, di per sé, l'equipaggiamento visibile. Diventa un percorso di autorizzazione verso Modify solo quando esiste già un diritto contingente applicabile See sull'attrezzatura testata.

Possiamo quindi creare il seguente diritto condizionale:

Elemento	Valore
Titolo	Modificare l'attrezzatura visibile ai gestori della quotazione
Descrizione	Permette ai membri della Gestione Annunci di modificare solo i dispositivi su cui See è già efficace.
Gruppo beneficiario	Gestion Fiches
Tipo di oggetto sicuro	Equipment
Permesso concesso	Modify
Permesso richiesto	See
Ambito	Lo stesso equipaggiamento

Se See è efficace su un dispositivo — tramite appartenenza diretta o indiretta a un gruppo, o tramite permesso diretto — appartenenza a Gestione della quotazione Poi rende possibile ottenere Modify sullo stesso equipaggiamento. Se See non è efficace, Modify resti rifiutati.

2. Come viene mantenuto il perimetro di visibilità?

Il diritto condizionale non si riferisce direttamente a una regione, a un dipartimento, a una stazione o a una particolare famiglia di apparecchiature. Per ogni apparecchiatura testata, la sicurezza determina prima se il permesso See è efficace per l'utente. In questo esempio, questo See risulta dall'incrocio di due dimensioni:

• Il Gruppi geografici determina dove l'utente può accedere all'apparecchiatura;
• Il Gruppi di Equipaggiamento determina quali famiglie di attrezzature a lui visibili.

Questi gruppi non sono registrati nella tassa di contingenza. Contribuiscono a monte al calcolo di See. La regola condizionale controlla quindi solo due cose sul dispositivo interessato:

• L'utente è nel gruppo funzionale Gestione della quotazione ?
• già lo ha fatto See Con questa stessa attrezzatura?

Prendiamo l'esempio di Alice:

• Alice è un membro del gruppo Gestione della quotazione ;
• la sua gerarchia geografica le conferisce l'accesso a una regione;
• I suoi gruppi di apparecchiature gli permettono di vedere le apparecchiature di illuminazione in quella regione.

Con il sovrano Gestion Fiches : Modify si See, il risultato varia per ogni pezzo di attrezzatura:

Equipaggiamento testato	Ambito geografico	Famiglia visibile	See	Modify
Illuminazione nella sua regione	Permesso	Sì	Forza lavoro	Concesso
Ascensore nella sua zona	Permesso	No	Assente	Rifiutato
Illuminazione fuori dalla tua regione	Fuori dal campo di applicazione	Sì	Assente	Rifiutato

In tutti e tre i casi, Alice appartiene ancora a Gestione della quotazione. È la presenza o l'assenza di See sull'apparecchiatura sotto test che determina se Modify è concesso. Un altro membro del Gestione della quotazione può quindi ottenere un risultato diverso a seconda dei propri gruppi geografici e delle proprie famiglie di apparecchiature visibili.

3. Come viene valutato un permesso?

Per un utente abituale, la valutazione segue questo ordine:

1. richiedere un rifiuto esplicito del permesso richiesto;
2. Se si applica un rifiuto, nega l'accesso;
3. altrimenti, richiedere un'autorizzazione diretta;
4. Se non si applica alcuna autorizzazione diretta, si esaminano i diritti condizionali attivi;
5. permettere se almeno una regola applicabile soddisfa la sua condizione;
6. altrimenti, nega l'accesso.

Perché una regola condizionale si applichi, devono essere soddisfatte tutte le seguenti condizioni:

• la regola è attiva;
• Il tipo dell'oggetto corrisponde al tipo configurato nella regola.
• il permesso richiesto corrisponde al permesso concesso;
• L'utente appartiene al gruppo beneficiario, direttamente o tramite gruppi annidati.
• Il permesso richiesto è valido sullo stesso oggetto.

Più regole possono concedere lo stesso permesso. Funzionano come alternative: tutto ciò che serve è che una regola applicabile abbia successo. Una regola può esprimere un solo permesso richiesto. Le dipendenze possono essere concatenate. Ad esempio, un permesso può dipendere da Modify, che a sua volta dipende da See. Cicli come Modify si See e See si Modify sono proibiti.

4. Ambito delle regole

Una regola è definita per un Tipo di oggetto sicuro, ma la sua condizione viene valutata su un Scopo preciso di questo tipo.

Se l'utente ha See Sull'attrezzatura 125, la regola può concederlo Modify sull'attrezzatura 125. Il fatto di possedere See sull'equipaggiamento 126 non concede nulla sull'equipaggiamento 125.

La versione attuale supporta solo l'ambito Stesso scopo :

• Il permesso concesso e il permesso richiesto appartengono allo stesso tipo di sicurezza.
• vengono valutati con lo stesso identificatore di oggetto;
• Un permesso posseduto su una stazione, dipartimento o altra attrezzatura non soddisfa la condizione relativa all'oggetto testato.

5. Modello di Dati Concettuale

ConditionalPermissionGrant è l'oggetto che rappresenta una legge condizionale. Ogni occorrenza risponde alla seguente domanda:

Per i membri di quale gruppo, su quale tipo di oggetto, quale permesso dovrebbe essere concesso se quale altro permesso è già in vigore sullo stesso oggetto?

La regola non contiene un ID utente o un ID dispositivo. Descrive una relazione riutilizzabile tra oggetti di sicurezza; il risultato viene poi calcolato per l'utente e l'oggetto al momento del controllo degli accessi.

5.1 Oggetti correlati e cardinalità

Ogni diritto condizionale è correlato esattamente:

• a Group, che designa il gruppo beneficiario;
• a SecurizedObjectTypeDefinition, che designa il tipo di oggetto in questione;
• a Permission nel ruolo concesso ;
• a Permission nel ruolo Richiesto.

Al contrario, ciascuno di questi oggetti può essere utilizzato da zero, uno o più diritti condizionali.

Oggetto di sicurezza	Ruolo nel diritto condizionale	Cardinalità per una regola
Group	Gruppo i cui membri possono beneficiare della regola.	Esattamente uno
SecurizedObjectTypeDefinition	Il tipo di oggetti su cui viene valutata la regola.	Esattamente uno
Permission — Ruolo conferito	Permesso ottenuto quando la condizione è soddisfatta.	Esattamente uno
Permission — ruolo richiesto	Permesso che deve essere già in vigore sullo stesso oggetto.	Esattamente uno

5.2 Dati trasportati dalla regola

Dati	Significato
Identifier	Identificatore tecnico unico del diritto condizionale.
Title	Un titolo obbligatorio, limitato a 255 caratteri, che riassume l'intento commerciale.
Description	Una spiegazione opzionale, limitata a 2.048 caratteri, che fornisce un contesto utile agli amministratori.
BeneficiaryGroupIdentifier	Riferimento del gruppo beneficiario. L'appartenenza diretta o indiretta dell'utente a questo gruppo viene verificata durante la valutazione.
SecuredObjectTypeIdentifier	Riferimento del tipo di oggetto sicuro, ad esempio Equipment.
GrantedPermissionIdentifier	Riferimento al permesso che la regola può generare, ad esempio Modify.
RequiredPermissionIdentifier	Riferimento al permesso che deve già essere in vigore sullo stesso oggetto, ad esempio See.
IsEnabled	Stato attivo o inattivo. Solo le regole attive partecipano alla valutazione.
RowVersion	La versione utilizzata per rilevare un cambiamento concorrente e impedire a un amministratore di sovrascrivere silenziosamente un'azione più recente.

Il titolo e la descrizione sono utilizzati solo per identificare e spiegare la regola nell'interfaccia di amministrazione. Non partecipano al calcolo del diritto. IsEnabled, tuttavia, determina se la regola può essere utilizzata.

5.3 Regole di Integrità

La configurazione protegge le seguenti regole:

• Il gruppo, il tipo sicuro e entrambi i permessi sono necessari e devono esistere.
• Il tipo secure deve essere attivo quando si crea una regola.
• I permessi concessi e richiesti devono essere diversi e appartengono entrambi al tipo selezionato.
• La stessa combinazione Gruppo + Tipo + Permesso concesso + Permesso richiesto Può essere salvato solo una volta, anche se la regola esistente è inattiva.
• La creazione o la riattivazione di una regola è negata se introduce un ciclo di dipendenze tra i permessi.
• Cancellare un gruppo, un tipo o un permesso che è ancora citato da una regola viene bloccato.
• Quando avviene un cambiamento o una cancellazione di stato, la versione nota della regola può rilevare un cambiamento concorrente.

Quindi, una singola regola Gestion Fiches : Modify si See può essere applicato a tutte le attrezzature presenti e future. Tuttavia, non produce Modify che per l'equipaggiamento su cui See viene effettivamente ottenuto dall'utente.

6. Interfaccia di gestione

La pagina è accessibile da Sicurezza, allora Diritti condizionati. Da allora esiste anche l'accesso Configurazione dei diritti con l'azione Amministrazione dei diritti condizionati.

Nell'interfaccia attuale, questa pagina è dedicata solo all'account Cervello.

6.1 Scelta del tipo di oggetto

Il tipo Oggetto Sicuro è presentato come un link cliccabile.

1. clicca sul tipo visualizzato;
2. Scegli un tipo nella finestra di selezione.
3. la finestra si chiude automaticamente;
4. La pagina ricarica le regole del tipo scelto.

La finestra offre solo i tipi configurati in sicurezza.

6.2 Lettura delle regole esistenti

Per il tipo selezionato, la tabella mostra:

Colonna	Indice
Stato	Actif oppure Inactif.
Gruppo beneficiario	Il nome del gruppo e, quando disponibile, il suo Nome Distinto.
Permesso concesso	Permesso fornito dalla regola.
Condizione sullo stesso oggetto	Permesso che l'utente deve già avere.
Azioni	Abilita, disabilita o elimina la regola.

Le regole attive vengono visualizzate prima delle regole inattive.

6.3 Aggiunta di una regola

Come posso aggiungere una regola?

1. Seleziona il tipo di oggetto sicuro.
2. in Nuovo diritto condizionale, clicca su Scegli un gruppo ;
3. Seleziona il gruppo beneficiario nella finestra che mostra solo i gruppi.
4. scegliere il permesso concesso;
5. scegliere un altro permesso richiesto;
6. clicca su Aggiungi al carrello ;
7. Controlla il messaggio di conferma e la nuova linea attiva.

Il pulsante aggiungi diventa disponibile dopo aver scelto il gruppo, purché il tipo sia attivo e abbia almeno due permessi.

6.4 Disabilita, Riattiva o Elimina

Disabilitazione Rimuove immediatamente il contributo condizionato senza chiarire la definizione. Questa azione è adatta per un test o una sospensione temporanea.

Attiva Restituisce la regola al servizio dopo un nuovo controllo dei cicli di dipendenza.

Elimina Elimina la definizione dopo la conferma. Per ripristinarla, deve essere ricreata.

Se un altro amministratore ha modificato la regola tra il momento in cui è stata visualizzata e l'azione richiesta, la registrazione viene negata. La pagina deve quindi essere ricaricata prima di ricominciare.

7. Facciata amministrativa e API di sicurezza

L'interfaccia di gestione dell'Enhancer non modifica mai direttamente i dati di sicurezza. Le sue azioni attraversano una facciata amministrativa comune che costituisce il confine tra l'interfaccia e il dominio di sicurezza. Gli stessi ordini aziendali sono ora disponibili per le integrazioni tramite l'HTTP Web API di SecurityController. Che un ordine provenga dall'Enhancer o dall'API, viene trasmesso alla stessa facciata e quindi beneficia delle stesse validazioni.

7.1 Ordini di gestione disponibili

Funzionamento	Route HTTP	Informazioni attese	Risultato
Consulta	GET /api/Security/ConditionalPermissionGrants	Filtro opzionale securedObjectTypeIdentifier.	Un elenco di tutte le regole corrispondenti, attive o inattive, con i loro ID e versioni.
Crea	POST /api/Security/ConditionalPermissionGrants	Titolo, descrizione opzionale, gruppo, tipo di sicurezza, permesso concesso e permesso richiesto.	Crea una regola attiva e restituisci la versione.
Cambia stato	PATCH /api/Security/ConditionalPermissionGrants/{identifier}/Enabled	Il nuovo stato e la versione nota della regola.	Attivare o disattivare e restituire la nuova versione.
Elimina	DELETE /api/Security/ConditionalPermissionGrants/{identifier}	Versione nota della regola.	Cancellazione della regola.

Il RowVersion è rappresentato in Base64 negli exchange JSON. Dopo uno stato nuovo o modificato, il chiamante deve mantenere il nuovo valore restituito per la prossima operazione sulla regola.

Non esiste un ordine per modificare una definizione esistente a livello globale. Per cambiare gruppo, tipo o uno dei permessi, devi creare la nuova regola, validarla e poi disattivare o cancellare quella vecchia.

7.2 Controlli della facciata

La facciata applica sistematicamente le seguenti protezioni:

• l'autore è determinato dal contesto autenticato;
• Solo Cerebrate e gli amministratori root della piattaforma possono modificare questa configurazione.
• il gruppo e il tipo devono esistere;
• Il tipo deve essere attivo al momento della creazione.
• Entrambi i permessi devono esistere, essere distinti e appartenere al tipo scelto.
• i duplicati e i cicli sono rifiutati;
• ogni modifica viene registrata in una transazione atomica;
• Una versione diventata obsoleta porta a una risposta 409 Conflict invece di sovrascrivere un cambiamento più recente;
• Dopo la validazione, il dominio di sicurezza viene ricaricato e la modifica viene segnalata ad altre istanze.
• La fonte dell'operazione e l'autore sono scritti nei log del server.

8. Effetto dei cambiamenti

Cambiamento	Effetto atteso
Creare una regola	La regola diventa attiva per gli oggetti esistenti e futuri non appena il dominio di sicurezza viene aggiornato.
Aggiungere un utente al gruppo beneficiario	L'utente può beneficiare della regola secondo i permessi richiesti.
Ritiro dal gruppo beneficiario	L'utente non beneficia più della regola di questo percorso di appartenenza.
Aggiungere o rimuovere il permesso richiesto su un oggetto	Il permesso condizionato appare o scompare per lo stesso oggetto.
Disattivazione	La definizione rimane visibile ma non partecipa più alle decisioni.
Riattivazione	La regola partecipa nuovamente alle decisioni dopo la validazione.
Cancellazione	La regola scompare; i diritti diretti rimangono invariati.

9. Limiti attuali

Il meccanismo attuale non permette:

• Scegli un singolo utente come beneficiario.
• Richiedere più permessi contemporaneamente in una singola regola.
• Usa il permesso di un altro oggetto come condizione.
• collegare due tipi diversi di oggetti nella stessa regola;
• ignorare un rifiuto esplicito;
• creare una dipendenza ciclica;
• espone direttamente la gestione tramite una via web API pubblica dedicata.

Per esprimere, ad esempio, due condizioni obbligatorie See e Approve, il modello deve essere modificato. Due regole separate significherebbero attualmente See oppure Approve.

10. Risoluzione dei problemi

Sintomo	Audit
Un membro del CP vede l'attrezzatura ma non può modificarla	Verifica che la regola sia attiva, che il suo tipo e i permessi siano corretti, che l'utente appartenga a CP e che non ci siano rifiuti Modify non si applica.
Un membro del CP può modificare troppa attrezzatura	Cerca un destro diretto Modify troppo ampio, e poi controllare l'origine dei suoi diritti See.
Il gruppo atteso non compare nella selezione	Verifica che l'oggetto esista come gruppo nel dominio di sicurezza e ricarica la pagina.
Il pulsante Aggiungi rimane non disponibile	Controlla la scelta del gruppo, lo stato attivo del tipo e la presenza di almeno due permessi.
L'aggiunta viene rifiutata	Verifica che i permessi siano distinti, che appartengano al tipo scelto, che la regola non esista già e che non crei un ciclo.
Un'azione viene respinta dopo una vecchia opinione	Pagina di ricarica: Un altro cambiamento probabilmente ha cambiato la versione della regola.
La disattivazione sembra non avere alcun effetto	Controlla se un diritto diretto o un'altra regola condizionata concede ancora il permesso.

11. Lista di controllo per la commissione

• Il tipo di sicurezza pertinente è attivo.
• I permessi concessi e necessari appartengono a questo tipo.
• Il gruppo destinatario corrisponde al profilo funzionale atteso.
• Il permesso richiesto rappresenta correttamente l'ambito da mantenere.
• La regola non duplica una regola esistente.
• Non viene introdotto alcun ciclo di dipendenze.
• Sono stati identificati diritti diretti troppo ampi.
• I rifiuti espliciti sono stati controllati.
• I gruppi annidati sono stati controllati.
• Il tester dei diritti conferma il risultato su un oggetto visibile e su un oggetto non visibile.
• La regola è stata validata con un vero utente CP o Master Records.