Mantello (COM)

Il mantello è una funzionalità di sicurezza COM che determina l'identità dei progetti client verso il server durante la rappresentazione. Quando si imposta il mantello, il server intermedio maschera la propria identità e presenta l'identità del client al server che chiama per conto del client. Fondamentalmente; l'identità client visualizzata dal server è l'identità associata al proxy. L'identità del proxy è determinata da diversi fattori, uno dei quali è il tipo di mantello impostato (se presente). Il mantello non è supportato dal provider di sicurezza Schannel.

Gli argomenti seguenti forniscono altre informazioni sul mantello:

Tipi di mantello

Esistono due tipi di mantello: mantello statico e mantello dinamico :

  • Con il mantello statico (EOAC_STATIC_CLOAKING), il server vede il token di thread dalla prima chiamata da un client al server. Per la prima chiamata, se l'identità proxy è stata precedentemente impostata durante una chiamata a CoSetProxyBlanket, viene usata tale identità proxy. Tuttavia, se l'identità proxy non è stata impostata in precedenza, viene usato il token del thread. Se non è presente alcun token di thread, viene usato il token di processo. Per tutte le chiamate future, viene usata l'identità impostata nella prima chiamata.
  • Con il mantello dinamico (EOAC_DYNAMIC_CLOAKING), in ogni chiamata viene usato il token del thread corrente (se è presente un token di thread) per determinare l'identità del client. Se non è presente alcun token di thread, viene usato il token di processo. Ciò significa che i server chiamati per conto del client durante la rappresentazione vedono l'identità del client COM che ha originato la chiamata, che è in genere il comportamento desiderato. Naturalmente, affinché la rappresentazione abbia esito positivo, il client deve avere concesso all'autorità del server di rappresentare impostando un livello di rappresentazione appropriato. Per altre informazioni, vedere Livelli di rappresentazione. Questo tipo di mantello è costoso.

Impatto del mantello sull'identità client

Quando viene effettuata una chiamata crittografata e il server chiede al client la relativa identità, in genere ottiene l'identità associata al proxy. A volte il servizio di autenticazione esegue una conversione dall'identità reale, ma in genere l'identità proxy è l'identità che il server vede. Il proxy presenta un'identità al server che dipende dal tipo di mascheramento impostato e da altri fattori.

Per riepilogare, l'identità del client è una funzione del flag di mascheramento impostato, il token di processo, la presenza o l'assenza di un token di thread e se l'identità proxy è stata impostata in precedenza. La tabella seguente mostra l'identità proxy risultante (identità client) quando questi fattori variano.

Flag di mantello Presenza del token di thread Identità proxy impostata in precedenza Identità proxy (identità client)
Mantello non impostato
Don't care
Don't care
Elaborare l'identità del token o dell'autenticazione
EOAC_STATIC_CLOAKING
Presentazione
No
Token del thread
EOAC_STATIC_CLOAKING
Presentazione

Identità proxy corrente
EOAC_STATIC_CLOAKING
Non presente
No
Token di processo
EOAC_STATIC_CLOAKING
Non presente

Identità proxy corrente
EOAC_DYNAMIC_CLOAKING
Presentazione
Don't care
Token del thread
EOAC_DYNAMIC_CLOAKING
Non presente
Non importa
Token di processo

Il diagramma di flusso seguente illustra come viene determinata l'identità proxy in situazioni diverse.

Diagram that shows the flow for determining the proxy identity.

Impostazione del mantello

Il mantello viene impostato come flag di funzionalità in una chiamata a CoInitializeSecurity, che imposta il mantello per l'intero processo. La funzionalità di mantello viene quindi impostata fino a quando il client non lo modifica tramite una chiamata a IClientSecurity::SetBlanket (o a CoSetProxyBlanket), che imposta il mantello per il proxy.

Per impostazione predefinita, il mantello non è impostato. Per impostarlo, passare EOAC_STATIC_CLOAKING o EOAC_DYNAMIC_CLOAKING al parametro pCapabilities in CoInitializeSecurity o SetBlanket.

Quando il mantello statico è abilitato tramite CoInitializeSecurity, ogni proxy preleva un token (thread o processo) la prima volta che si effettua una chiamata sul proxy. Quando il mantello statico è abilitato tramite SetBlanket, il proxy preleva il token nel thread in quel momento. Se non è disponibile alcun token di thread quando viene chiamato SetBlanket , il token di processo viene usato per l'identità del proxy. In pratica, SetBlanket corregge l'identità del proxy.

Con il mantello dinamico, l'identità del proxy viene determinata allo stesso modo indipendentemente dal fatto che il mantello dinamico sia impostato usando CoInitializeSecurity o con SetBlanket. Il token del thread corrente viene usato se presente; in caso contrario, viene usato il token di processo.

Se il mantello è impostato per l'intero processo tramite una chiamata a CoInitializeSecurity e si desidera effettuare chiamate con il token di processo, non rappresentare durante l'esecuzione di chiamate.

Livelli di rappresentazione e mantello

Come accennato in precedenza, la funzionalità di mascheramento determina l'identità presentata a un server durante la rappresentazione. Il mantello consente a un server di proiettare un'identità diversa da quella di un altro server che sta chiamando per conto del client. Il livello di rappresentazione indica la quantità di autorità che il client ha assegnato al server.

La rappresentazione senza mantello funziona, ma potrebbe non essere la scelta migliore perché, in alcuni casi, il server finale deve conoscere l'identità del chiamante iniziale. Ciò non può essere ottenuto senza usare il mantello perché è difficile garantire che solo i client autorizzati possano accedere a un computer remoto. Quando la rappresentazione viene usata senza mascheramento, l'identità presentata a un server downstream è quella del processo chiamante immediato.

Tuttavia, il mantello non è utile senza rappresentazione. Il mantello ha senso solo quando il client ha impostato un livello di rappresentazione di rappresentazione o delegato. Con livelli di rappresentazione inferiori, il server non può effettuare chiamate mascherate. L'esito positivo del mascheramento dipende dal numero di limiti del computer superati e dal livello di rappresentazione, che indica la quantità di autorità che il server deve agire per conto del client.

In alcune situazioni, è opportuno che il server imposti il mantello quando il client imposta il livello di rappresentazione su RPC_C_IMP_LEVEL_IMPERSONATE. Tuttavia, alcune limitazioni sono effettive. Se il client originale imposta il livello di rappresentazione su RPC_C_IMP_LEVEL_IMPERSONATE, il server intermedio (che funge da client nello stesso computer) può mascherarsi su un solo limite del computer. Ciò è dovuto al fatto che un token di rappresentazione a livello di rappresentazione può essere passato attraverso un solo limite del computer. Dopo aver superato il limite del computer, è possibile accedere solo alle risorse locali. L'identità presentata al server dipende dal tipo di mascheramento impostato. Se non viene impostato alcun mantello, l'identità presentata a un server sarà quella del processo che effettua la chiamata immediata.

Per nascondere più limiti del computer, è necessario specificare sia un flag di funzionalità di mantello appropriato che una rappresentazione a livello di delegato. Con questo tipo di rappresentazione, sia le credenziali di rete locali che di rete del client vengono fornite al server, quindi il token di rappresentazione può superare qualsiasi numero di limiti del computer. Anche in questo caso, l'identità presentata al server dipende dal tipo di mantello impostato. Se non viene impostato alcun mantello con rappresentazione a livello di delegato, l'identità presentata a un server è quella del processo che effettua la chiamata.

Si supponga, ad esempio, che l'elaborazione A chiami B e B abbia impostato il mantello E A abbia impostato il livello di rappresentazione su rappresentazione. Se A, B e C si trovano nello stesso computer, passando il token di rappresentazione da A a B e quindi a C funzionerà. Ma se A e C si trovano nello stesso computer e B non lo è, il passaggio del token funzionerà tra A e B, ma non da B a C. La chiamata da B a C avrà esito negativo perché B non può chiamare C durante il mantello. Tuttavia, se A imposta il livello di rappresentazione su delegato, il token può essere passato da B a C e la chiamata potrebbe avere esito positivo.

Scenari di mantello

Nella figura seguente il processo A chiama B, chiama C, chiama D quando il mantello non è impostato. Di conseguenza, ogni processo intermedio vede l'identità del processo che lo ha chiamato.

Diagram that shows the process when cloaking is not set.

Con il mantello statico, il server vede l'identità proxy impostata durante la prima chiamata dal client al server. La figura seguente mostra un esempio dell'identità proxy impostata durante una chiamata da B a C. In una chiamata successiva, il processo D vede l'identità di B quando il mantello statico viene impostato da B e C.

Diagram that shows the process for static cloaking.

Con il mantello dinamico, l'identità del chiamante durante la rappresentazione si basa sul token del thread corrente, se presente. La figura seguente mostra la situazione in cui B e C impostano il mantello dinamico e D vedono l'identità di A, nonostante una chiamata precedente da B a C.

Diagram that shows the process for dynamic cloaking.

Delega e rappresentazione