Certificação de Conformidade

O Test Plan da Fase 2 Versão 2 de dados transacionais é uma série de test plans que foram construídos para testar se as implementaçãos de cada instituição estão em linha com a última versão das APIs de dados transacionais da fase 2 do Open Insurance Brasil, e também estão em linha dos requisitos funcionais esperados

Os testes são divididos em duas diferentes classes:

• Testes Estruturais

- Testes que validarão a estrutura do JSON structure para as respostas 20X de cada endpoint de dados. Já que a camada de segurança não será testada, o payload não deve ser protegido via MTLS. Haverão um módulo de teste por API dentro do mesmo test plan.

• Teste Funcionais

- Testes que validarão o comportamente funcional da API, com um test plan específico para cada API.

Como os testes estão em desenvolvimento contínuo, até que as certificações iniciem podem ser encontrados erros durante as execuções pelas instituições. Estes erros podem ser relacionados a especificações incertas ou porque o teste está executando um comportamento que não está em linha com o definido nas especificacões. Em ambos os casos, as instituições devem abrir um ticket da issue no Service Desk para que o erro possa ser avaliado pelo time de engenharia da Conformance Suite.

Requisitos de amostra de dados

Todos os testes necessitam que as instituições provisionem pelo menos um cliente Pessoa Física ou Pessoa Jurídica com o produto que está sendo testado. O CPF ou par de CPF/CNPJ do cliente testado deve ser provisionado na configuração do teste para que as APIs possam ser acessadas e o payload de resposta possa ser validado no escopo do teste.

Quando dados além dos definidos acima forem necessários, o sumário do teste definirá o que deve ser provisionado para que o teste execute com sucesso. Os seguintes test plans contém módulos que necessitam de amostras de dados:

1. Resources API Test 1.1.0 - entre 3 a 25 recursos acessíveis devem ser provisionados para que o usuário passe no teste de paginação que requer o acesso a uma segunda página.

Execução dos test plans

To execute the tests the user will have to follow a three-step process: Para executar os testes, o usuário deve seguir um processo de 4 passos:

1. Acessar o Open Insurance Conformance Suite

2. Selecionar um Test Plan

3. Preencher os campos de configuração

4. Executar os módulos de teste

O detalhe de cada passo é definido a seguir:

Acesso a Conformance Suite

Os testes de dados transacionais estão disponíveis na Open Insurance Brasil Conformance Suite. Para acessar a Conformance Suite, o usuário deve ter uma conta ativa no Diretório de Sandbox do Open Insurance Brasil.

Após o acesso o usuário será direcionado a uma página inicial com 6 botões:

Open

Para executar os testes, o usuário deve clicar no botão "Create a new test plan". O usuário pode também verificar logs de testes ou planos publicados nas outras opções.

Selecionar um Test Plan

Ao criar um test plan, o usuário deverá prencher as informações pertinentes a execução:

Open

A lista completa de test plans é disponibilizada no menu "Test Plans". Nele o usuário pode selecionar qualquer um dos testes apresentados na lista. Tanto os testes Estruturais quanto os Funcionais estarão disponíveis nesta lista:

Após selecionar um test plan, o usuário também será solicitado a preencher três opções:

1. Client Authentication Type - Como o cliente se autenticará no servidor para obter o token. FAPI suporta somente private_key_jwt e tls_client_auth dos Métodos de Autenticação OAuth 2.0 disponíveis

2. Request Object Method - Se PAR será ou não utilizado

Preencher os campos de configuração

Dependendo do tipo de teste a ser executado (Funcional ou Estrutural) o usuário será solicitado a providenciar informações adicionais para prosseguir com a execução do teste. As informações são detalhes tanto sobre o cliente que será utilizado pela Conformance Suite, quanto detalhes sobre o servidor que será certificado pelos testes

Configuração dos testes estruturais

O usuário deve providenciar as seguintes informações para executar os testes estruturais:

Test Information:

Estes campos são usados para definir informações gerais utilizadas pela Conformance Suite quando executando e salvando os testes.

alias: Este campo será utilizado para criar o redirect_uri que será utilizado ao executar o fluxo de autorização no escopo dos testes. Este é um campo padrão, e não será utilizado nos testes estruturais.

description: Campo de texto livre que será utilizado para identificar este teste posteriormente.

publish: Selecione se os resultados dos testes devem ser publicados ou mantidos privados - Caso sejam publicados será possível que outros usuários acessem seus test plans ao pesquisar por logs de testes públicos.

Server:

discoveryUrl: Providencie a URI de Meta Dados do Authorisation Server, também conhecido como endereço well-known. Esse valor também deve ser registrado no Diretório de Sandbox do Open Insurance Brasil.

Resource:

resourceUrl: Providencie um URL que será utilizado para acessar o endpoint via Regex. É importante notar que o URL providenciado neste campo deve ser o que hospede as payloads que serão validadas no teste estrutural, portanto não deve ser protegido via MTLS. Exemplo: https://www.example.dummypayload.com/open-insurance/consents/v1/

Configuração dos testes funcionais

Os testes funcionais requerem informações adicionais que devem ser preenchidas na configuração do teste. As seções que devem ser preenchidas são:

• Test Information

• Server

  • Client

  • Resource

  • Directory

A descrição de cada campo é detalhada abaixo:

Test Information:

Estes campos são usados para definir informações gerais utilizadas pela Conformance Suite quando executando e salvando os testes.

alias: Este campo será utilizado para criar o redirect_uri que será utilizado ao executar o fluxo de autorização no escopo dos testes. A redirect_uri terá o seguinte formato: "https://web.conformance.directory.openbankingbrasil.org.br/test/a/alias/callback" no qual alias é o valor definido no campo alias. Certifique-se de que este redirect_uri foi adicionado ao software_statement utilizado no DCR.

description: Campo de texto livre que será utilizado para identificar este teste posteriormente.

publish: Selecione se os resultados dos testes devem ser publicados ou mantidos privados - Caso sejam publicados será possível que outros usuários acessem seus test plans ao pesquisar por logs de testes públicos.

Server Details

Estes campos são relacionados à configuração do servidor e suas URIs, incluindo tanto as URIs do Authorisation Server as URIs do Resource Server.

discoveryUrl: Providencie a URI de Meta Data do Authorisation Server, também conhecida como o endereço well-known. Este campo também deve ser cadastrado no diretório de Sandbox do Open Insurance Brasil.

Client Details:

Estes detalhes são relacionados ao Software Statement que deve ser criado no ambiente de Sandbox do Open Insurance Brasil e que será utilizado pela Conformance Suite para conectar-se ao servidor que será testado. Antes de gerar os certificados e realizar o DCR para gerar o client_id necessário, certifique-se de que o redirect_uri correto e o papel de DADOS foi adicionado ao Software Statement.

jwks: Providencie as chaves de assinatura utilizadas pelo cliente em um formato JWKS. Nós sugerimos utilizar a PKI do Diretório de Sandbox para gerar estas chaves. Para criar uma chave de assinatura (BRSEAL) na PKI do Diretório de Sandbox, refira-se ao guia de geração do certificado BRSEAL

As chaves geradas seguindos as instruções do diretório serão geradas em um formato que não é JSON. Porém os testes necessitam que as chaves estejam no formato JWKS. Há diversas maneiras de realizar a conversão. Dado que esta chave será publicada durante a execução do teste, é possível utilizar um conversor online para obter o JWKS, com o procedimento a seguir:

1. Converta o arquivo .key obtido do diretório para RSA com OpenSSL openssl rsa -in server.key -out server_new.key

2. Converta a chave RSA para JWK em jwk to pem convertor, pem to jwk convert online, jwk openssl format pem

3. Antes de adicionar a Private Key na Conformance Suite, certifique-se de o objeto "alg": "PS256" foi adicionado ao jwks, e que o campo "kid" está atualizado com o kid correto do diretório, e que o campo "use" tem o valor "sig".

mtls.cert: Providencie o conteúdo do certificado Public Transport (BRCAC) gerado no Diretório de Sandbox em formato PEM. Aqui você pode abrir o arquivo .pem com um editor de texto comum e colar os conteúdos neste campo. Para criar um certificado BRCAC na PKI do Diretório de Sandbox, refira-se ao guia de geração do certificado BRCAC

mtls.key: Providencie o conteúdo da chave pública em formato .PEM. Similar ao campo mtls.cert, porém aqui deve ser providenciado o conteúdo da chave que foi gerada junto ao .csr.

client_id: Neste campo, você deve providenciar o client_id que foi gerado ao realizar um DCR contra o servidor a ser testado com as credenciais preenchidas acima.

Certifique-se de que o Software Statemen utilizado foi registrado com o papel de DADOS.

Resouce

consentUrl: Providencie a URI utilizada para acessar a API de Consent de dados transacionais.

brazilCpf: Providencie o CPF do cliente teste criado para o escopo dos testes. Este CPF será utilizado ao criar o ConsentID em cada um dos planos executados pela Conformance Suite.

brazilCnpj: Caso a instituição deseje testar com um cliente do tipo Pessoa Jurídica, providencie também o CNPJ que será utilizado para criar o Consentimento. Este campo não é obrigatório.

Business or Personal Products: Selecione se a Conformance Suite utilizará as permissões de Customer Personal Permissions (Pessoas Físicas) ou Business Personal Permission (Pessoa Jurídica) ao obter dados do servidor. Caso o campo brazilCnpj seja preenchido, selecione Business Personal Permission.

Directory

Directory ClientID: ID do cliente (Software Statement) no Diretório. Este valor é utilizado para obter o access token, que é utilizado para obter o Software Statement.

Quando todas as configurações estiverem preenchidas, clique em "Create Test Plan":

Executar os módulos de teste

Após a criação dos test plans, você será redirecionado à página de test plan. Para começar a execução dos testes, selecione o módulo de teste a ser executado, e clique em "Run test":

Por favor leia a descrição do teste na caixa de texto azul claro próxima ao topo dos logs da página - essa seção pode conter instruções específicas ao teste; por exemplo, um teste requer que o usuário rejeite o processo de autenticação. Se aplicável, o teste pode pedir que seja aceito (ou negado, ou ignorado) o pedido no dispositivo de autenticação em questão.

Quando o teste for completado, pressione “Continue Plan” para iniciar o próximo teste, ou “Return to Plan” para visualizar seu progresso.

Se você necessitar de suporte, por favor crie um issue no GitLab da Conformance Suite, visitando este link.

Caso seja relacionado a falha de um teste, por favor inclua um link para o log-detail.html relacionado, ou caso esteja utilizando uma instalação local, o arquivo de log baixado.

Lista de Test Plans

26 módulos de testes distintos já foram disponibilizados para a Certificação da Versão das APIs da Fase 2. Estes testes estão separados em seis diferentes test plans, um para cada teste Funcional mais um para os testes Estruturais. Os módulos disponíveis estão listados a seguir:

• Functional tests for Consents API - version 1.0.0

  • opin-preflight-check-test

  • opin-consent-api-test

  • opin-consent-api-status-test

  • opin-consent-api-test-negative

  • opin-consent-api-test-permission-groups

  • opin-consent-api-test-client-limits

  • opin-consent-api-status-declined-test

  • opin-consent-api-expired-consent-test

  • opin-consents-api-delete-test

  • opin-consent-inavlid-user-test

• Functional tests for Resources API - version 1.0.0

  • opin-resources-api-test

  • opin-resources-api-test-404-customer-data

  • opin-resources-api-pagination-test

• Functional tests for Customer Personal API - version 1.1.0

  • opin-customer-personal-data-api-test

  • opin-customer-personal-api-wrong-permissions-test

• Functional tests for Customer Business API - version 1.1.0

  • opin-customer-business-data-api-test

  • opin-customer-business-api-wrong-permissions-test

• Functional tests for Patrimonial API - version 1.1.0

  • opin-patrimonial-api-test

  • opin-patrimonial-api-wrong-permissions-test

  • opin-patrimonial-resources-api-test

  • opin-patrimonial-residencial-api-branch-test

• Structural tests

  • opin-consents-api-structural-test

  • opin-resources-api-structural-test

  • opin-customer-personal-api-structural-test

  • opin-customer-business-api-structural-test

  • opin-patrimonial-api-structural-test

Test Plans

• Lista com os cenários de testes realizados para APIs de Fase 2 e 3.

Workshops

• 1º Workshop Processo de Certificação Funcional das APIs Fase 2 com a Raidiam (23/11/2022)