Os desafios de fazer um sistema de autenticação usando LDAP e permissionamento com PHP. Tchelinux Porto Alegre 2019

1. PHPSSOnoZentyal
Os desafios de fazer um sistema de autenticação
usando LDAP e permissionamento com PHP.
Tchelinux
Edição Porto Alegre
2019

2. JacksonMafra
Desenvolvedor Sênior
Desenvolvedor há mais de 20 anos com background em
projetos de e-commerce e mercado imobiliário, desde
2009 com interesses focados para o desenvolvimento de
interfaces móveis e aplicações corporativas.
Me chama lá...
http://about.me/jacksonfdam
http://linkedin.com/in/jacksonfdam
@jacksonfdam

3. Agenda
01Gerenciamento de acesso à identidade
02
Processode
autenticação
Gerenciamento de acesso à identidade
IAM
03Easy Linux alternative to Windows
Server
Zentyal
04Criando o logon único...
eoPHP?

4. Processode
autenticaçãoGarantir o acesso à uma rede, e seus
serviços, por usuários legítimos
01

5. Aidentificaçãoéumprocessoquepermiteo
reconhecimentodeumaentidadeporum
sistemaeaautenticaçãoéumprocessoque
verificaaidentidadedeumusuário,dispositivo
ououtraentidadeemumsistemade
computador,geralmentecomoumpré-requisito
parapermitiroacessoarecursosemum
sistema.

6. Autenticação
Um processo de autenticação tem como objetivo garantir o acesso à uma
rede, e seus serviços, por usuários legítimos, e impedindo qualquer acesso
não autorizado.

7. Autenticação
Muitos sistemas computacionais requerem que o usuário primeiramente
passe por um processo de autenticação para que esteja devidamente
identificado e habilitado a utilizar o sistema, antes de permitir o acesso
deste usuário à rede.

8. Autenticação
Sendo validado e autorizado, o usuário terá acesso garantido durante um
determinado período de tempo estabelecido pelo sistema de autenticação,
e terá que revalidar sua autorização quando este tempo se esgotar.

9. Autenticação
Enviando uma mensagem de request, o sistema é capaz de identificar
múltiplos usuários.
Tradicionalmente, este processo é realizado através do envio de uma
senha (password) durante o login.
No entanto, o envio de senhas através da rede não é seguro, uma vez que
elas podem ser interceptadas por alguém que esteja vigiando a rede, com
o objetivo de se fazer passar pelo usuário.

10. Autenticação
Muitos serviços de rede aceitam sem maiores verificações as
autenticações providas por uma máquina cliente, onde se encontra o
usuário.
Um serviço seguro de rede não se baseia apenas na integridade e
veracidade de informações fornecidas somente por uma máquina cliente.

11. Autenticação
Dado este tipo de vulnerabilidade, existem protocolos que realizam as
autenticações utilizando criptografia.
Dessa forma, não há o fornecimento de informações para pessoas que
estejam intencionadas a adquirir a identidade de outra.
Alguns protocolos questionam e autenticam a identidade de um usuário
toda vez em que este fizer a requisição de um serviço da rede, podendo
aceitar ou negar a utilização do serviço pela máquina cliente.

12. Principaistermos
Os seguintes termos e abreviações são usados em todo esta apresentação:
SAML: Security Assertion Markup Language
IdP: Identity Provider (provedor de identidade)
SP: Service Provider (provedor de serviço)
AS: Authorization Server
ADFS: Serviços de Federação do Active Directory
ADCs: Application Default Credentials (Credenciais padrão do aplicativo)

13. Principaistermos
GP: Group Policy(Política de grupo)
GPO: Group Policy Object (Objeto de Política de grupo)
Realms: Domínios
Roles: Funções
Rules: Regras
ABAC: Attribute-based access control
RBAC: Role-based access control

14. Principaistermos
Autenticação: verificação de que uma entidade é quem / o que alega estar
usando uma senha, biometria como impressão digital ou comportamento
distinto como um padrão de gesto em uma tela sensível ao toque.
Autorização: gerenciando informações de autorização que definem quais
operações uma entidade pode executar no contexto de um aplicativo
específico. Por exemplo, um usuário pode estar autorizado a inserir um
pedido de vendas, enquanto um usuário diferente está autorizado a
aprovar a solicitação de crédito para esse pedido.

15. Principaistermos

16. Principaistermos
Funções: Funções são grupos de operações e / ou outras funções. Os
usuários recebem funções frequentemente relacionadas a um trabalho ou
função específica.
As funções recebem autorizações, efetivamente autorizando todos os
usuários aos quais foi concedida a função. Por exemplo, uma função de
administrador do usuário pode estar autorizada a redefinir a senha do
usuário, enquanto uma função de administrador do sistema pode ter a
capacidade de atribuir um usuário a um servidor específico.

17. Principaistermos
Delegação: a delegação permite que administradores ou supervisores
locais realizem modificações no sistema sem um administrador global ou
que um usuário permita que outro execute ações em seu nome. Por
exemplo, um usuário pode delegar o direito de gerenciar informações
relacionadas ao escritório.
Intercâmbio: os protocolo OpenID, OAuth2 e SAML são um meio
importante usado para trocar informações de identidade entre dois
domínios de identidade.

18. DAP
(Directory Access Protocol) é um protocolo
de software presente no protocolos X.500 (
uma série de padrões para redes de
computador abordando serviço de
diretório.)

19. LDAP
(Lightweight Directory Access Protocol) é
um protocolo de software para permitir que
qualquer pessoa localize organizações,
indivíduos e outros recursos, como arquivos
e dispositivos em uma rede, na Internet
pública ou na intranet corporativa.
A versão atual é LDAPv3, especificado em
uma série de RFC como mostra o RFC 4510

20. AD
O Active Directory (AD) é um serviço de diretório
desenvolvido pela Microsoft para redes de domínio do
Windows.
Uma equipe pode acessar os recursos com contas
gerenciadas em um domínio do Active Directory.

21. ADeLDAPsãoduascoisasdiferentes
masestãototalmenteinterligadas

22. ArelaçãoentreADeLDAPémuitoparecida
comarelaçãoentreoApacheeHTTP

23. ADxLDAP
O HTTP é um protocolo de comunicação entre sistemas de
informação.
Apache é um servidor web que usa o protocolo HTTP.
LDAP é um protocolo de serviços de diretório.
Active Directory é um servidor de diretório que usa o protocolo
LDAP.
Active Directory é apenas um exemplo de um serviço de diretório que
suporta LDAP.

24. SCIM
O System for Cross-Domain Identity Management (SCIM) é um
padrão que define esquema e protocolo para gerenciamento de
identidade.
O SCIM está surgindo como um padrão para gerenciamento de
usuários e grupos e geralmente é usado no lugar do protocolo LDAP
tradicional.

25. SCIM
O SCIM fornece a flexibilidade que é necessária para implementações
de REST HTTP, entre empresas e de aplicativo em nuvem.
Como muitos serviços de nuvens não oferecem uma interface LDAP, é
possível usar o SCIM independente dos protocolos subjacentes.

26. O TGT ( Ticket Granting Ticket ) é uma
espécie de credencial concedida ao
usuário pelo AS, parte do KDC, do
Kerberos. Este usuário precisa do TGT
para fazer requisições de serviços
específicos. Quando o programa que
ele está usando faz uma requisição de
um ticket para um servidor Kerberos,
este irá solicitar o login e a senha do
usuário.
TicketGrantingTicket(TGT)

27. TicketGrantingTicket(TGT)
O servidor responde à requisição do
ticket enviando o ticket- granting-
ticket. Dessa forma, somente este
usuário é capaz de decriptar o TGT.
O ticket granting ticket expira
algumas horas após sua concessão,
para evitar invasões e falsificações, e é
necessário para que o usuário tenha
acesso ao Ticket Granting Server, TGS.

28. Kerberos
Kerberos é um protocolo de
autenticação de rede. Ele foi projetado
para fornecer autenticação forte para
aplicativos cliente / servidor usando
criptografia de chave secreta. Uma
implementação gratuita deste
protocolo está disponível no
Massachusetts Institute of
Technology

29. RADIUS
O Remote Authentication Dial-In User
Service (RADIUS) é um protocolo de
rede que fornece gerenciamento
centralizado de Authentication,
Authorization e Accounting (AAA ou
Triple A) para usuários que conectam e
usam um serviço de rede.

30. SAML
O Security Assertion Markup Language
(SAML) é um formato de dados padrão
aberto e baseado em XML para a troca
de dados de autenticação e autorização
entre as partes, em particular, entre um
provedor de identidade e um provedor
de serviços. SAML é um produto do
Comitê Técnico de Serviços de
Segurança OASIS.

31. Slidereservadoparapiada
doOASIS-Wonderwall

32. OpenID
OpenID é um padrão aberto para
autenticação, promovido pela
organização sem fins lucrativos OpenID
Foundation.
Um usuário deve obter uma conta
OpenID através de um provedor de
identidade OpenID (por exemplo,
Google).

33. OpenID
O usuário usará essa conta para fazer
login em qualquer site (a parte confiável)
que aceite a autenticação OpenID (pense
no YouTube ou em outro site que aceite
uma conta do Google como login). O
padrão OpenID fornece uma estrutura
para a comunicação que deve ocorrer
entre o provedor de identidade e a
terceira parte confiável.

34. Oauth2
OAuth 2 é uma estrutura de
autorização que permite que
aplicativos obtenham acesso limitado
a contas de usuário em um serviço
HTTP, como Facebook, GitHub e
DigitalOcean.

35. Oauth2
O OAuth2 fornece acesso delegado seguro,
o que significa que um aplicativo, chamado
cliente, pode executar ações ou acessar
recursos em um servidor de recursos em
nome de um usuário, sem que o usuário
compartilhe suas credenciais com o
aplicativo.

36. Oauth2
O OAuth2 faz isso permitindo que os
tokens sejam emitidos por um provedor de
identidade para esses aplicativos de
terceiros, com a aprovação do usuário. O
cliente usa o token para acessar o servidor
de recursos em nome do usuário.

37. IAMGerenciamento de acesso à identidade
02

38. IAM
O gerenciamento de acesso à identidade (IAM) ou simplesmente
gerenciamento de identidade é uma categoria de ferramentas de software
que permite que empresas de todos os tamanhos gerenciem geralmente as
identidades e os direitos de acesso de todos os seus funcionários. Essa é
uma caracterização ampla e é intencionalmente: Existem muitas
ferramentas diferentes que se enquadram no guarda-chuva de software de
gerenciamento de identidades ou gerenciamento de acesso a identidades.

39. SSO significa Single Sign On e permite
que funcionários de uma empresa façam
login em todos seus serviços com um
único clique. SSO usa um portal que
centraliza e mostra todas as aplicações
que sua empresa tem configurado para o
Single Sign On
SingleSignOn-SSO

40. O MFA fornece uma segunda camada
crucial de segurança, além das senhas
normais, que podem ser facilmente
compartilhadas ou comprometidas. O
MFA consiste em códigos únicos gerados
por aplicativos no seu telefone ou em
chaves físicas como Yubi Keys que você
conecta à sua máquina e concedem acesso
quando você tenta fazer login.
Multi-factorauthentication-MFA

41. Em relação à funcionalidade de logon
único, essas ferramentas permitem que os
administradores definam permissões de
acesso ao software de gerenciamento de
identidades com base no nível e grau de
acesso que um funcionário específico
possui.
Quanto melhor o software, mais
granulares as permissões podem ser
definidas.
Rolebasedaccess-RBAC

42. —SOMEONEFAMOUS
“This is a quote. Words full of
wisdom that someone important
said and can make the reader get
inspired.”

43. Zentyal03Easy Linux alternative to Windows Server

44. O Zentyal Server é um aplicativo open
source de web decorrente da evolução da
plataforma eBox, que começou a ser
utilizada em 2004.
Atualmente seu código base pertence à
eBox Technologies, e o código fonte está
disponível de acordo com os termos da
licença pública geral GNU.
ZentyalServer

45. O Zentyal Server é capaz de realizar
tarefas de gateway, infraestrutura de
rede, gerenciamento unificado de
ameaças (UTM) e solução para escritórios
e comunicações.
ZentyalServer

46. O desenvolvimento do Zentyal foi iniciado no início
de 2004 e atualmente é uma alternativa de código
aberto para o Windows Small Business Server.
ZentyalServer

47. Mesmo sendo um software que administra a rede
completamente, não é necessário um hardware topo
de linha em sua instalação.
Uma VM ou Bare Metal com 1Gb de RAM e 5 Gb de
espaço em HD é o suficiente.
ZentyalServer

48. As funcionalidades do Zentyal podem ser agrupadas.
Vejamos quais são estes grupos e algumas dessas
funcionalidades.
Mail: permite a interação com o Microsoft Outlook e
possui compatibilidade com o Microsoft Active Directory
(integração com Samba4.1).
Controla o sistema de e-mails, calendários, contatos e
webmail.
Também é capaz de sincronizar dispositivos móveis com
segurança, pois possui antivírus e AntiSpam.
ZentyalServer

49. Infraestrutura: trabalha com servers DNS, DHCP, NTP,
VPN e autorizações.
Network: lida com interfaces estáticas e DHCP, com filtro
de pacotes e port forwarding.
Possui firewall avançado, routing, traffic shaping e QoS,
entre outras propriedades.
ZentyalServer

50. Domínios e diretórios: Tem um gerenciamento central de
grupos usuários e equipes em forma de árvore.
Lida com autenticações, permissões e compartilhamentos
de arquivos com o sistema operacional Windows.
Também agrega Single Sign-On, unidades organizacionais
múltiplas e gerenciamento de impressoras.
ZentyalServer

51. Para maiores informações acesse:
http://www.zentyal.org
Caso tenha dúvidas, utilize o fórum em
português:
http://forum.zentyal.org/index.php?board=9.0
ZentyalServer

52. eoPHP?04Criando o logon único...

53. SSO

54. SSO

55. ATIMELINEALWAYSWORKSFINE
Aplicação
Monolítica Legada
Aplicação em
Wordpress
Aplicação YII2
Aplicação Laravel
para emissão de
NF, NFE, Boletos
CRM/ERP/SCM I
Portalde
Soluções
CRM/ERP/SCM II
Invoices

56. O SSO Server é o serviço responsável pela
autenticação do usuário e por registra os Brokers.
Somente os Brokers registrados podem tentar fazer
login no SSO Server.
SSOServer

57. O Broker é a aplicação (pagina web, api, etc) que
você quer permitir que o usuário acesse após se
autenticar no SSO Server.
Cada Broker possui um ID e uma chave privada que
é utilizada para fazer a conexão entre o Broker e o
SSO Server.
Quando uma nova requisição é feita por um Broker,
este recebe do SSO Server um token referente a
requisição, no ambiente em qual ele foi requisitado.
Broker

58. Client é quem deseja se autenticar no SSO Server
para acessar conteúdos que são disponibilizados
pelos Brokers.
Client

59. Um cliente no nosso caso é um funcionário.
O funcionário possui credenciais de acesso a
aplicação e elas que são utilizadas para autenticar no
SSO Server.
O funcionário só pode se autenticar através de
algum Broker.
Comofuncionatudoisso?

60. Comofuncionatudoisso?
No exemplo que estamos utilizando, nós temos,
então, alguns Brokers:
Broker App Monolítica (BAM)
Broker App Portal (BAP)
Broker App API (BAA)

61. Comofuncionatudoisso?
Quando um Client instancia um BAM via Browser,
por ex., o Broker vai até o SSO Server e se autentica.
Após se autenticar, ele devolve para o Client um
Cookie com um hash único que o identifica, dentro
daquela instância.

62. Aqui podemos ver como o SSO
server visualiza os requests dos
Brokers,
SSOServer

63. Páginaspúblicasnósnãoautenticamos
oBrokernoSSOServer

64. Masseoconteúdoforprivado,
comovocêfazentão?

65. BrokerSessionManager
Cada aplicação tem sua própria gerência de sessão.
Se um Client requisitar um conteúdo privado, o
Broker Session Manager é acionado para verificar se
o Client possui sessão ativa.

67. https://github.com/jacksonfdam/php-sso

68. Referências
★ https://blog.varonis.com.br/o-que-e-saml-e-como-funciona/
★ https://auth0.com/blog/how-saml-authentication-works/
★ https://docs.microsoft.com/pt-br/azure/active-directory/develop/single-sign-on-saml-protocol
★ https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/
★ https://www.getkisi.com/blog/authentication-protocols-overview
★ https://www.getkisi.com/blog/physical-security-assessment-problems-it-can-uncover
★ https://www.getkisi.com/blog/identity-access-management-tools
★ https://blog.varonis.com.br/entenda-a-diferenca-entre-active-directory-e-ldap/
★ https://ldapwiki.com/wiki/OAuth%202.0
★ https://medium.com/laraveltips/single-sign-on-sso-server-laravel-5-6c7c70858c63

69. ★ https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
★ https://en.wikipedia.org/wiki/Single_sign-on
★ https://en.wikipedia.org/wiki/Ticket_Granting_Ticket
★ https://www.gta.ufrj.br/grad/07_1/kerberos/ConsideracoesIniciais.html
★ https://www.3way.com.br/protocolo-kerberos/
★ https://en.wikipedia.org/wiki/Identity_management
★ https://en.wikipedia.org/wiki/Identity-management_system
★ https://www.linux.ime.usp.br/~cef/mac499-06/monografias/erich/html/ch01s06.html
★ https://pt.wikipedia.org/wiki/Active_Directory
★ https://pt.wikipedia.org/wiki/OpenLDAP
Referências

70. Qualquer dúvida, crítica ou sugestão só me procurar:
@jacksonfdam
jacksonfdam@gmail.com
Obrigado!