Posts Tagged ‘Ruby on Rails’

Implementando Rubycas Server e Client

junho 29th, 2011

Aqui na UFABC possuímos uma base para autenticação de usuários centralizada no LDAP. Para evitar desconfortos aos usuários, bem como para facilitar a vida de nós, que desenvolvemos as aplicações e, é claro, as interfaces de login em cada uma delas, comecei a pesquisar maneiras de realizar um Single Sign-On (SSO) para todas as aplicações já em produção e para as futuras.

Inicialmente pensei em simplesmente criar uma sessão genérica que pudesse ser acessada por diversas aplicações, porém, o que parecia ser mais simples e rápido acabou se mostrando menos seguro e infinitamente menos portável. Logo desisti da idéia e comecei a pesquisar outras soluções de SSO.

O Maurício me indicou uma série de sistemas/bibliotecas baseados em diferentes protocolos, todos para Ruby. No meio da lista o Rubycas me chamou atenção, principalmente por utilizar um protocolo já utilizado e implementado em forma de clients para outras linguagens e por possibilitar a autenticação no LDAP.

Não vou entrar em detalhes sobre a história e funcionamento do protocolo CAS de SSO, mas suas primeiras implementações foram feitas em Java, quando se tornou um projeto da Jasig.

Para saber mais sobre como funciona o protocolo CAS visite este link. Basicamente existe um server que é uma interface web que autentica um usuário em alguma base de autenticação (LDAP no caso da UFABC) e redireciona para algum client que é sua aplicação.

RUBYCAS SERVER

A primeira coisa que fiz após ler um pouco sobre o protocolo CAS e sobre o projeto Rubycas foi tentar fazer o download do rubycas-server, seguindo as instruções desta página, instalei a gem rubycas-server em uma nova rvm gemset e segui as instruções destadesta pagina. As dores de cabeça começaram.

A gem possui dependências de gems antigas, o que ocasionou diversos problemas em alguns requires e em alguns métodos. Fiz alguns monkey patch’s para corrigir estes probleminhas, e após brigar muito com seu arquivo de configuração consegui fazer subir um “Frankenstein” no Webrick.

Foi um avanço, comecei a implementar os clients pois estava com pressa, mas mais tarde voltei ao server, definitivamente eu não queria fazer deploy de um Frankenstein:

  1. Clonei este projeto (O projeto!) do Github:  $ git clone git://github.com/gunark/rubycas-server.git meu_diretorio/rubycas-server;
  2. Entrei na pasta do projeto, editei o arquivo rubycas-server.gemspec e troquei a dependência da gem sqlite3 pelo meu adaptador de bd preferido;
  3. Instalei todas as dependências: $ bundle install
  4. Executei $ ./bin/rubycas-server e o arquivo localizado em ./config/config.example.yml foi automaticamente copiado para /etc/rubycas-server/config.yml
  5. Editei o arquivo /etc/rubycas-server/config.yml configurando o meu servidor e porta da aplicação, o meu adaptador de banco de dados, e meu modo de autenticação (LDAP);
  6. Fiz a aplicação subir localmente no Webrick rodando novamente $ ./bin/rubycas-server
  7. Testei a aplicação em http://localhost:<porta_escolhida> e visualizei a interface de login com sucesso!
  8. Para fazer deploy, como centralizamos nossos códigos no SVN, importei o projeto para nosso servidor SVN e fiz o checkout na máquina de produção;
  9. Dentro da pasta do projeto na máquina de produção repeti as etapas 3, 4 e 5, mas no arquivo de configuração não escolhi o meu servidor (webrick, mongrel, phusion passenger – apache, etc);
  10. Como iria publicar o rubycas-server no Apache (com o Phusion Passenger previamente instalado) entrei no diretório /etc/apache2/vhosts.d e criei um novo arquivo de configuração direcionando o meu host para a pasta da minha aplicação;
  11. Reiniciei o Apache e minha interface de login (Rubycas-server) passou a funcionar em produção desde então!

RUBYCAS CLIENT

A instalação e configuração do rubycas-client foi bem menos traumática. Transformei duas de nossas aplicações em dois clients para se autenticarem noserver que eu já tinha configurado:

  1. Instalei a gem rubycas-client;
  2. Entrei no diretório do projeto da minha aplicação;
  3. Editei o arquivo ./config/environment.rb em uma aplicação feita em Rails 2.x.x e ./config/application.rb em uma feita em Rails 3.x.x e inseri o seguinte código:
        require 'casclient'
        require 'casclient/frameworks/rails/filter'
    
        CASClient::Frameworks::Rails::Filter.configure(
          :cas_base_url => "https://<meu_server>/"
        )
  4. Editei o arquivo ./app/controllers/application_controller.rb e inseri o seguinte código no início do arquivo:  before_filter CASClient::Frameworks::Rails::Filter
  5. Apartir deste momento as aplicações já passaram a funcionar como clients. Um client se comporta basicamente da seguinte maneira: Verifica se a sessão cas_user existe, caso positivo cabe à sua aplicação decidir se fornece ou não permissão ao usuário logado, caso negativo redireciona o usuário para o rubycas-server, onde deve ser feita a autenticação, caso o usuário digite seu login e senha corretamente ele é redirecionado para a aplicação anterior (client), com a sessão cas_user contendo uma string com seu nome de usuário;
  6. O client é bastante flexível. A documentação (http://rubycas-client.rubyforge.org/) me ajudou bastante, principalmente para me ajudar a implementar o logout e a fazer os testes automatizados
E foi assim que consegui implementar um SSO aqui na UFABC. A partir de agora vou monitorar o desempenho e a eficiência do sistema e futuramente avaliar a necessidade de implementar ou não o Shiboleth (outro sistema de SSO que se comunica com a federação Cafe, que não entra no caso agora).

Vale lembrar que os clients do CAS podem ser implementados em outras linguagens além do Ruby (Java, PHP, .NET, etc), veja aqui.

Espero que tenha ajudado, ou ao menos dado alguma idéia. Qualquer coisa podem entrar em contato!

Rails Summit 2009 – Obie Fernandez

outubro 21st, 2009

Na semana passada eu e toda a equipe de desenvolvimento da UFABC fomos ao Rails Summit 2009, maior encontro de Ruby on Rails da América Latina. O evento, promovido pela Locaweb e guiado por Fábio Akita, teve a sua segunda edição realizada nos dias 13 e 14 de outrubro, no Centro de Convenções Anhembi, em São Paulo. Confira qual foi a programação do evento.

logo_rails_summit

Foram várias as palestras e os temas apresentados durante o Rails Summit, desde valores e paradigmas da linguagem e do framework, até detalhes técnicos e novidades sobre o assunto.

obie_fernandezA palestra de fechamento do evento foi apresentada por Obie Fernandez, autor do The Rails Way, o guia de referência definitiva para Ruby on Rails, editor da Addison-Wesley Professional Ruby Series e reconhecido membro da comunidade internacional de Ruby. Obie é o CEO/fundador da Hashrocket, consultoria web e desenvolvedora de produtos em Jacksonville Beach, Flórida.

Palestra: “Dominando a Arte de Desenvolvimento de Aplicações”

A palestra teve o objetivo de comparar o desenvolvimento de aplicações com criações artísticas. Obie iniciou descrevendo as maneiras como um indivíduo pode ser considerado especialista em alguma coisa, sugerindo como regra maior a prática: “Practice, practice and practice” (Praticar, praticar e praticar). Apesar do caráter óbvio desta colocação, a idéia parece não ser tão simples. Obie dividiu em 3 níveis o domínio que alguém possui sobre alguma modalidade, seja ela esportiva, artística ou de programação. Não me lembro exatamente como foram as classificações atribuídas por ele, mas era algo assim:

1º nível: O especialista. A pessoa é expert e muitas vezes uma importante referência naquilo que faz.

2º nível: O bom conhecedor. Apesar de não ser a melhor em sua área, a pessoa tem um bom conhecimento. Não passa vergonha.

3º nível: O mediano. Não é leigo, mas pode estar longe de ser o especialista da sua área.

Segundo algumas pesquisas, o tempo médio de prática para que um ser-humano possa se tornar especialista em alguma modalidade em algum momento de sua vida é em torno 10000 (dez mil) horas. Desta maneira, calculando bem por cima, um programador Ruby, por exemplo, com uma jornada diária de 8 horas, levaria cerca de 5 anos para ser especialista na linguagem. Porém, nesta estimativa alguns fatores que não foram levados em consideração podem fazer este tempo se elevar bastante – Apesar da jornada diária de trabalho, qual programador fica, efetivamente, 8 horas por dia apenas codificando ou estudando Ruby? E outro fator, não menos importante: O prazer com que a pessoa exerce determinada atividade – de nada vale 8 horas efetivas diárias se isto for um grande sacrifício. Obie comparou este último fato com o aprendizado de violino – Uma pessoa que desde sua infância pratica e estuda horas e horas por dia o instrumento, mas não tem o mínimo prazer em fazer isto, definitivamente o tempo que ela levará para se tornar uma especialista é extremamente superior (isto se fosse possível).

Entendo que pode paracer uma série de obviedades, e pode até ser, mas foi brilhantemente exposta por Obie Fernandez. Recomendo assistirem ou lerem algum material de sua autoria. Mas as partes mais legais, na minha opinião, foram as menções ao desenvolvimento ágil:

Assim como um artista plástico idealiza uma obra de arte em que o resultado final não é claro em sua mente, não se deve esperar que o desenvolvedor preveja todas as funcionalidades e o formato definitivo do sistema antes mesmo de começar a desenvolver – o pecado capital da maioria das metodologias clássicas de engenharia de software. Da mesma forma,  o artista não pinta um quadro o dividindo em partes isoladas, assim como o desenvolvimento e a programação de um sistema pode fluir muito melhor se não for excessivamente modularizada. Reparem nas diferenças:
monalisa_desenvolvimento_agilOutra prática muito comum utilizada em metodologias de desenvolvimento ágil são os testes automatizados de sistema: TDD (Test Driven Development ou Desenvolvimento Orientado a Testes). Uma feature de um sistema só deve ser codificada caso um teste para esta feature também já tiver sido previamente codificado, garantindo a integridade de todo o sistema, evitando, ou melhor, evidenciando uma porção de erros inimagináveis em futuras modificações sem que eles precisem ser encontrados pelo usuário final (como acontece na maioria das vezes em que um sistema é desenvolvido sem testes automatizados) e principalmente proporcionando uma visão clara e garantida do funcionamento do sistema como um todo, sem ao menos ter realizado nenhum teste real, assim como alguns especialistas da música conseguem imaginar perfeitamente como é a melodia da obra sem a ter ouvido nem uma única vez, apenas pela sua partitura.

A palestra foi ótima!

Aos programadores que não conhecem estes tipos de metodologias (Agile Development, TDD, etc), recomendo fortemente que pesquisem sobre. Ficam aí alguns links:

Test Driven Development
Agile Manifesto
Desenvolvimento ágil de software
Scrum

Web Site oficial de Obie Fernandez: http://obiefernandez.com/