WS-Policy

O que é WS-Policy, em palavras simples?

Pense no WS-Policy como o regulamento de entrada de um prédio, escrito em linguagem que computadores entendem. Ele não executa a segurança, apenas informa as regras: se é preciso apresentar certificado, se a mensagem deve ser assinada, se o conteúdo precisa estar criptografado e assim por diante.

Ele faz parte da família de especificações conhecidas como WS-* (WS-Security, WS-Addressing, WS-SecurityPolicy, entre outras), criadas para padronizar a comunicação entre web services do tipo SOAP. O nome completo em inglês é Web Services Policy Framework.

Como funciona o WS-Policy?

Uma política é um documento XML formado por asserções, que são requisitos ou capacidades individuais, por exemplo, exigir transporte via HTTPS ou exigir assinatura no corpo da mensagem. Essas asserções podem ser combinadas com operadores como All (todas devem ser atendidas) e ExactlyOne (apenas uma das alternativas deve ser escolhida).

A política costuma ser anexada ao WSDL, o arquivo que descreve o web service, por meio de um mecanismo chamado Policy Attachment. Ferramentas de desenvolvimento leem esse WSDL, interpretam a política e configuram automaticamente o cliente para respeitar as regras exigidas pelo servidor.

Para que serve o WS-Policy na integração fiscal?

Muitos serviços de emissão de documentos fiscais no Brasil, como os web services das SEFAZ e de diversas prefeituras para NFS-e, foram construídos sobre SOAP e descritos por WSDL. Quando um desses serviços declara políticas, elas indicam ao desenvolvedor como a conexão e as mensagens devem ser montadas.

Na prática, entender a política ajuda a evitar erros de comunicação difíceis de diagnosticar, como mensagens recusadas por falta de um cabeçalho de segurança ou por uso de um protocolo diferente do esperado. Como cada órgão pode ter suas próprias exigências, ler a documentação e a política de cada serviço é parte do trabalho de integração.

Qual a diferença entre WS-Policy e WS-Security?

O WS-Security define como aplicar segurança dentro da mensagem SOAP, por exemplo, como incluir assinaturas, tokens e criptografia no cabeçalho. Já o WS-Policy apenas descreve quais requisitos o serviço exige.

Existe ainda o WS-SecurityPolicy, que fornece as asserções específicas de segurança usadas dentro de uma política WS-Policy. Em resumo: o WS-Policy é a estrutura geral, o WS-SecurityPolicy é o vocabulário de segurança e o WS-Security é a forma de aplicar essas regras na mensagem.

Quem usa uma API fiscal REST precisa se preocupar com WS-Policy?

Em geral, não diretamente. Quando o sistema emite documentos por meio de uma API REST para emissão fiscal, é o provedor da API que lida com os web services SOAP dos órgãos, incluindo políticas, certificados, assinaturas e formatos XML específicos de cada SEFAZ ou município.

Isso permite que o desenvolvedor trabalhe com JSON e endpoints padronizados, sem precisar interpretar WSDL ou políticas de dezenas de serviços diferentes. O conceito continua útil, porém, para quem mantém integrações próprias ou precisa entender por que certos serviços exigem configurações tão específicas.

Exemplos de WS-Policy

• Um desenvolvedor importa o WSDL do web service de NFS-e de uma prefeitura e a ferramenta gera automaticamente um cliente configurado para enviar mensagens assinadas, porque a política anexada exige essa assinatura.
• Uma política WS-Policy declara, com o operador ExactlyOne, que o serviço aceita autenticação por certificado digital ou por token de usuário, cabendo ao cliente escolher apenas uma das opções.
• Uma equipe de ERP investiga por que suas requisições SOAP são recusadas e descobre, lendo a política do serviço, que faltava incluir um carimbo de tempo no cabeçalho de segurança.
• Uma plataforma de vendas troca a integração direta com vários web services SOAP por uma API fiscal REST e deixa de precisar tratar as políticas de cada órgão separadamente.