Conceitos
A autenticação na plataforma pode ocorrer de várias formas, porém, antes de tudo, é preciso explicar que existem duas coisas:
– Autenticação: Processo de digitar usuário e senha para validação
– Autorização: Processo de dar ou não permissão para um usuário acessar um recurso
E que na SeniorX (G7) seguimos um modelo de mercado que possui dois componentes:
– IdP (Identity Provider): Responsável por autenticar um usuário
– RP (Resource Provider): Responsável por garantir que o usuário tenha permissão para acessar um recurso (ex: chamar uma API)
Na SeniorX, suportamos 4 tipos de autenticação:
– Nativa: Fazemos o papel de IdP e RP e os usuário são cadastrados na própria plataforma
– Integração G5: Fazemos o papel de Idp e RP e os usuários são importados da G5
– LDAP: AD faz o papel de IdP e nós fazemos o papel de RP apenas, temos que importar os usuários do LDAP para atribuir as permissões
– SAML: ADFS faz o papel de IdP e nós fazemos o papel de RP apenas, todo usuário que logar e não existir na SeniorX criamos ele para que possa ser atribuído as permissões
Obtenção do token para chamada de APIs
Para realizar chamadas em APIs da plataforma ou mesmo validar o login para uma simples integração, é necessário passar nas chamadas o token criado pela plataforma para acesso.
O token criado deve ser passado em todas as requisições para endpoints da plataforma, no header Authorization dos requests.
Exemplo de autenticação para abertura de sistema através do menu da plataforma
Na integração via menu, onde o sistema integrado será acessado por dentro da plataforma a obtenção do token é feita à partir da própria sessão autenticada.
Neste caso o token é obtido no login e está disponível em cookies da sessão. O sistema integrado deve ser configurado no menu de forma que receba o token para que possa consumir os endpoints da plataforma e sistemas.
Para criar os menus do sistema siga o tutorial: criando um pacote de menus pré-definidos
Para ver exemplo de implementação de um Frontend integrado , clique aqui
Na integração via Backend, uma chamada de login deve ser feita para obtenção do token, que deverá ser utilizado nas chamadas subsequentes da API
Exemplo de autenticação e consumo de API
Chamada do endpoint de autenticação:
curl -d "{'username':'user@domain.com.br', 'password':'myStrongPassword'}" -H “Content-Type:application/json” -X POST https://platform.senior.com.br/t/senior.com.br/bridge/1.0/rest/platform/authentication/actions/login Que vai gerar a resposta: {"jsonToken":" {\"scope\":\"desktop device_ef811503-2047-46d1-bf9e-d13f7c44db4f\", \"expires_in\":604800,\"username\":\"user@domain.com.br\", \"token_type\":\"Bearer\",\"access_token\":\"1759c479d34d9bc1d0abc0c65e627ec5\", \"refresh_token\":\"0db9a569644b861b38d48e9dd9ce087e\"} "}
Após isso pode-se chamar qualquer API passando o acces_token no header Authorization das chamadas subsequentes
curl -X GET -H “Content-Type:application/json” -H “Authorization: Bearer <token>” https://platform.senior.com.br/t/senior.com.br/platform/1.0/rest/usuarios/userManager/queries/obterMeusDados
Que vai gerar a resposta:
{ "id": "ae87372a-f713-4d9a-ae59-e659a360cc70", "nome": "user", "nomeCompleto": "user@domain.com.br", "descricao": "50000", "email": "user@domain.com.br", "localidade": "en-US", "tenantDomain": "domain.com.br", "tenantName": "domain", "tenantLocale": "pt-BR" }
Outro exemplo de consumo de APIs pode ser encontrado aqui
Fluxo de autenticação com ADFS
- Colaborador da Senior acessar nosso login.senior.com.br
- Usuário é redirecioando para logar no ADFS da Senior
- Usuário entra com nome e senha do ADFS
- ADFS valida, manda um SAML Code para o RP da SeniorX e redireciona o usuário para o login.senior.com.br com o SAML Code gerado
- SeniorX valida o SAML Code, autentica o usuário e retorna um token OAuth2
- Usuário acessa o menu do sistema Integrado, se possuir a permissão adequada
- O menu deve apontar para o login do sistema Integrado