Closed glaubervila closed 8 months ago
@gschwend Está tarefa ficou bloqueada, hoje encontrei uma incompatibilidade que não me permite continuar por enquanto. Vai ser necessário separar o Daiquiri do Science Server. Por separar eu quero dizer que vai precisar ter uma URL independente, e uma configuração independente no SATOSA.
O problema é que um dos endpoints de autenticação é configurado para retornar com os dados do usuario de volta para a app que solicitou a requisição. Essa configuração ocorre em 2 lugares no satosa que tem fixo a url que solicita o login. E no container do shibboleth que possui um apache configurado para retonar a solicitação de volta para a aplicação.
Nos 2 casos são configurações NÃO dinamicas. tentei contornar colocando 2 container shibboleths no lado da aplicação mas não adiantou pq falhou no lado do Satosa.
Acredito que agora é conversar com @carlosadean para chegarmos a uma solução.
Abaixo deixo as 2 configs que citei:
Satosa: Arquivo: /home/deployer/satosa/config/metadata/scienceserver-dev.xml
<md:Extensions>
<init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://scienceserver-dev.linea.org.br/Shibboleth.sso/Login"/>
</md:Extensions>
Pelo que eu entendi o Satosa tem fixo a url que ele espera que faça a requisição: Location="https://scienceserver-dev.linea.org.br/Shibboleth.sso/Login"
E no container gidlab (Shibboleth com Apache) Tem uma rota Shibboleth.sso que redireciona para o container do backend da aplicação.
<VirtualHost *:80>
ServerName https://scienceserver-dev.linea.org.br:443
UseCanonicalName On
ProxyPassMatch /Shibboleth.sso !
ProxyPass / uwsgi://lsp_daiquiri:8000/`
Essas configurações envolvendo o módulo shibboleth do apache são um pouco sensíveis, pois é necessário estabelecer a relação de confiança entre o SP, no caso o daiquiri ou o scienceServer, com o IdP, representado nesse caso pelo satosa. Sem isso, a autenticação não vai funcionar.
De qualquer modo, me parece que a escolha por separar as aplicações é a correta e vai de encontro ao que já havíamos definido, que o Daiquiri deve estar fora do guarda-chuvas do ScienceServer como uma aplicação independente @glaubervila
@glaubervila @carlosadean pedido para novo CNAME no ticket #14253.
@carlosadean Deixei pronto o ambiente do userquery, coloquei o container do shibboleth e configurei as rotas que eu sabia. e copiei a pasta com as configs do science server.
A url https://userquery-dev.linea.org.br já está no ar e a porta interna a ser usada é a 8096.
A url https://userquery-dev.linea.org.br já está no ar e a porta interna a ser usada é a 8096.
@carlosadean Agora falta a parte do SAML/Shibboleth, eu apenas copiei toda a pasta do shibboleth do science server. Eu não conheço os arquivos de configuração, imagino que vc precise criar novas chaves e fazer a relação entre o shibboleth e o satosa.
@glaubervila concluímos a configuração do shibboleth entre o userquery e o satosa, no entanto, notamos duas coisas:
Importante Achei essa referencia a uma biblioteca que integra com protocoloc SAML: https://github.com/SAML-Toolkits/python3-saml/tree/master https://varun-sharma.medium.com/mastering-the-implementation-of-saml-2-0-authentication-in-django-91d381fd55e7 https://github.com/KristianOellegaard/django-saml-service-provider
Reference: https://www.g-vo.org/edp-forum-2018/slides/asterics2018-daiquiri-galkin.pdf