segurança de API

É possível proteger suas APIs com dois níveis diferentes que ajudam a controlar quem pode chamar APIs e qual autorização essa pessoa deve ter..

Ao chamar uma API, você deve passar pelos dois níveis de segurança a seguir:

  1. Autenticação com um ID do usuário, um certificado ou ambos. A API de login é chamada antes de qualquer outra API.
  2. Autorização, que verifica a API que você pode acessar.

Este procedimento de segurança é para cada chamada de API que é feita por meio de um processo do servidor de aplicativos. Por padrão, agente e servidores de integração sempre possuem acesso completo às APIs.

Assim que passar na verificação de autenticação, uma verificação de autorização determinará quais APIs e recursos você pode acessar. Esta verificação de autorização é além da segurança da interface com o usuário (UI). Por exemplo, a segurança da IU pode ajudar a acessar uma tela que lista usuários. Para gerar uma lista de usuários na tela, também pode ser necessário passar uma verificação de autorização para a API getUserList que lista os usuários.

Outros exemplos de verificações de autorização incluem:
  • Se você usar a API do getCommonCodeList para propósitos de exibição, não será possível obter informações do usuário que são explicitamente restritas da saída da API.
  • Se você chamar a API getUserList antes de designar um alerta, não será possível obter senhas do usuário.
  • Se você usar a API UserHierarchy para mudar sua senha:
    • Você não deve poder alterar seu próprio sinalizador IsSuperUser.
    • Você não deve ser capaz de modificar as informações de outro usuário.
    • Você não deve ser capaz de assinar mais grupos de usuários, o que lhe daria mais acesso ao sistema.

Essa segurança é implementada usando os arquivos de modelo de apisecurity (segurança). Estes arquivos de modelo apisecurity são arquivos XML que documentam os elemento de entrada e saída para os quais (por padrão) todas as APIs são restritas. Esses arquivos são gerados automaticamente durante a implementação de XAPI, mesmo quando a geração de documento está desativada.

Nota: os serviços não usam o arquivo apisecurity.

Modelos são usados para as verificações de autorização de entrada e saída. Esses modelos substituem os modelos regulares.

Por exemplo, um modelo de entrada com as linhas OrganizationCode=#PROHIBITED# e IsSuperUser=#PROHIBITED# impediria que você subscrevesse mais grupos de usuários e obtivesse mais permissões.

O modelo de saída suplementa a filtragem executada pelo modelo baseado na documentação padrão. Se um elemento for restringido porque ele não está configurado no arquivo apisecurity, ele nunca será retornado na saída, mesmo se presente no modelo baseado na documentação.

Nota: em determinados pontos na entrada e saída, APIs como multiApi e getPage têm acesso de autorização para qualquer elemento. Mas, outras APIs que são chamadas por estas APIs devem passar pela verificação de autorização.

O acesso à segurança da API e o nível de permissão são controlados nas seguintes propriedades no arquivo yfs.properties. Todas as falhas de autorização são registradas em uma categoria de criação de log denominada sci.apisecurity.

  • api.security.enabled
    • Y (padrão) — Ativar segurança da API
    • N — Não ativar segurança da API
  • api.security.mode
    • STRICT — Se qualquer validação falhar, lance uma exceção. Isso é apropriado para sistemas de produção, se todas as permissões estão configuradas corretamente.
    • LAX — Filtrar e registrar a entrada inválida, mas continuar o processamento. A filtragem permite que o sistema trabalhe pela maior parte, apesar da entrada ou saída incorreta, enquanto o registro ajuda a identificar os locais que precisam ser alterados.
      Nota: O sistema ainda pode lançar uma exceção quando a filtragem produz um comportamento ambíguo..
    • DEBUG — Registrar entrada e saída inválidas, mas não filtrar nada nem lançar exceções. Isso é apropriado somente durante o desenvolvimento inicial para identificar as permissões necessárias para vários processos

Se você não especificar um modo de segurança, não há filtragem, exceções lançadas nem verificação de autorização. Ha criação de log limitada.

  • api.security.override .apiName.mode

    Use essa configuração para substituir as permissões em APIs individuais. Esta propriedade usa os mesmos valores que api.security.mode.

  • api.security.smc.enabled
    • Y-Ativar a segurança da API para o Applications Manager
    • N (padrão) Não ativar a segurança da API para o Applications Manager
  • api.security.console.enabled
    • Y — Ativar segurança da API para o Application Console
    • N (padrão) — Não ativar segurança da API para o Application Console

Ao atualizar, você deve inicialmente desativar este recurso e conceder todo o acesso por meio das propriedades. Em um sistema atualizado, você pode introduzir gradualmente este recurso ativando a segurança uma API por vez, conforme você definir e testar as permissões. Se ativado, apenas o grupo de usuários do sistema recebe permissão para as APIs; para todos os outros grupos de usuários customizados, a permissão apropriada deve ser fornecida. Para obter informações sobre permissões do grupo de usuários, consulte Sobre modelagem da organização.