Um Estudo Sobre Autenticação Federada no Acesso a
Recursos Computacionais por Terminal Remoto Seguro
Marcelo M. Galheigo, Antônio Tadeu A. Gomes Laboratório Nacional de Computação Científica (LNCC/MCTI) Av. Getúlio Vargas, 333 – Quitandinha, Petrópolis/RJ – 25651-075
{galheigo,atagomes}@lncc.br
Resumo. O primeiro objetivo deste artigo curto é apresentar os resultados
preliminares de nosso estudo de métodos para autenticação federada em recursos computacionais por terminal remoto seguro usando o protocolo SSH. Esses resultados apontam para a inexistência de uma solução que mantenha a interface de acesso típica dos terminais remotos seguros e não leve à reformulação ou reconfiguração dos provedores de identidade de uma federação. Nesse sentido, outro objetivo deste trabalho é apresentar o desenho de uma solução com as características supracitadas. Planejamos empregar essa solução no acesso remoto por linha de comando na grade computacional do Sistema Nacional de Processamento de Alto Desempenho – SINAPAD. Vislumbramos, contudo, que a solução possa ser adaptada em outros contextos.
1. Introdução
Federações de identidade permitem que a identidade eletrônica de indivíduos possa ser armazenada e utilizada entre sistemas de gestão de identidade distintos [Shim et al., 2005]. No contexto da Internet, diversas soluções de federação de identidade têm sido desenvolvidas e adotadas. Em geral essas soluções têm como base as tecnologias de web. Dentre elas, podemos citar a linguagem SAML [SAMLCoreV2, 2005], adotada na solução Shibboleth1
, e os protocolos OAuth [RFC6749, 2012] e OpenID [OpenIDCoreV1, 2014], adotados em serviços como Google, Twitter e LinkedIn. Um elemento fundamental dessas soluções é a funcionalidade de Single Sign-On – SSO. Apesar do amplo uso dessa funcionalidade em aplicações web, o mesmo não acontece com aplicações “não-web”. Um exemplo desse tipo de aplicação, de particular interesse para este trabalho, é o de acesso a recursos computacionais por terminal remoto seguro. Essa modalidade de acesso é empregada em grande parte na administração de recursos computacionais remotos, mas também tem seu uso difundido entre usuários de recursos especializados, como os providos por grades e clusters computacionais para a execução de aplicações de processamento de alto desempenho (HPC – High-Performance Computing). A solução para essa forma de acesso mais amplamente empregada nos dias de hoje é provavelmente por intermédio do protocolo SSH [RFC4251, 2006].
O primeiro objetivo deste artigo é apresentar os resultados preliminares de nosso estudo de soluções de autenticação federada para acesso SSH. Esses resultados apontam para a inexistência de uma solução que mantenha a interface de acesso típica dos terminais remotos seguros e não impacte na reformulação ou reconfiguração dos provedores de identidade (IdPs – Identity Providers) de uma federação. Nesse sentido, outro objetivo deste trabalho é apresentar uma solução concebida em nosso projeto SSH
1
http://www.shibboleth.net
Federated remote authentication – SFera –, que faz parte do Programa de Gestão de Identidade da RNP. A característica chave dessa solução é a de tentar concentrar as adaptações necessárias, o quanto possível, nos provedores de serviço (SP – Service Providers). O raciocínio no qual essa solução se baseia é o de que SPs são os principais interessados em facilitar o acesso dos usuários aos seus serviços.
O restante deste artigo está organizado como se segue. Na Seção 2, levantamos um conjunto básico de requisitos que julgamos importantes para uma solução de autenticação federada no acesso remoto por terminal seguro. Na Seção 3, apresentamos as soluções estudadas e discorremos sobre suas vantagens e desvantagens. Na Seção 4, apresentamos em linhas gerais a solução sendo concebida como parte de nosso projeto SFera. Por fim, na Seção 5 apresentamos nossas considerações finais.
2. Requisitos
Em nosso estudo, consideramos os seguintes requisitos para a adoção de soluções de autenticação federada para acesso SSH tanto pelos usuários como pelos IdPs e SPs: • A solução precisa ser intuitiva para o usuário. Idealmente, o usuário deveria
informar apenas dados referentes a sua autenticação federada na própria tentativa de acesso SSH (seja em linha de comando ou com uma aplicação como PuTTY2
); • A solução não pode impactar na reformulação/reconfiguração de IdPs e demais
componentes de gestão de identidades de uma federação, uma vez que isso implicaria em mudanças que afetariam a federação como um todo. Isso envolve também manter a liberdade de cada IdP implementar a sua interface de autenticação; • Como decorrência do requisito anterior, as funcionalidades adicionais necessárias à
solução devem ser de inteira responsabilidade dos SPs;
• O cliente SSH deve poder ser configurável para acionar módulos de verificação adicionais que dependam das características de um SP particular. Um exemplo dessa necessidade é o da obrigatoriedade de um usuário de uma grade computacional de preencher eletronicamente um termo de compromisso de bom uso dos recursos dessa grade, antes do acesso efetivo a esses recursos.
3. Estudo das soluções existentes
Nosso estudo abordou as seguintes soluções: a tecnologia Moonshot,3
cujo desenvolvimento é liderado pela rede acadêmica britânica Ja.net; os Serviços para Transposição de Credenciais de Autenticação Federadas – STCFed4 – desenvolvidos pela UFSC em parceria com a Rede Nacional de Ensino e Pesquisa – RNP; e as extensões à solução Shibboleth para autenticação não-web.5
3.1 Moonshot
Moonshot é uma tecnologia que emprega o protocolo RADIUS/RADSEC [RFC6614, 2012], a API GSS e o protocolo EAP [RFC7055, 2013] como base para autenticação federada. Essa mesma arquitetura, à exceção da API GSS, é utilizada no serviço Eduroam para autenticação federada em redes wifi.6
A infraestrutura do Moonshot contempla 3 elementos principais: o Moonshot IdP/Trust Router, o Moonshot Server e o Moonshot Client. O Moonshot IdP/Trust 2 http://www.putty.org 3 https://www.ja.net/products-services/janet-futures/moonshot 4 https://www.rnp.br/pd/gts2010-2011/gt_stcfed2.html 5 https://github.com/biancini/Shibboleth-Authentication/wiki 6 http://www.eduroam.org
Router engloba os componentes da infraestrutura que fornecem a identidade do usuário, como o servidor RADIUS, sua base de usuários (p.ex. LDAP) e sua conexão com a federação de identidades (caso exista). O Moonshot Server contém o SP Shibboleth e o serviço que se deseja disponibilizar na federação. O Moonshot Client é o cliente final propriamente dito que quer ter acesso ao serviço por meio de uma autenticação federada. Em todos os elementos da infraestrutura Moonshot é necessário o uso da API GSS para asserção dos atributos do usuário, validação das credenciais do mesmo no momento de sua autenticação, e envio dessas credenciais através do protocolo EAP. 3.1.1. Utilização para acesso SSH
Entre as várias aplicações não-web com as quais o Moonshot pode ser utilizado, está o SSH. A integração do SSH com o Moonshot se dá via servidor SSH através da API GSS. Nesse cenário, o Moonshot Server é constituído do servidor SSH e do SP Shibboleth. Para a integração, além das configurações referentes ao Moonshot Server, é necessário também a configuração do servidor SSH para utilização da API GSS (na implementação do Moonshot é usado o módulo OpenSSH). É possível ainda definir qual dos atributos SAML obtidos no momento da autenticação será utilizado como credencial no acesso SSH, através de configurações no SP Shibboleth. Feito isso, para receber e autorizar credenciais GSS-EAP oriundas do Moonshot Client é preciso iniciar um servidor que ofereça a API GSS. No Moonshot Client, apenas as configurações referentes ao Moonshot são necessárias. Feitas essas configurações, basta que o usuário informe sua credencial de usuário federado e as envie ao Moonshot Server através de uma ferramenta cliente da API GSS.
Após esses procedimentos, o servidor Moonshot/OpenSSH/Shibboleth está pronto para receber acessos SSH do cliente que enviou sua credencial GSS-EAP através da ferramenta cliente da API GSS.
3.1.2. Vantagens e desvantagens
Assumindo que todas as instituições da federação possuam previamente a infraestrutura RADIUS implantada (p.ex., pela utilização do Eduroam), a implantação da infraestrutura Moonshot na federação é simples. A interface com o usuário é transparente, sem a necessidade de modificações no cliente SSH, apenas o envio da credencial GSS-EAP ao servidor Moonshot via ferramenta externa. Contudo, há a necessidade de instalação dos módulos Moonshot em todas as camadas da infraestrutura, bem como configuração prévia também na máquina cliente. Além disso, as credenciais ficam expostas em um arquivo texto oculto na máquina do usuário. 3.2 STCFed
Os serviços STCFed se baseiam na emissão e validação de credenciais diferentes das aceitas pelo Shibboleth. Eles empregam o “IdP+”, uma extensão da implementação de IdPs do Shibboleth acrescida de 3 serviços: o Secure Token Service – STS –, o Credential Translation Service – CTS – e o Serviço Gerador de Certificados – SGC. Além disso, para emissão de certificados o IdP+ conta com uma Autoridade Certificadora – AC – confiável para emissão de certificados, como o da infraestrutura ICPEdu da RNP7
ou o MyProxyCA8
em um modelo auto-confiável, por exemplo.
O STS é um serviço web implementado nos moldes da especificação WS-Trust [WS-Trust-1.3, 2012] e responsável pela ponte entre o IdP Shibboleth e a aplicação não-web. O CTS é responsável pela tradução das credenciais obtidas pela autenticação na
7 https://www.rnp.br/servicos/icpedu.html 8
http://grid.ncsa.illinois.edu/myproxy/ca/
federação em outros padrões, como o X.509. Essa tradução é feita obtendo as informações do usuário autenticado, através da asserção SAML de seus atributos disponíveis na federação. O SGC emite o certificado X.509 assinado pela AC confiável, utilizando os atributos SAML do usuário federado.
3.2.1. Utilização para acesso SSH
O SSH é uma das várias aplicações com os quais os serviços STCFed podem ser utilizados. A integração do SSH com esses serviços se dá via servidor SSH através do módulo GSI-OpenSSH do toolkit Globus de implementação de grades computacionais.9 Para isso, o servidor OpenSSH deve ser devidamente configurado para utilização desse módulo e da Autoridade Certificadora – AC – que emitirá os certificados dos usuários federados.
Para o acesso SSH federado, o usuário deve acessar uma aplicação web de geração de certificados. Caso o usuário não esteja ainda autenticado na federação, este será redirecionado ao site de autenticação do IdP+. Após a autenticação, a asserção SAML é utilizada pelo CTS para fazer a tradução das informações do usuário na requisição do certificado a ser enviada pelo SGC à AC confiável. Uma vez que a AC emita o certificado do usuário, este é devolvido à aplicação web, que o disponibiliza para download pelo usuário. De posse do certificado assinado pela AC, o usuário poderá acessar o servidor SSH utilizando a autenticação com base em certificado X.509.
3.2.2. Vantagens e desvantagens
A solução com STCFed (usando o IdP+) não exige a instalação de ferramentas adicionais na máquina cliente. Uma vez que o usuário possua o certificado e o servidor SSH esteja configurado para aceitar aquele certificado, o acesso SSH é transparente para o usuário. Contudo, independente da forma como a emissão de certificados pela(s) CA(s) é gerida (seja ela centralizada pelo administrador da federação ou distribuída entre os IdPs), o IdP+ traz para a camada que provê a identidade a responsabilidade de prover o serviço de gerência e emissão de credenciais.
3.3 Extensões à solução Shibboleth para autenticação não-web
Essa abordagem envolve uma série de tecnologias, das quais as principais são: a extensão Enhanced Client or Proxy – ECP – do IdP Shibooleth;10 a biblioteca libcurl para manipulação programática de requisições e respostas a sites web;11
e o serviço Name Service Switch – NSS – integrado à interface Pluggable Authentication Modules – PAM – para consulta de informações sobre usuários e tratamento da autenticação dos mesmos em ambiente Unix/Linux12.
3.3.1. Utilização para acesso SSH
Neste modelo, para que o acesso SSH esteja disponível aos usuários federados, é necessária algumas configurações no IdP, no SP e no servidor SSH. Primeiramente devem ser feitas algumas configurações no IdP Shibboleth para habilitar o módulo ECP e para a utilização do método de autenticação HTTP Básica. Isso se deve ao fato de a integração NSS-PAM só permitir esse tipo de autenticação para consumir e inserir valores nas variáveis de login (username e password) do site de autenticação do IdP Shibboleth através da utilização da biblioteca libcurl.
9 http://dev.globus.org/wiki/GSI-OpenSSH 10 https://wiki.shibboleth.net/confluence/display/SHIB2/ECP 11 http://curl.haxx.se/libcurl/ 12 https://amd.co.at/adminwiki/PAM/NSS
No provedor de serviço SP Shibboleth é feita a configuração para informar que a autenticação básica no IdP também será aceita. Após isso é configurada a integração NSS-PAM no servidor SSH do SP. Após essas configurações, o servidor SSH do SP já está apto a receber autenticações federadas.
3.3.2. Vantagens e desvantagens
Essa abordagem não exige a instalação de ferramentas na máquina cliente. Além disso, uma vez que o servidor SSH esteja configurado para integração com o IdP Shibboleth via NSS-PAM, o acesso SSH é transparente para o usuário. Contudo, ela envolve uma série de configurações a serem feitas na camada do IdP Shibboleth, o que pode trazer dificuldades em sua operacionalização na federação. A exigência de os sites de autenticação dos IdPs Shibboleth serem padronizados para o método de autenticação HTTP Básica é um fator limitante a flexibilidade natural inerente ao contexto de federação, onde em princípio cada IdP teria liberdade de implementar seu método de autenticação. Há ainda o fato de esta abordagem não suportar o uso do serviço Where Are You From - WAYF – pelo usuário federado, sendo este limitado a um único IdP acessível pelo servidor SSH.
3.4 Análise geral das soluções
Foi possível identificar que cada uma das soluções analisadas acima é aplicável no acesso SSH a recursos computacionais. Porém, nenhuma delas atende plenamente todos os requisitos apresentados na Seção 2.
4. O Projeto SFera
O projeto SFera visa fornecer mecanismos de acesso SSH federado de forma a atender os requisitos apresentados na Seção 2. Seu objetivo é prover uma interface o mais transparente possível para o usuário final, eximindo os IdPs da responsabilidade de prover e administrar tal serviço. Para alcançar esse objetivo, desenhamos uma solução, ilustrada na Figura 1, cuja implementação pode ser concentrada totalmente no SP que desejar ofertar o serviço de acesso SSH federado. Essa solução prevê ainda que o usuário possa escolher qual é o seu IdP de origem através do serviço WAYF. Há também uma maior flexibilidade nesta solução através do conceito de integração de módulos de verificação de terceiros.
Na implementação desta solução planejamos usar o módulo ECP do IdP Shibboleth e a biblioteca libcurl, bem como implementar um plug-in para o servidor OpenSSH de modo que esse possa estender as funcionalidades de seleção do IdP de origem a partir do serviço WAYF bem como ser acoplado a módulos de verificação de terceiros. Uma vez que essa abordagem permita que o usuário selecione seu IdP de origem, uma dificuldade desta solução é garantir a flexibilidade/heterogeneidade do site de autenticação de cada IdP da federação. Para isso é preciso implementar wrappers que permitam a injeção das credenciais do usuário para o site de autenticação do IdP de origem de forma customizada. Esses wrappers podem usar diferentes tipos de credenciais – como username/password, CPF/password, e-mail/password, entre outras – de acordo com o exigido pela instituição provedora da identidade. Porém, essa complexidade pode ser encapsulada no provedor de serviços, que é o principal interessado em facilitar o acesso dos usuários.
5. Considerações finais
O problema da identificação de com qual IdP um usuário está associado é particularmente complexo em aplicações não-web, como no acesso SSH. Essa
complexidade reside no fato de que os subsistemas de autenticação dessas aplicações são em geral pobres semanticamente para lidar com a autenticação federada. No entanto, os blocos chave para adicionar essa funcionalidade estão disponíveis, como explorado nas soluções estudadas neste trabalho, sendo importante identificar os requisitos que são de fato importantes para cada tipo de aplicação. Esperamos que os passos seguintes deste trabalho – fundamentalmente, a implementação completa da solução desenhada e sua comparação com outros trabalhos, p.ex. [Wangham et al., 2012] – possam validar nossas escolhas acerca da concentração da complexidade da solução para autenticação federada de acesso SSH na implementação dos SPs.
Figura 1. Arquitetura da solução SFera.
Referências
[OpenIDCoreV1, 2014] The OpenID Foundation. N. Sakimura, J. Bradley, M. Jones, B. de Medeiros e C. Mortimore (Eds.), “OpenID Connect Core 1.0,” Fevereiro de 2014.
[RFC4251, 2006] IETF. T. Ylonen e C. Lonvick, Ed., “The Secure Shell (SSH) Protocol Architecture”, RFC 4251, Janeiro de 2006.
[RFC6749, 2012] IETF. D. Hardt (Ed.), “The OAuth 2.0 Authorization Framework”, RFC 6749, Outubro de 2012.
[RFC6614, 2012] IETF. S. Winter, M. McCauley, S. Venaas e K. Wierenga, “Transport Layer Security Encryption for RADIUS”, RFC 6614, Maio de 2012.
[RFC7055, 2013] S. Hartman (Ed.) e J. Howlett, “A GSS-API Mechanism for the Extensible Authentication Protocol”, RFC 7055, Dezembro de 2013.
[SAMLCoreV2, 2005] OASIS. S. Cantor, J. Kemp, R. Philpott, e E. Maler (Eds.), “Assertions and Protocol for the OASIS Security Assertion Markup Language V2.0”, Março de 2005. [Shim et al., 2005] S.S.Y. Shim, G. Bhalla, e V.S. Pendyala, Federated Identity Management.
In: Proceedings of IEEE Computer. 2005, 120-122.
[WS-Trust-1.3, 2012] OASIS Standard. A. Nadalin, M. Goodner, M. Gudgin, A. Barbir, e H. Granqvist (Eds.), “WS-Trust 1.3 Errata 01”, 25 de abril de 2012.
[Wangham et al., 2012] M.S. Wangham, E.R. Mello, D.S. Böger, J.S. Fraga, e M.C. Guérios. Geração de Certificados Digitais a partir da Autenticação Federada Shibboleth. In: Anais do XII Simpósio Brasileiro de Segurança da Informação e de Sistemas Computacionais (SBSeg), 2012.
