RPC (Qualidade de Serviço)
Os programas cliente podem usar a função RpcBindingSetAuthInfoEx em vez da função RpcBindingSetAuthInfo para criar uma associação autenticada. Se o fizerem, passarão um ponteiro para uma estrutura RPC_SECURITY_QOS como o parâmetro final de RpcBindingSetAuthInfoEx. Essa estrutura contém informações sobre a qualidade do serviço. Os programas cliente também podem especificar o acompanhamento de identidade e selecionar o tipo de representação.
Use o membro Capabilities da estrutura RPC_SECURITY_QOS para definir quais partes do aplicativo cliente/servidor são autenticadas. Se RPC_C_QOS_CAPABILITIES_DEFAULT for selecionado, a biblioteca de tempo de execução RPC autentica o cliente ou o servidor de acordo com o padrão do SSP. Por padrão, o protocolo Kerberos SSP autentica o cliente e o servidor. O padrão para todos os outros SSPs que a Microsoft fornece é autenticar o cliente no servidor, mas não autenticar o servidor no cliente.
Se o cliente e o servidor sempre devem se autenticar entre si, defina o membro Capabilities da estrutura RPC_SECURITY_QOS como RPC_C_QOS_CAPABILITIES_MUTUAL_AUTH. Alguns provedores de segurança podem não dar suporte à autenticação mútua. Se RPC_C_QOS_CAPABILITIES_MUTUAL_AUTH for especificado para esses provedores de segurança, um erro será retornado quando uma chamada de procedimento remoto for feita. Ao usar o SSP do SCHANNEL, também é possível definir o membro Capabilities como RPC_C_QOS_CAPABILITIES_ANY_AUTHORITY. Essa constante especifica que o SSP validará a chamada de procedimento remoto mesmo que a autoridade de certificação que emitiu o certificado de autenticação do cliente não esteja no repositório de certificados raiz do SSP. O padrão é rejeitar o certificado se o SSP não reconhecer a autoridade de certificação. A autoridade de certificação é uma empresa ou organização independente, como a VeriSign, que emite certificados de autenticação.
Os aplicativos também podem definir o acompanhamento de identidade que a biblioteca de tempo de execução do RPC usa. Os programas geralmente usam o acompanhamento de identidade estático. Com o acompanhamento estático, as credenciais do cliente são definidas quando ele chama a função RpcBindingSetAuthInfo . Em seguida, a biblioteca de tempo de execução RPC usa essas credenciais para todas as chamadas RPC na associação, independentemente das alterações na identidade do thread de chamada ou do processo de chamada. Os aplicativos também podem selecionar o acompanhamento dinâmico de identidade. O acompanhamento dinâmico de identidade instrui a biblioteca de tempo de execução do RPC a usar as credenciais do thread de chamada no momento de cada chamada, em vez do identificador de associação. O controle de identidade padrão é estático.
Se a identidade do cliente não for alterada, o rastreamento de identidade estático poderá ter melhores características de desempenho e poderá salvar o tempo de execução do RPC de verificar cada vez se a identidade no thread de chamada é a mesma que a identidade fornecida ao sistema de segurança. Se a identidade do thread de chamada puder mudar entre as chamadas e o servidor precisar reconhecer essas alterações, é melhor especificar o acompanhamento dinâmico de identidade: o tempo de execução do RPC controla a identidade de forma silenciosa e eficiente e, se a identidade for alterada, gerenciará essa alteração em seu nome.
Observação
Para chamadas ncalrpc , o acompanhamento de identidade estático e dinâmico tem características de desempenho diferentes e, dependendo das circunstâncias, qualquer um pode ser mais rápido.
Como parte da especificação do QOS, o programa cliente também pode definir o tipo de representação que um programa de servidor pode executar em seu nome. Para obter mais informações, consulte Representação do cliente.
O campo número de versão da estrutura RPC_SECURITY_QOS deve ser sempre definido como RPC_C_SECURITY_QOS_VERSION.