AUTENTICAÇÃO ÚNICA ENTERPRISE SINGLE SIGN ON

AUTENTICAÇÃO ÚNICA ENTERPRISE SINGLE 

SIGN­ON

Jann Claude Mousquer1_{, João Paulo de Lima Barbosa}1_{, Kenner Alan Kliemann}1 1_{Faculdade Anglo Americano ­ FAA}

Foz do Iguaçu, PR – Brasil

{jannclaude,kenner.hp}@gmail.com, joao@barbosa.net.br

Abstract.  This   paper   describes   an   overview   about   centralized   user authentication in enterprise environments utilizing the concepts of single sign­ on and the Central Authentication Service protocol, and their importance to Cloud Computing.

Resumo.  Este artigo descreve a contextualização sobre autenticação única para   usuários   em  ambientes   empresariais,   abordando  os   conceitos   Single Sing­On (SSO) e o protocolo Central Authentication Service (CAS), bem como sua importância na nuvem (Cloud Computing). Palavras Chaves: Single Sign­on, CAS, Autentication. 1. Introdução No panorama atual, onde usuários no meio corporativo acessam diversas aplicações e serviços em uma elevada frequência, torna­se necessário a aplicação de técnicas de autenticação, para proporcionar agilidade e ao mesmo tempo segurança ao tentarmos nos conectar a determinado serviço.        A autenticação é o processo de determinar se alguém é , de fato, quem ou o que é declarado. Em redes de computadores privadas e públicas (incluindo a Internet), a autenticação é comumente feita através de credênciais de acesso. O conhecimento da senha é assumido como garantia de que o usuário é autêntico. O ponto fraco deste sistema para transações que são significativas é que as senhas podem ser roubadas, reveladas ou esquecidas. Por esta razão , as empresas exigem processos de autenticação mais rigorosos.      O número de logins e senhas que usuários de modo geral devem gerenciar diariamente   é   atualmente   uma   fonte   de   frustração,   perda   de   produtividade   e insegurança.

Algumas credenciais exigem ainda, diferentes informações ao usuário, vários requisitos de complexidade de senhas e renovação forçada em intervalos de tempo cada vez mais curtos. 

       No meio corporativo onde não há autenticação centralizada, o número de logins que um funcionário deve gerenciar  cresce com  a implantação  de cada  novo aplicativo ou serviço.

    O setor de suporte muitas vezes atribui a responsabilidade de resetar senhas perdidas para funcionários. Todos esses fatores contribuem para o risco de segurança e incrementa os custos de suporte onde algumas organizações podem não ter recursos para resolver.(BUECKER, 2012) As diretivas LDAP, ressalta Aubry et al.(ESUP Portail), salvam os cérebros dos usuários ao fazê­los memorizar apenas uma senha, porém seus dedos ainda são muito procurados por todas as autenticações que precisam digitar, na prática, toda vez em que acessa à aplicação. 

Para   fornecer   um   método   de   login   centralizado   e   seguro,   Schumacher   et al(SCHUMACHER, 2006) cita os seguintes pontos que deverão ser considerados:

•   Os   usuários   não   necessitem   fornecer   sua   senha   para   cada   aplicação

separadamente, de acordo com sua política de segurança; • Forçar os usuários a identificar­se várias vezes, para evitar uso indevido de uma sessão do usuário que é deixado aberta por algum tempo; • Aplicativos que sejam independente do esquema de autenticação utilizado; • Novas aplicações devem se integrar facilmente ao esquema de autenticação; • Tanto um single sign­on e um single sign­out. Isso significa que o usuário deve

manter   a  sessão,   enquanto   ele  estiver  ativo,  independentemente   do  concreto back­end que ele interage. Por outro lado, quando um usuário faz logoff, sua sessão deve ser encerrada, de modo que, mesmo quando o navegador é deixado aberto,  ninguém  mais   pode se  conectar   aos servidores  de  back­end  sem  re­ autenticação.

1.1. Objetivo

 A problemática gira em torno dos diversos web­sites e sistemas web, onde em cada um é preciso login e senha para acesso, forçando a memorização de diversas informações, o que pode ser um processo entediante  e inseguro.   Em ambientes  corporativos,  que contam com intranet e proxy, os dados cadastrais são sempre os mesmos, porém é preciso   digitar   as   credenciais   para   todo   e   qualquer   recurso   que   se   deseja   acessar, causando fadiga e má experiência aos usuários.

        O   objetivo   deste   artigo   é   uma   revisão   bibliográfica   sobre   autenticação abordando uma estratégia de arquitetura centralizada que aplique o conceito de Single Sign­On. 2. Autenticação x Autorização x Accounting Identidade pode ser definida como “um conjunto de características próprias e exclusivas de um sujeito”. Mas para que os processos de diferenciação entre os usuários possam ser iniciados, é necessário primeiramente validar a identidade apresentada. E, para entender como isso acontece, Moraes (MORAES, 2013) afirma que é fundamental conhecer a seguinte terminologia: • Autenticação é o processo de verificação de uma identidade alegada, por meio

de   comparação   das   credenciais   apresentadas   pelo   sujeito   com   outras   pré­ definidas. A combinação username/password é muito comum mas vários outros métodos estão disponíveis (certificados digitais, biometria, etc);

• Autorização é o processo que ocorre após a autenticação e que tem a função de

diferenciar   os   privilégios   atribuídos   ao   sujeito   autenticado.   Os   atributos   de autorização  normalmente  são definidos em grupos mantidos em um base de dados   centralizada.   (Cada   sujeito   herda   as   características   do   grupo   a   que pertence);

• Accounting   é   o   processo   por   meio   do   qual   um   equipamento   de   Rede   que

implementa uma política de acesso (accounting client), coleta informações sobre a atividade do elemento autenticado e as envia ao servidor de autenticação.   A   integração   dessas   três   funcionalidades   define   a   arquitetura   AAA (Autenticação, Autorização e Accounting).

3. Single Sign­On

Single   sign­on   (SSO),   destaca   \itext{The   Open   Group}(The   Open   Group),   é   o mecânismo pelo qual uma única ação de autenticação de usuário pode permitir que um usuário possa acessar todos os computadores e sistemas em que ele tem permissão de acesso, sem a necessidade de digitar várias senhas. Single sign­on reduz o erro humano, um componente importante da falha no sistema e é, portanto, altamente desejável, mas difícil de implementar. Algumas de suas vantagens são: • Acesso individual ou em grupo a recursos (aplicações); •  Login único para vários recursos. As identidades e informações dos usuários são armazenados em configurações centralizadas (um ou mais servidores), que são confiáveis para todas as aplicações. Este possui diversas vantagens sobre logins separados em cada máquina cliente da rede local, dentre eles Schumacher et. al. (SCHUMACHER, 2006) cita: • Maior produtividade uma vez que um usuário só precisa se lembrar de uma senha de SSO para acessar todos os recursos de rede ou aplicação; • Administração mais fácil e consistente da segurança de usuários e aplicações; • Integração   mais   simples   e   segura   de   recursos   de   segurança   durante   a

programação dos aplicativos sendo preciso apenas chamar a API SSO;

• Integração   de   administração   de   segurança   para   sistemas   distintos,   ou   seja,

aplicações rodando em diferentes sistemas operacionais e hardwares, etc;

• Menor custo de implementação e manutenção da segurança em toda a empresa.

Serviços de segurança e funcionalidade não precisam ser reconstruídas a partir do zero para cada nova aplicação.(The Open Group)

Com   o   surgimento   do   SSO,   multiplas   soluções   e   implementações   foram construidas, dentre elas AuthWorld cita: (Authentication World)

“Em ambientes Open Source, o principal protocolo é o CAS (Central  Authentication Service).”

4. Cloud Computing

como   acontece   com   outros   desenvolvimentos   significativos   em   tecnologia,   muitos fabricantes aproveitaram o termo "Cloud" e estão usando­o para os produtos que ficam fora da definição comum.(KEPES) Cloud Computing é frequentemente descrito como uma pilha, uma resposta à ampla gama de serviços construídos em cima de um outro apelidado de "Cloud". A definição geralmente aceita de Cloud Computing vem do Instituto Nacional de Padrões e Tecnologia ­ NIST (NIST apud KEPES, p.3). A definição do NIST essencialmente diz que (NIST apud KEPES, p.3): “Cloud Computing é um modelo para acesso conveniente e sob demanda a um   pool   compartilhado   de   recursos   computacionais   configuráveis   (por exemplo, networks, servidores, armazenamento, aplicações e serviços) que podem   ser   rapidamente   disponibilizados   e   liberados   com   esforço   de gerenciamento mínimo ou através de interação com o provedor de serviços.” O que isto significa em termos simples é a simplicidade para usuários finais de utilização das partes dos recursos em massa, e que esses recursos podem ser adquiridos de forma rápida e fácil.(KEPES) Os serviços oferecidos em Cloud são divididos em três classes, Rouse (ROUSE, 2012) os comenta: • Software as a Service (SaaS) é um modelo de distribuição de software em que os

aplicativos   são   hospedados   por   um     fornecedor   ou   prestador   de   serviços   e disponibilizados aos clientes através de uma rede, geralmente a Internet;

• Plataform   as   a   Service   (PaaS)   é   um   paradigma   para   fornecer   sistemas

operacionais   e   serviços   associados   através   da   Internet,   sem   downloads   ou instalação;

• Infraestructure  as  a  Service  (PaaS) envolve   a  terceirização  de  equipamentos

utilizados   para   apoiar   as   operações,   incluindo   o   armazenamento,   hardware, servidores e componentes de rede.   Segundo Chun (CHUN, 2012) as máquinas de legado, equipamentos e redes têm sido um fardo para as empresas manter e gerenciar, e um dos problemas mais difíceis é fazer valer o investimento. A computação em nuvem reduz a carga sobre as organizações de TI corporativos e oferece elasticidade, permitindo que as empresas terceirizem suas necessidades de computação para se concentrar nas soluções dos seus clientes.

5. SSO nas Nuvens

As empresas adotam aplicativos cada vez mais baseados em SaaS, eles querem estender   as  suas  capacidades   de  SSO  para   essas  aplicações.   Isso  significa   que   um usuário pode efetuar login em um aplicativo SaaS com as mesmas credenciais que ele ou ela usa para aplicações corporativas, como o e­mail ou o computador de trabalho. (MITTAL, 2012).

5.1. Central Authentication Service

Single   sign­on   oferece   conveniência   para   o   usuário,   pois   protege­o   tanto   contra   a proliferação   de   credenciais   e   exposição   de   senhas,   centraliza   a   experiência   log­in institucional. (UNICON)  O projeto Central Authentication Service (CAS) (ESTANQUEIRO, 2010), foi inicialmente desenvolvido em 2001 pela Universidade de Yale para autenticação de utilizadores de uma maneira confiável e centralizada. Em Dezembro de 2004, passou a ser um projeto da empresa Jasig.O CAS fornece um serviço de SSO com o seu próprio protocolo, aberto, e com o servidor de autenticação totalmente escrito na linguagem Java. A integração do CAS com as aplicações pode ser ao nível de modulos/filtros no servidor aplicacional ou do lado da aplicação através de bibliotecas/clientes para várias linguagens de programação, como PHP ou ASP.NET.

       Fora da caixa,  CAS suporta  autenticação  de usuários através de senhas validados com LDAP (incluindo Active Directory), bancos de dados, RADIUS e etc. CAS foi projetado desde o início para ser uma plataforma extensível com APIs de plugins bem definidos com base em casos de uso da comunidade.(ESTANQUEIRO, 2010)

       O CAS foi desenhado para ser um produto sem autorização, focando­se apenas   na   autenticação   do   utilizador.   No   entanto,   o   CAS   permite   a   gestão   de autorização de serviços associados ao SSO e escolher que atributos do utilizador a aplicação tem direito a receber. Assim, a aplicação pode criar o seu mecanismo de controle de acesso próprio com base nestes atributos.(ESTANQUEIRO, 2010)     Como se pode observar na figura 1, o processo de autenticação, geralmente, começa com um pedido de um usuário a um recurso protegido, que o redirecciona para a página de login. Este redirecionamento é feito juntamente com a URL para o qual o CAS   vai   enviar   o   usuário   após   a   autenticação   ser   efetuada   (passo   1­2­3).   Esta autenticação   irá   gerar   um   Ticket   Granting   Cookie   (TGC)   ­   uma   longa   cadeia   de caracteres aleatórios que mapeia este cookie ao usuário. E através deste cookie que o utilizador é indexado na memória cache de credenciais no servidor CAS. Se o browser suportar   cookies,   então   o   TGC   é   enviado   para   o   browser   como   um   cookie   não persistente   identificando   um   login   bem   sucedido,   evitando   assim   a   necessidade   de autenticação do servidor CAS para pedidos subsequentes (passos 4­5).(KEPES)

Depois de concluído o processo de autenticação, o CAS redireciona o browser para   o   serviço   pedido,   juntamente   com   um   Service   Ticket   (ST)   ­   outra   cadeia   de caracteres aleatórios que mapeia o utilizador e o serviço pedido (passo 6). A aplicação pode agora extrair o ticket e valida­lo usando o URL de validação do CAS, passando o ticket e o serviço como parametros desta URL (passos 7). Uma validação feita com sucesso resulta na destruição no ticket de serviço e é retornado o nome de utilizador ao serviço   (passos   8).   Finalmente,   o   utilizador   tem   acesso   ao   recurso   pretendido inicialmente (passo 9). Futuros pedidos a servidores/aplicações protegidas pelo CAS não ir ao necessitar que o utilizador se autentique novamente, visto que este já possui todos os tokens necessários para uma sessão SSO.(JASIG)     O CAS também tem suporte para Proxy. Proxy é basicamente um serviço que deseja se comunicar com outro serviço em nome de um utilizador. Isto é possível através de um Proxy­Granting Ticket (PGT) do CAS que permite produzir um Proxy Ticket (PT) que   dá   acesso   ao   serviço   simulando   um   utilizador.   Esta   habilidade   de   proxy   é particularmente importante para serviços, como portais, que desejam comunicar com outros serviços em nome  do utilizador sem perguntar  novamente  pelas credenciais. (JASIG)

       O CAS oferece um protocolo de Single Sign­Out, efetuado quando um utilizador acede a página de logout. Para isto, o CAS envia uma mensagem  HTTP POST à todas as   aplicações   que   estejam   associadas   à   sessão   do   utilizador.   Este   Single   Sign­Out apenas funciona para clientes/linguagens cuja gestão de sessão é mantida do lado do servidor. Isto significa que em aplicações cuja sessão é mantida em cookies no browser do utilizador, a que o CAS nao tem acesso, não participam no protocolo de Single Sign­ Out.(ESTANQUEIRO, 2010)

5.2. Por Que SSO e CAS?!

Central Authentication Service (CAS) é um portal de autenticação única de   código aberto,   que   fornece   controle   de   acesso   centralizado,   e   autenticação   para     recursos baseados   na   web,   semelhante   ao   Yahoo,   Google   e   outros   portais. Mularien(MULARIEN, 2010) destaca que os principais benefícios do CAS são: • Suporte a uma ampla variedade de locais de autenticação (para centralizar a gestão de usuários), fornecendo um ponto único de autenticação e controle para um amplo ambiente multi­máquina; • O suporte amplo de autenticação é fornecido por aplicações Java baseadas ou não baseadas na web através de bibliotecas de clientes CAS; • Um único ponto de referência para credenciais de usuário (através de CAS), para que aplicações clientes CAS não necessitam saber nada sobre as credenciais do usuário, ou como verificar elas. A implementação do protocolo CAS traz diversas vantagens e facilidades, como por exemplo: • O acesso individual ou em grupo a recursos ( aplicações)  pode ser configurado em um único local; • Suporte a uma ampla variedade de locais de autenticação fornecendo um ponto único de autenticação e controle para um amplo ambiente multi­máquina; • Centraliza a gestão de usuários;

• Abstrai   complexidade   de   software   de   várias   aplicações   para   uma   aplicação

central. 5.3. O que é rbCAS  O rbCAS é uma organização de desenvolvedores no github (RBCAS) a fim de manter o projeto CASino.     CASino é um servidor de aplicação Single Sign­On escrito na linguagem de programação ruby. Implementa o protocolo CAS e pode ser utilizado com a maioria das linguagens de programação para web. (CASINO) 6. Conclusão Com a tendência de migração dos sistemas desktop para a núvem, e o crescimento dos chamados SaaS, é inevitável a necessidade de um sistema centralizado de autenticação no meio empresarial. A forma de se utilizar softwares está mudando, e neste processo o Single Sign­On trás uma solução eficiente, segura e financeiramente viável.  6.1. Trabalhos futuros

Após   contextualização   do   tema   e   revisão   bibliográfica,   o   próximo   passo   é   a implementação e deploy do CASino através de um estudo de caso.

Referencias

Single Sign­On Design Guide Using IBM Security Access Manager for Enterprise Single Sign­On; ed. 8.2.; Vervante, 2012. Tradução nossa.

AUBRY Pascal; MATHIEU Vincent; MARCHAL Julien; ESUP­Portail: open source Single   Sign­On   with   CAS   (Central   Authentication   Service).     Disponível   em: <http://www.esup­portail.org/consortium/espace/SSO_1B/cas/eunis2004/cas­

eunis2004­article.pdf>. Acesso em 20 de fevereiro de 2014. Tradução nossa.

The   Open   Group.   Single   Sign­on.   Disponível   em: <http://www.opengroup.org/security/sso/>.   Acesso   em   25   de   fevereiro   de   2014. Tradução nossa.

Authentication   World.   Disponível   em:   <http://www.authenticationworld.com/Single­ Sign­On­Authentication>. Acesso em 02 de maio de 2014. Tradução nossa. SCHUMACHER, Markus et al. Security Patterns: Integrating Secutity  and Systems Engineering. John Wiley & Sons Ltd, 2006 MULARIEN, Peter. Spring Security 3: Secure your web applications against malicious intruders with this easy to follow practice guide. Birmingham: Packt Publishing, 2010. Tradução nossa. KEPES, Ben;   UNDERSTANDING The Cloud Computing Stack SaaS, Paas, IaaS.; Disponível   em:   < http://www.rackspace.com/knowledge_center/whitepaper/understanding­the­cloud­ computing­stack­saas­paas­iaas>. Acesso em 10 de maio de 2014. Tradução nossa. NIST.     NIST   Cloud   Computing   Program.   Disponível   em:

<http://www.nist.gov/itl/cloud/>. Acesso em 10 de maio de 2014. Tradução nossa. ROUSE,   Margaret.;   SPI   model   (SaaS,   PaaS,   IaaS).   Disponível   em:

<http://searchcloudcomputing.techtarget.com/definition/SPI­model>. Acesso em 10 de maio de 2014. Tradução nossa.

MITTAL,   Kunal.;     Extend   single   sign­on   to   the   cloud.   Disponível   em:   < http://www.ibm.com/developerworks/cloud/library/cl­singlesignoncloud/index.html? ca=drs>. Acesso em 10 de maio de 2014. Tradução nossa.

UNICON.;   Central   Authentication   Service   (CAS).;   Disponível   em:   < http://www.unicon.net/opensource/cas>. Acesso em 12 de abril de 2014. Tradução nossa.

MORAES, Alexandre M. S. P.;   Autenticação, Autorização e Accounting: Conceitos

Fundamentais.   Disponível   em:

<http://alexandremspmoraes.wordpress.com/2013/02/15/autenticacao­autorizacao­e­ accounting­conceitos­fundamentais/>. Acesso em 11 de maio de 2014.

CHUN,   Wesley.;   What   is   Cloud   Computing?;   Disponível   em:   < https://developers.google.com/appengine/training/intro/whatiscc>.   Acesso   em   9   de maio de 2014. Tradução nossa. ESTANQUEIRO, Francisco Wallenstein Teixeira;   SINGLE SIGN­ON NA FCUL.; Universidade de Lisboa. 2010. Tradução nossa. JASIG;   CAS Protocol; Disponível em: < http://www.jasig.org/cas/protocol>. Acesso em 20 de fevereiro de 2014. Tradução nossa. RBCAS; Portal do projeto CASino; Disponível em: <http://casino.rbcas.com/>. Acesso

em 15 de fevereiro de 2014. Tradução nossa.

CASino; CASino Rails Engine; Disponível em: <https://github.com/rbCAS/CASino>. Acesso em 15 de fevereiro de 2014. Tradução nossa.