Pular para o conteúdo principal

Conceitos

Entidades​

Entidade é a representação jurídica da corporação que possui a licença do software, além da representação jurídica e legal da entidade em si. As entidades são cadastradas pela própria Betha Sistemas, como uma efetivação da entidade proprietária de uma licença de uso do software.

Times​

De modo geral, times são grupos com permissões específicas dentro de um escopo na Entidade em qual foi criado.

Acessos​

Local onde são concedidos acessos aos usuários para que possam utilizar os produtos Betha.

Licenças​

Local onde são concedidos as licenças (liberações) para que as entidades possam utilizar os produtos Betha.

Segurança​

Um item que faz parte da segurança e que deve ter uma atenção considerável é o token, pois ele é responsável pela manipulação de dados. Portanto, tenha bom senso e não dê a chave para ninguém e não deixe visível em lugares em que as pessoas tenham acesso.

Mas, o que é um token?

Token é um certificado digital, que gera uma senha para que o usuário possa realizar movimentações de dados.

Exemplo: pense em uma chave que pode manipular tanto um sistema como uma integração entre dois ou mais sistemas. Para realizar ações como essa é necessário ter certa criticidade e saber muito bem o que está fazendo.

Quando gerado um token jamais anexe em chamados ou chat, sempre envie via e-mail.

Escopos​

Escopos são identificadores que representam permissões específicas de acesso a recursos de uma API. Cada API pode definir um ou mais escopos que controlam o nível de acesso concedido a um token. Exemplos: meu-projeto.suite.betha.cloud/auth/dados.leitura, meu-projeto.suite.betha.cloud/auth/dados.escrita.

IMPORTANTE!

Os nomes dos escopos são únicos globalmente em toda a plataforma. Isso significa que um escopo cadastrado em uma API de qualquer projeto não pode ser reutilizado em outra API, mesmo que pertença a um projeto diferente. Ao tentar cadastrar um escopo com nome já existente, o sistema retornará o erro: ”Não foi possível realizar a operação pois existem itens duplicados”.

Access Token​

O Access token é uma credencial representada por um conjunto de caracteres alfanuméricos que fornecem as informações necessárias para autorizar um usuário a utilizar uma determinada API. Cada token está vinculado com um ou mais escopos que definem se o mesmo é apto para o consumo das API’s. O access token é utilizado no cabeçalho das requisições através da propriedade “authorization”, conforme exemplo a seguir:

curl 
'https://plataforma-autorizacoes.betha.cloud/user-accounts/v0.1/api/suite/users/@me/access/ZGF0YWJhc2U6MTAwMjA1LGVudGl0eTo1MzE2' \
  -H 'Authorization: Bearer 48ef47b7-322e-4a77-8019-7994298e5eb1' \

User-Access​

Para realizar o consumo dos dados de um cliente específico, é necessária a geração prévia de um user-access que fornece a permissão para acesso aos dados de clientes que serão utilizadas nas requisições em conjunto com o Access token. É uma autorização dada aos usuários que lhes permite acessar recursos específicos de um determinado cliente. É a geração do usuário para estar realizando credenciais com os escopos necessários para autorização de consumo das API's. Muito utilizado nas requisições dos usuários, sistema e contexto para coletar informações. Segue exemplo de uma requisição com user-access: 

curl 
'https://plataforma-autorizacoes.betha.cloud/user-accounts/v0.1/api/access/61d374cf8975d901043c69a4/systems' \
  -H 'authorization: Bearer a3ca2a5f-9386-4473-977a-f8eee51e8d72' \
  -H 'user-access: 9KhjaHpS4B6Leuh_KBEvDg==' \

Para realizar a geração de um user-access é necessário que o cliente tenha em mãos a chave pública da credencial de serviço já vinculada a API, e esta deve ser utilizada na tela de autorizações do próprio sistema para a geração do user-access. Uma vez com o user-access em mãos, já é possível realizar a interação das API’s com dados daquele cliente.

Propriedades de uma licença (onde e como usar)​

Existem cenários onde um parceiro Betha pode ter um subdomínio por sistema, ou seja, para cada liberação de um sistema, será necessário ter um domínio, como por exemplo:

  • criciuma.sistema.betha.cloud
  • riodosul.sistema.betha.cloud

Como esse domínio é dinâmico e totalmente acoplado a uma licença, dado o cenário da informação será colocado na propriedade, que é um campo dentro do cadastro de licenças, que poderá ser informado pelo Admin ou diretamente no CRM que são sistemas que gerenciam as licenças, lembrando que, uma licença é liberada para um sistema e entidade.

O campo propriedade, é uma String Json, que irá aceitar qualquer valor, não limitando apenas ao cenário citado de domínios, mas podendo ser usado em diversos cenários como por exemplo: permissões dentro de um sistema, entre outros.

Exemplo do valor do campo propriedade:

{
    "dominio": "criciuma",
    "liberado": true,
    "codigo": 10,
    “chaveexemplo”: “valorexemplo”
}

No cenário para uso de domínio, será informado a propriedade da licença, com o domínio e na configuração do Projeto, na URL do Produto deverá ser informado de forma dinâmica.

studio

Para demais cenários, o campo propriedade poderá ser consultado através das requisições que retornam dados do acesso, como:

Para mais detalhes dessas requisições, veja no tópico Autorizações.

O objetivo aqui, é mostrar o retorno que terá a propriedade da licença, como mostra o exemplo abaixo:

{
"id": "60a2dfc82170040104d12a72",
"licenseId": "KBgAQZmL5-cEXQLuuniWag==",
"admin": true,
"user": "teste.lamego",
"createBy": "guilherme.lamego",
"createAt": "2021-05-17T21:27:36.803+0000",
"context": "ZGF0YWJhc2U6MTA4NDQsZW50aXR5OjEwNTQ=",
"totalGroups": 0,
"totalRestrictions": 0,
"system": 56,
"technical": false,
"expiresIn": null,
"connected": true,
"firstActivity": "2022-02-18T19:55:57.214+0000",
"lastActivity": "2022-02-18T19:55:57.214+0000",
"accepted": true,
"acceptedIn": "2022-02-16T10:05:30.273",
"licenseProperty": {
"chave2": "valor2",
"chave1": "valor1"
},
"values": {
"database": "10844",
"entity": "1054"
}

Onde é possível verificar o valor da propriedade do atributo licenseProperty.

Multi-tenancy​

Multi-tenancy é o termo utilizado para definição de arquiteturas que propõem a organização de múltiplos clientes dentro de um serviço. Os serviços da Betha organizam os dados de cliente em databases físicos em um único schema, porém, o isolamento dos dados dos clientes se dá através de duas camadas: o database e a entidade.

studio

O database é o nível mais elevado de particionamento lógico das informações armazenadas, do qual agrupa todos os dados de um único cliente. Quanto a entidade representa um subnível de particionamento dentro de um database, onde é possível definir quais dados serão completamente isolados, e quais dados podem ser compartilhados entre entidades dentro de um mesmo database.

studio