Objetivo Geral

Propor uma estrutura para fornecer autenticação única com o protocolo
OAuth na plataforma Java, e implementar duas mini-aplicações que utilizem esta
estrutura de autenticação, sendo elas de plataformas de programação diferentes.

Conteúdo

O trabalho começa com uma pesquisa bibliográfica sobre diversos tópicos que abrangem o protocolo OAuth. Primeiramente sobre os conceitos de segurança de software, autenticação, autorização, cloud computing, o protocolo HTTP, protocolos similares (OpenID e CAS), e uma pesquisa aprofundada no protocolo OAuth, tendo como base principalmente sua especificação.

Tecnologias

Para o desenvolvimento das aplicações utilizadas no estudo de caso foram utilizadas as seguintes tecnologias:

• Spring MVC e Spring Security OAuth
• Hibernate
• Zend Framework
• Play Framework
• HTML5 e CSS3.

Implementação

Foi definido um servidor OAuth que fornece uma base de usuários e as funcionalidades de autorizar ou revogar o acesso de aplicações consumidoras. Foram implementados dois consumidores que utilizam este servidor para autenticação, um utilizando Zend Framework que é um sistema simples de cadastro de despesas e outro utilizando o Play Framework que é uma agenda de contatos. Os códigos dos três encontram-se na minha página do GitHub:

• Servidor
• Controle de Despesas
• Agenda de Contatos

Trabalhos Futuros

• Adicionar os tokens gerados pelo framework Spring Security OAuth a um banco de dados, ao invés de uma fonte de dados volátil como a memória RAM. Isso pode ser implementado criando-se um novo serviço de tokens, que implemente a interface OAuthProviderTokenServices;
• Após implementar o serviço de tokens mencionado acima, implementar um serviço de consumidores, permitindo que um administrador de sistema cadastre novas aplicações que podem tentar consumir dados dos proprietários de recursos capazes de se autenticar no sistema. Para isso é necessário implementar um novo serviço de consumidores, que implemente a interface ConsumerDetailsService;
• Com estas duas melhorias implementadas, outro trabalho futuro é a capacidade de listar para o usuário as aplicações que o mesmo autorizou e, permitir que o mesmo possa revogar o acesso das aplicações cadastradas;
• Outra melhoria é, ao revogar o acesso de uma aplicação, a capacidade de limpar os dados do usuário armazenados nessa aplicação, permitindo que a base de dados não fique inconsistente já que o proprietário do recurso não autoriza mais que o consumidor utilize seus dados.
• Essas melhorias estão relacionadas à aplicação desenvolvida aqui, porém, quando a versão 2.0 do OAuth, que até esta data encontra-se em rascunho, se tornar uma especificação estável, uma melhoria importante é a estrutura para utilizar esta versão.

O Trabalho

Confira abaixo o PDF contendo o trabalho completo:

Agradecimentos

À minha namorada, aos meus pais e ao orientador professor Diego de Carvalho.

Introdução

O Quartz é um serviço de agendamento de tarefas que pode ser integrado, ou utilizado virtualmente, em qualquer aplicação Java SE ou Java EE. A ferramenta pode ser utilizada para criar agendas simples ou complexas que executam dezenas, centenas ou até milhares de tarefas, as quais são definidas utilizando componentes padrão da plataforma Java, que são codificados para suprir as necessidades da aplicação. O Quartz Scheduler fornece diversos recursos corporativos, como suporte a transações JTA ou clusterização.

Scheduler

O Scheduler é o componente principal do Quartz, e é responsável por gerenciar a execução de jobs (tarefas). A partir do Scheduler o desenvolvedor pode agendar, iniciar a execução e parar a execução de jobs. Para construir um Scheduler deve-se utilizar uma classe que implementa o padrão de projeto Factory, no Quartz representado pela interface SchedulerFactory. Existem duas classes que implementam esta interface: StdSchedulerFactory e DirectSchedulerFactory. A primeira classe permite a utilização de um arquivo properties para configuração e a segunda implementa um segundo padrão de projeto: o Singleton.

Após obter um Scheduler, pode-se iniciar a execução do agendamento a partir do método start(), agendar novos jobs com o método scheduleJob() e parar o agendador com o método shutdown(). Ao se agendar um job com o método scheduleJob(), é necessário definir dois parâmetros:

• O primeiro define o job que será executado, representado pela interface Job;
• O segundo define o trigger, representado pela interface Trigger, que corresponde às condições de agendamento para execução do job em questão.

Job

Um job é uma tarefa a ser executada, que no Quartz nada mais é do que uma classe que implementa a interface Job, e que agrega todo o código necessário para fazer a funcionalidade específica do job em questão. Um job pode também receber parâmetros para seu correto funcionamento e isso é feito a partir da classe JobDetail.

Ao se implementar a interface Job, deve-se implementar também o método execute(), que recebe como parâmetro um JobExecutionContext e lança uma exceção do tipo JobExecutionException. Dentro do método execute() estará todo o código referente ao job em questão. Um exemplo de job é uma varredura automática de spams em um e-mail, ou, uma busca por tags duplicadas de um produto para limpeza em um banco de dados de algum comércio eletrônico.

Para a criação de um job é utilizada a classe JobBuilder, que define a classe do job implementado a partir do método newJob(), a identidade do job no método withIdentity() e a instanciação do mesmo no método build().

Trigger

Um objeto trigger é utilizado para disparar a execução de jobs. Quando um job é agendado, é feita a instância de um trigger e suas propriedades são configuradas para satisfazer o agendamento necessário para a aplicação. Existem alguns triggers pré-definidos na biblioteca Quartz, como, por exemplo, o SimpleTrigger e o CronTrigger.

Para a construção de um trigger é utilizada a classe TriggerBuild que implementa métodos utilizando Domain Specific Language (DSL) e permite a configuração dos dados do trigger, como, por exemplo, sua identidade a partir do método withIdentity(), seus dados de agendamento a partir do método withSchedule(), e a instanciação do trigger a partir do método build(). O método build() retorna uma classe que implementa a interface Trigger.

O CronTrigger é um tipo de trigger que é útil para agendamentos baseados em calendários, como, por exemplo, “uma execução deve ocorrer às quartas e quintas às 12:00h” ou “uma execução deve ocorrer todos os dias às 08:00h”, e assim por diante.

Um CronTrigger é construído ao se definir no método “TriggerBuild.withSchedule” um agendamento do tipo CronSchedule. Este tipo de agendamento é construído a partir do método estático cronSchedule da classe CronScheduleBuilder que recebe como parâmetro uma expressão cron.

Para formar uma expressão cron, alguns requisitos devem ser satisfeitos. Primeiramente deve-se conhecer a ordem dos parâmetros:

• Segundos;
• Minutos;
• Horas;
• Dia do mês;
• Mês;
• Dia da semana;
• Ano (opcional).

Por exemplo, uma expressão cron que será executada todas às quartas-feiras às 12:00PM é escrita da seguinte forma: “0 0 12 ? * WED”. Outro exemplo de expressão demonstra uma tarefa executada todos os dias, às 08:00AM e 12:00PM: “0 0 8,12 * * *”.

Exemplo

Para ilustrar todos os conceitos apresentados anteriormente foi desenvolvido um exemplo simples, que simula a utilização de um CronTrigger e define um job customizado que implementa a interface Job.

Este job será responsável por exibir uma mensagem de texto simples indicando que foi executado a cada 10 segundos todos os dias. O código do job foi definido conforme a listagem abaixo.

public class MyJob implements Job {
    @Override
    public void execute(JobExecutionContext context)
            throws JobExecutionException {
        System.err.println("Servico executado conforme agendamento");
    }
}

A classe principal que faz a execução deste job foi definida conforme a listagem a baixo.

public class Main {
    public static void main(String[] args) {
        try {
            SchedulerFactory schedFact = new StdSchedulerFactory();
            Scheduler sched = schedFact.getScheduler();
            sched.start();

            JobDetail job = JobBuilder.newJob(MyJob.class)
                .withIdentity("myJob", "group1")
                .build();

            Trigger trigger = TriggerBuilder
                .newTrigger()
                .withIdentity("myTrigger", "group1")
                .withSchedule(CronScheduleBuilder.cronSchedule("0/10 * * * * ?"))
                .build();

            sched.scheduleJob(job, trigger);
        } catch (Exception e) {
            System.out.println("erro");
            e.printStackTrace();
        }
    }
}

Neste exemplo de código é obtido uma instância de Scheduler a partir da Factory StdSchedulerFactory, o agendamento é iniciado, é criado um novo job do tipo MyJob, um novo CronTrigger que possui a expressão cron “0/10 * * * * ?” que significa “a cada 10 segundos”, e o job é agendado conforme o trigger criado.

Conclusão

Apesar de ser um exemplo simples, com ele é possível verificar o funcionamento de cada componente necessário para a execução de um job agendado, e a partir dele é possível ver sua aplicabilidade no cenário de alguma aplicação que tenha estas necessidades.

Referências

• http://quartz-scheduler.org/documentation/quartz-2.1.x/;
• http://adminschoice.com/crontab-quick-reference.

SQL Magazine 84

Já aconteceu a muito tempo, porém eu não havia compartilhado essa conquista aqui no blog. Um artigo meu entitulado “Implementação em MVC utilizando o Zend Framework” foi publicado na SQL Magazine edição 84. Para ver o conteúdo da revista clique aqui. Para acessar o artigo clique aqui.

Espero que nesse ano que virá eu consiga mais publicações .

Estou escrevendo artigos sobre o Zend Framework que serão publicados até o final de semana aqui no blog e, provavelmente, no iMasters. Nesses artigos estarei abordando: Zend_Db, Zend_Locale, Zend_Translate, Doctrine2 e iniciarei novas áreas aqui no blog: Play! Framework, JSF e OAuth.O OAuth foi o tema do meu trabalho de conclusão de curso da minha especialização na Universidade Tecnológica Federal do Paraná, estou viabilizando a disponibilização do PDF do trabalho e a criação de um repositório no Github para as aplicações desenvolvidas neste trabalho.

Instalei também no blog um plugin “social”, para permitir um “Curtir” no Facebook, compartilhar no Twitter e Linkedin, acho que isso vai ser muito bom para saber o que o pessoal anda achando do conteúdo. Bom, é isso que queria passar a todos, aguardem mais um pouco que logo logo saem novos artigos de Zend Framework. Vale a pena esperar!

Material que utilizei para estudo:

• php|architect’s Zend PHP 5 Certification Study Guide;
• Zend PHP 5.3 Study Guide;
• Zend Certification Preparation Tutorial;
• PHP Manual.

Os exercícios e testes práticos que fiz são os do próprio guia de estudos da Zend e, também os seguintes:

• PHPRiot Quiz;
• Vulcan Zend PHP Certification Mock Test.

Lembrando que, os mocks da Vulcan não estão mais disponíveis, eu apenas reutilizei créditos que tinha da certificação de PHP 5.

Uma dica que dou é que estudem a fundo o manual do PHP. Muita coisa da prova não é abordado nos outros PDFs, mas a partir do manual as coisas ficam mais fáceis.

Agradeço a Deus, minha namorada, meus familiares e amigos pelo apoio. E boa sorte para quem vai fazer a prova.

Minha idéia é fazer uma reflexão breve e esperar o feedback de vocês leitores, para refletirmos sobre este assunto tão comentado e fomentado por empresas nacionais e internacionais.

O que você entende por Simples?

A primeira pergunta a se fazer é: O que você entende por simples? Bom, isso é algo que deve-se pensar muito para responder, principalmente para não dizer coisas confusas. Mas será que existe uma forma de falar sobre isso claramente? Vamos tentar.

Para mim algo simples é algo facilmente compreensível e identificável. Em User Experience, o termo simples é a chave de tudo, já que os usuários podem facilmente aproveitar o uso de alguma ferramenta, software, etc. Este termo é bastante empregado na definição dos produtos da Apple, talvez por este termo sempre ter sido pregado em seus produtos ou por realmente os produtos serem simples.

Código-fonte

Mas trazendo para o código, realmente existe o termo simplicidade? Sim e não. Códigos desenvolvidos por outras pessoas tendem a ser difíceis de se entender, principalmente por cada um ter uma visão particular sobre a melhor forma de se fazer uma determinada tarefa. Mesmo com documentação e tudo mais, existe um esforço mínimo para a compreensão da visão que o outro desenvolvedor tem.

Mas utilizando princípios de DRY (Don’t Repeat Yourself) e KISS (Keep It Simple, Stupid), é possível minimizar esta complexidade. Utilizar métodos e funções já prontas da própria linguagem de programação, padronizar códigos repetitivos, utilizar orientação a objetos, utilizar Domain Specific Language, separar melhor o código em camadas, delegação de responsabilidades etc.

Só que tendo estas premissas em mente, você acaba trazendo a complexidade para si próprio. Como assim? Você pensa e repensa antes de codificar algo, o que pode afetar até sua produtividade. Realmente não existe muita mágica para diminuir complexidade de código… Só que existe algo que pode ser o melhor amigo do programador.

Refatoração

Refatorar código é uma ótima forma de minimizar a complexidade de código. Agora talvez seja a hora onde você, leitor, fale bastante mal de mim, por escrever tanta coisa e chegar em um ponto tão óbvio para todos. Mas essa é a mais pura verdade, refatorar é ótimo e ajuda muito a diminuir a complexidade do seu código.

Só que não se limite a apenas você mesmo refatorar o seu código, passe ele para amigos, colegas, para seu chefe e etc. vendo a opinião e as alterações de cada um, o que pode acabar tendendo a uma quantidade mínima de linhas e uma clareza maior.

Mantenha o foco

Por último, uma dica importante é manter o foco. Por experiência própria digo que esquentar a cabeça com a melhor forma de programar pode acabar te trazendo problemas de produtividade. Resolva o problema, faça funcionar, escreva os testes para garantir que seu código faz o que deveria fazer e refatore após tudo pronto.

Simples assim… Você já terá algo pronto e testado, poderá se dedicar a refatorar este código e não vai ficar horas e horas quebrando a cabeça para tentar achar a solução mais perfeita do que você está fazendo. Não tenho experiência suficiente para falar sobre BDD (Behavior Driven Development) mas dizem que utilizar ele da maneira correta traz muitos benefícios na questão de testes, entendimento e legibilidade de código, DSL e etc.

Bom, esse é um assunto que pode gerar uma discussão boa e quero agora ver de você, leitor, uma opinião sobre tudo isso. Como você faz para diminuir a complexidade do seu código? Você gosta e acredita na refatoração?

1. OS: Ubuntu 10.10: Distro GNU/Linux baseada no Debian, consegue unir o ótimo gerenciador de pacotes apt-get com um visual muito bonito, além de ser bem estável.
2. IDE: Zend Studio 8: IDE baseada em Eclipse criada pela Zend, possui suporte ao Zend_Tool, virtualização, debugger, code hint, PHPDoc, PHPUnit, etc. Para mim é de longe a melhor IDE para PHP e não vejo grandes gargalos de performance.
3. Subversion: Sistema de controles de versão bem famoso, possui conector nativo no Zend Studio, além de diversos programas que oferecem integração direta ao SO (como Tortoise ou RabbitCVS). Apesar de eu estar interessado no GIT, ainda não consegui estudá-lo, então continuo no SVN.
4. PostgreSQL: Não muito famoso para aplicações web, mas um ótimo sistema gerenciador de banco de dados. Possui muitas das funcionalidades de outros bancos de dados (como MySQL), além do grande plugin postgis.
5. PHPUnit: Usado na criação de testes unitários das aplicações que desenvolvo. Possui uma ótima integração com o Zend Studio, além de ser de fácil instalação/configuração.
6. Browsers: Para o desenvolvimento de aplicações web todos os browsers mais famosos são necessários. Isso inclui Internet Explorer, Mozilla Firefox, Opera, Safari e Google Chrome.
7. Frameworks: Zend Framework + Doctrine 2: Uma dupla quase perfeita, o Doctrine 2 simplifica toda a persistência das aplicações, além de permitir o trabalho com entidades PHP simples, sem atributos ou heranças obrigatórias. O Zend Framework me fornece todas as ferramentas para construir as aplicações, desde um framework MVC completo, até componentes de validação, internacionalização, acesso a serviços web e etc.

Bom, esses são os principais itens que gostaria de destacar sobre meu ambiente de trabalho. Agora passando a bola pra frente, indico os seguintes nomes:

@wcomnisky
@giolvani
@faustovaz

Segue abaixo os slides da palestra:

Para me preparar para a prova utilizei:

• Zend Framework em Ação;
• Zend Framework Certification Study Guide (Requer login);
• Zend Framework Componentes Poderosos para PHP;
• Zend Framework Certification a Refresher;
• Zend Framework Reference Guide – 1.5.3.

Espero que quem esteja interessado na certificação siga em frente e minha sugestão é que realmente estude e conheça os principais componentes exigidos, interfaces, constantes e os padrões de desenvolvimento com o framework. Um abraço e até a próxima.

Conceitos

Autorização é o ato de verificar as permissões de um usuário já autenticado no sistema e, baseando-se nessas permissões, permitir ou bloquear o acesso deste usuário a determinados recursos da aplicação. Se, por exemplo, em um Sistema de Gestão de Conteúdo (CMS), o usuário logado é um escritor, ele poderia ter acesso à escrita de artigos, porém não poderia ter acesso ao cadastro de novos usuários, pode-se obter este tipo de funcionalidade por meio de um componente de autorização. No Zend Framework este componente é o Zend_Acl, que fornece a funcionalidade de Lista de Controle de Acesso (ACL) e gestão de privilégios. Em geral, uma aplicação pode usar esta funcionalidade para controlar o acesso a certos objetos protegidos, requeridos por outros objetos.

Existem alguns termos utilizados para melhor explanar as entidades envolvidas no controle de acesso, cada um deles é detalhado a seguir.

Papel (role)

Um papel corresponde a uma responsabilidade de um usuário dentro de um sistema como, por exemplo, o papel de “colunista” ou de “membro”. Isto é encapsulado através da classe Zend_Acl_Role, que é uma classe simples que apenas armazena o nome do papel. Existe também herança de papéis, onde ao se herdar de um papel, é possível fazer tudo que o papel pai faz, além das ações específicas do papel filho. Para se criar um papel e adicioná-lo  na lista de controle de acesso, o seguinte código é necessário:

$papelMembro = new Zend_Acl_Role('membro');
$acl = new Zend_Acl();
$acl->addRole($papelMembro);

Para utilizar a herança de papéis basta passar o nome do papel pai como segundo parâmetro do método addRole(). Para exemplificar isso o papel “colunista” irá herdar de “membro”, pois um colunista pode fazer tudo o que um membro pode, além de possuir permissões especiais para criar colunas. O código deste exemplo é apresentado abaixo:

$papelMembro = new Zend_Acl_Role('membro');
$papelColunista = new Zend_Acl_Role('colunista');
$acl = new Zend_Acl();
$acl->addRole($papelMembro);
$acl->addRole($papelColunista, 'membro');

Recurso (resource)

Um recurso é algo a ser protegido, o que pode ser um controlador ou uma ação. Um recurso é encapsulado pela classe Zend_Acl_Resource, que simplesmente armazena o nome do recurso que será protegido. Assim como no caso do Zend_Acl_Role, a classe Zend_Acl_Resource oferece suporte a herança, esta sendo definida no segundo parâmetro do método add() de Zend_Acl. Um exemplo de utilização de recursos é o caso de um sistema de ERP onde usuários do papel “administrador” podem ter acesso ao controlador manutencao, já usuários do papel “operador” podem ter acesso ao controlador produto. Para criar estes recursos o seguinte código é necessário:

$acl = new Zend_Acl();
$acl->addResource(new Zend_Acl_Resource('manutencao'));
$acl->addResource(new Zend_Acl_Resource('produto'));

Privilégio (privilege)

Um dado recurso pode ter diversas permissões a um determinado papel, estas permissões são, tipicamente, baseadas nas operações que serão executadas. Exemplos destas operações podem ser ações de um controlador, como, por exemplo: “adicionar” e “visualizar”. Este tipo de acesso exigido é facilmente configurado com dois métodos do Zend_Acl: allow() e deny(). Um exemplo permitindo e negando ações do controlador artigos ao papel membro é exibido a seguir:

$acl->allow('membro', 'artigos', 'visualizar');
$acl->deny('membro', 'artigos', 'adicionar');

Após permitir ou negar privilégios é possível verificar se um determinado papel tem acesso a um privilégio com o seguinte código:

if ($acl->isAllowed('member', 'artigos', 'visualizar') {
	echo "acesso permitido";
}

Estes são os principais conceitos e métodos relacionados aos componentes de autorização do Zend Framework, agora é hora de implementar um sistema de autorização integrado com o MVC do framework. Existem diversas formas de se implementar esta funcionalidade, a maneira demonstrada neste artigo é apenas uma delas.

Codificando a Autorização

Após uma introdução sobre os componentes de autorização do Zend Framework é hora de integrar as funcionalidades para aplicar a autorização ao MVC do framework. Antes de mais nada estou partindo do pressuposto de que o leitor possui todos os fontes do artigo Autenticação com Zend Framework, para reaproveitar o código desenvolvido neste artigo.

Banco de Dados e configurações iniciais

O banco de dados do artigo anterior sofreu algumas modificações, agora foi criada uma tabela para armazenar os perfis (papéis) suportados por essa aplicação. Dois perfis de exemplo são criados, o primeiro corresponde ao perfil de administrador, que pode ter acesso a todos os recursos protegidos e o segundo ao perfil de escritor, que pode apenas acessar o controlador de notícias. Um usuário para cada perfil também foi criado. O SQL do banco de dados é apresentado abaixo:

CREATE TABLE `perfil`(
 id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
 nome VARCHAR(30)
)ENGINE=InnoDB;
CREATE TABLE `usuario`(
 id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
 login VARCHAR(30) NOT NULL UNIQUE,
 senha VARCHAR(60) NOT NULL,
 nome_completo VARCHAR(100) NOT NULL,
 perfil_id INT UNSIGNED NOT NULL,
 FOREIGN KEY(`perfil_id`) REFERENCES `perfil`(`id`)
 ON UPDATE CASCADE
 ON DELETE CASCADE
)ENGINE=InnoDB;
INSERT INTO `perfil`(nome) VALUES ('admin'), ('writer');
INSERT INTO `usuario`(login, senha, nome_completo, perfil_id) VALUES ('admin', SHA1('admin'), 'Administrador', 1), ('escritor', SHA1('escritor'), 'Escritor', 2);

O arquivo de configurações application/configs/application.ini desenvolvido no artigo anterior não sofrerá alterações impactantes, algumas linhas são adicionadas para configurar as namespaces do autoloader do framework e incluir o plugin de autenticação, que cuidará da parte de verificar o usuário logado e suas permissões, implementado mais adiante. Estas linhas podem ser adicionadas logo acima da seção [staging : production]:

autoloaderNamespaces[] = "Aplicacao"
resources.frontController.plugins.auth = "Aplicacao_Plugin_Auth"

A próxima etapa é adicionar ao Bootstrap a inicialização da classe de ACL que irá popular todas as regras de autorização suportadas pela aplicação. Dentro do arquivo application/Bootstrap.php basta adicionar o seguinte método à classe Bootstrap:

protected function _initAcl()
{
	$aclSetup = new Aplicacao_Acl_Setup();
}

No artigo anterior foram criados os controladores: noticias e auth. Agora basta criar o controlador usuarios, que será acessível pelo papel admin, adicionar novas ações a este novo controlador e ao controlador noticias e, por último, adicionar uma nova ação ao controlador error.

zf create controller usuarios
zf create action adicionar noticias
zf create action adicionar usuarios
zf create action forbidden error

A ação forbidden ficará responsável por informar ao usuário que um determinado acesso não foi autorizado pela aplicação. Para exibir esta mensagem ao usuário basta adicionar o seguinte conteúdo ao arquivo views/scripts/error/forbidden.phtml:

<div style="color: #f00;">Voc&ecirc; n&atilde;o est&aacute; autorizado a ver esta p&aacute;gina</div>

Com isso a parte inicial da aplicação está pronta, agora é hora de implementar a classe responsável por popular o componente Zend_Acl.

Populando a ACL

A classe Bootstrap irá inicializar uma classe chamada Aplicacao_Acl_Setup, que ficará responsável por popular todos os dados relacionados a papéis, recursos e privilégios do componente Zend_Acl. Esta classe é apresentada abaixo e deve ser gravada no arquivo library/Aplicacao/Acl/Setup.php.

<?php
class Aplicacao_Acl_Setup
{
	/**
	 * @var Zend_Acl
	 */
	protected $_acl;

	public function __construct()
	{
		$this->_acl = new Zend_Acl();
		$this->_initialize();
	}

	protected function _initialize()
	{
		$this->_setupRoles();
		$this->_setupResources();
		$this->_setupPrivileges();
		$this->_saveAcl();
	}

	protected function _setupRoles()
	{
		$this->_acl->addRole( new Zend_Acl_Role('guest') );
		$this->_acl->addRole( new Zend_Acl_Role('writer'), 'guest' );
		$this->_acl->addRole( new Zend_Acl_Role('admin'), 'writer' );
	}

	protected function _setupResources()
	{
		$this->_acl->addResource( new Zend_Acl_Resource('auth') );
		$this->_acl->addResource( new Zend_Acl_Resource('error') );
		$this->_acl->addResource( new Zend_Acl_Resource('noticias') );
		$this->_acl->addResource( new Zend_Acl_Resource('usuarios') );
	}

	protected function _setupPrivileges()
	{
		$this->_acl->allow( 'guest', 'auth', array('index', 'login') )
				   ->allow( 'guest', 'error', array('error', 'forbidden') );
		$this->_acl->allow( 'writer', 'noticias', array('index', 'adicionar') )
				   ->allow( 'writer', 'auth', 'logout' );
		$this->_acl->allow( 'admin', 'usuarios', array('index', 'adicionar') );
	}

	protected function _saveAcl()
	{
		$registry = Zend_Registry::getInstance();
		$registry->set('acl', $this->_acl);
	}
}

A primeira etapa desta classe é configurar os papéis. Neste caso foram criados os papéis guest, writer e admin. O papel guest foi criado como um facilitador, já que não será utilizado. Pode ocorrer de a aplicação liberar determinados acessos a usuários não-logados, aí que entra este papel. O papel writer terá os mesmos acessos de guest, além de acessos específicos, assim como o papel admin terá os mesmos acessos que guest e writer, além de outras permissões.

Após ter os papéis definidos, são adicionados os recursos protegidos. Neste caso os recursos são os controladores auth, error, noticias e usuarios. A próxima etapa, é definir os privilégios de um determinado papel a um determinado recurso. O papel guest pode acessar ações de erro e a página de login, já o papel writer pode acessar as ações de guest, as ações do controlador de notícias e a ação de logout do controlador auth. Já o papel admin pode acessar o mesmo que os outros dois papéis, além das ações do controlador de usuários.

Por último esta ACL é adicionada ao Zend_Registry, para que em outras partes da aplicação ela esteja acessível e devidamente populada.

Verificação de permissões

Tendo a ACL devidamente configurada, agora será possível verificar as permissões do usuário. Para isso foi criado um plugin que é adicionado ao Zend_Controller_Front no arquivo de configuração definido na primeira etapa das implementações. Este plugin terá como pai a classe Zend_Controller_Plugin_Abstract que possui diversos métodos referentes a cada etapa do processo de despacho das classes do Zend Framework. O método utilizado no plugin é o preDispatch() que é chamado antes de uma ação de controlador ser despachada, o que permite re-configurar a rota caso o usuário não possa ter acesso à página em questão. Este plugin é exibido abaixo e deve estar gravado em library/Aplicacao/Plugin/Auth.php:

<?php
class Aplicacao_Plugin_Auth extends Zend_Controller_Plugin_Abstract
{
	/**
	 * @var Zend_Auth
	 */
	protected $_auth = null;
	/**
	 * @var Zend_Acl
	 */
	protected $_acl = null;
	/**
	 * @var array
	 */
	protected $_notLoggedRoute = array(
		'controller' => 'auth',
		'action'     => 'login',
		'module'     => 'default'
	);
	/**
	 * @var array
	 */
	protected $_forbiddenRoute = array(
		'controller' => 'error',
		'action'     => 'forbidden',
		'module'     => 'default'
	);

	public function __construct()
	{
		$this->_auth = Zend_Auth::getInstance();
		$this->_acl = Zend_Registry::get('acl');
	}

	public function preDispatch(Zend_Controller_Request_Abstract $request)
	{
		$controller = "";
		$action     = "";
		$module     = "";
		if ( !$this->_auth->hasIdentity() ) {
			$controller = $this->_notLoggedRoute['controller'];
			$action     = $this->_notLoggedRoute['action'];
			$module     = $this->_notLoggedRoute['module'];
		} else if ( !$this->_isAuthorized($request->getControllerName(),
					$request->getActionName()) ) {
			$controller = $this->_forbiddenRoute['controller'];
			$action     = $this->_forbiddenRoute['action'];
			$module     = $this->_forbiddenRoute['module'];
		} else {
			$controller = $request->getControllerName();
			$action     = $request->getActionName();
			$module     = $request->getModuleName();
		}
		$request->setControllerName($controller);
		$request->setActionName($action);
		$request->setModuleName($module);
	}

	protected function _isAuthorized($controller, $action)
	{
		$this->_acl = Zend_Registry::get('acl');
		$user = $this->_auth->getIdentity();
		if ( !$this->_acl->has( $controller ) || !$this->_acl->isAllowed( $user, $controller, $action ) )
			return false;
		return true;
	}
}

Primeiramente são definidas as rotas padrão para o caso do usuário não estar logado ou não estar autorizado a ver uma determinada página. Estas rotas são, consecutivamente: auth/login e error/forbidden. No construtor é recuperada a instância atual de Zend_Auth e Zend_Acl, ambas usadas no processo de verificação do usuário logado.

A primeira etapa do método preDispatch() é verificar se o usuário está logado e, caso não esteja, os parâmetros da requisição são configurados para a rota de login. A segunda etapa é o caso do usuário estar logado, nesta etapa o objeto que representa o usuário logado é recuperado e é feita uma verificação se este usuário possui o privilégio correspondente à ação do controlador requisitado. Caso não possua, ou o recurso que representa o controlador não exista, ele é redirecionado para a rota de acesso proibido. Se nenhuma destas verificações negar o acesso ao usuário significa que ele está apto a acessar a requisição em questão, portanto os parâmetros dessa requisição são mantidos e o fluxo prossegue.

Models

Tendo todo o processo de verificação pronto a próxima etapa é criar as classes com regras de negócio da parte de autenticação. Já que, diferente do artigo anterior, este artigo envolve o MVC do Zend Framework, toda a parte de regra de negócio é implementada na camada referente ao Model. A primeira classe criada é a classe que representa um usuário da aplicação. Ela implementará a interface Zend_Acl_Role_Interface, que permite que ela seja tratada como um papel do componente Zend_Acl. Esta classe exige que o método getRoleId() seja implementado e retorne o identificador correspondente ao papel em questão. Esta classe é bem simples e possui apenas métodos getters e setters. Ela deverá estar no arquivo models/Usuario.php.

<?php
class Model_Usuario implements Zend_Acl_Role_Interface
{
	private $_userName;
	private $_roleId;
	private $_fullName;

	public function getUserName()
	{
		return $this->_userName;
	}

	public function setUserName($userName)
	{
		$this->_userName = (string) $userName;
	}

	public function getFullName()
	{
		return $this->_fullName;
	}

	public function setFullName($fullName)
	{
		$this->_fullName = (string) $fullName;
	}
	/**
	 *
	 */
	public function getRoleId()
	{
		return $this->_roleId;
	}

	public function setRoleId($roleId)
	{
		$this->_roleId = (string) $roleId;
	}
}

A próxima etapa é implementar a classe que cuidará da regra de negócio de login. Esta classe terá apenas um método estático, responsável por fazer o login do usuário na aplicação. A principal diferença deste método de login com o apresentado no artigo anterior é a modificação da consulta ao banco de dados, para adicionar a tabela perfil aos dados retornados pelo Zend_Auth_Adapter_DbTable. O método join() de Zend_Db_Select, adicionará a tabela perfil com o alias “p”, onde a coluna perfil_id da tabela usuario seja igual a coluna id da tabela perfil, retornando a coluna  “nome” da tabela “perfil” com o alias “nome_perfil”. Após validar o login, o objeto retornado pelo adapter é mapeado para um objeto do tipo Model_Usuario e, por último, este é armazenado à sessão do Zend Framework. Este model ficará no arquivo models/Auth.php e deve possuir o seguinte conteúdo:

<?php
class Model_Auth
{
	public static function login($login, $senha)
	{
		$dbAdapter = Zend_Db_Table::getDefaultAdapter();
		//Inicia o adaptador Zend_Auth para banco de dados
		$authAdapter = new Zend_Auth_Adapter_DbTable($dbAdapter);
		$authAdapter->setTableName('usuario')
					->setIdentityColumn('login')
					->setCredentialColumn('senha')
					->setCredentialTreatment('SHA1(?)');
		//Define os dados para processar o login
		$authAdapter->setIdentity($login)
					->setCredential($senha);
		//Faz inner join dos dados do perfil no SELECT do Auth_Adapter
		$select = $authAdapter->getDbSelect();
		$select->join( array('p' => 'perfil'), 'p.id = usuario.perfil_id', array('nome_perfil' => 'nome') );
		//Efetua o login
		$auth = Zend_Auth::getInstance();
		$result = $auth->authenticate($authAdapter);
		//Verifica se o login foi efetuado com sucesso
		if ( $result->isValid() ) {
			//Recupera o objeto do usuário, sem a senha
			$info = $authAdapter->getResultRowObject(null, 'senha');

			$usuario = new Model_Usuario();
			$usuario->setFullName( $info->nome_completo );
			$usuario->setUserName( $info->login );
			$usuario->setRoleId( $info->nome_perfil );

			$storage = $auth->getStorage();
			$storage->write($usuario);

			return true;
		}
		throw new Exception('Nome de usuário ou senha inválida');
	}
}

Controller de Autenticação e demais Views

Agora que toda a regra de negócio foi delegada à camada Model, o controller de autenticação sofre algumas modificações para utilizar esta classe. Neste caso ele chamará o método estático Model_Auth::login(), e, caso este lance alguma exceção, irá armazenar a mensagem ao helper FlashMessenger e exibí-la em cima do formulário de login. A classe modificada é apresentada abaixo e, logo em seguida, a view correspondente a esta ação de login é apresentada. O formulário de login é o mesmo implementado no antigo anterior.

<?php
class AuthController extends Zend_Controller_Action
{

	public function init()
	{
	}

	public function indexAction()
	{
		return $this->_helper->redirector('login');
	}

	public function loginAction()
	{
		$this->_flashMessenger = $this->_helper->getHelper('FlashMessenger');
		$this->view->messages = $this->_flashMessenger->getMessages();
		$form = new Form_Login();
		$this->view->form = $form;
		//Verifica se existem dados de POST
		if ( $this->getRequest()->isPost() ) {
			$data = $this->getRequest()->getPost();
			//Formulário corretamente preenchido?
			if ( $form->isValid($data) ) {
				$login = $form->getValue('login');
				$senha = $form->getValue('senha');

				try {
					Model_Auth::login($login, $senha);
					//Redireciona para o Controller protegido
					return $this->_helper->redirector->goToRoute( array('controller' => 'noticias'), null, true);
				} catch (Exception $e) {
					//Dados inválidos
					$this->_helper->FlashMessenger($e->getMessage());
					$this->_redirect('/auth/login');
				}
			} else {
				//Formulário preenchido de forma incorreta
				$form->populate($data);
			}
		}
	}

	public function logoutAction()
	{
		$auth = Zend_Auth::getInstance();
		$auth->clearIdentity();
		return $this->_helper->redirector('index');
	}
}

<h2>Login</h2>
<?php echo ( sizeof( $this->messages ) > 0 ) ? '<div style="color: #f00;">' . $this->messages[0] . '</div>' : ""; ?>
<?php echo $this->form; ?>

A última etapa é modificar as views dos controladores noticias e usuarios. Estas views são extremamente simples e irão conter apenas uma mensagem de boas-vindas e um link para logout. O arquivo views/scripts/noticias/index.phtml deve conter o seguinte conteúdo:

<h2>Bem-vindo Escritor</h2>
<a href="<?php echo $this->url(array('controller' => 'auth', 'action' => 'logout', 'module' => 'default'), '', true); ?>">
	Logout
</a>

E, por último, o arquivo views/scripts/usuarios/index.phtml possui o seguinte conteúdo:

<h2>Bem-vindo Admin</h2>
<a href="<?php echo $this->url(array('controller' => 'auth', 'action' => 'logout', 'module' => 'default'), '', true); ?>">
	Logout
</a>

Funcionamento

Após todas as etapas estarem concluídas a aplicação está devidamente protegida, tanto na questão de permitir apenas usuários logados, como em autorizar aos usuários apenas alguns privilégios baseados em seu perfil. Para o meu caso a URL da aplicação ficou apontada para: http://localhost/zend_acl, e qualquer tentativa de acessar controllers internos são redirecionadas à pagina de login. Após o login,  a aplicação permite ou proíbe o acesso, de acordo com o perfil logado.  Abaixo são apresentadas algumas screenshots de cada parte funcional desta aplicação:

Erro ao efetuar login

Escritor logado com sucesso, acessando o controlador noticias

Tentativa de acesso ao controlador usuarios, utilizando o perfil escritor

Acesso ao controlador usuarios, usando o perfil admin

Conclusão

Os componentes do Zend Framework relacionados à autorização apresentam uma API consistente e intuitiva de se utilizar e configurar, o que garante uma baixa curva de aprendizagem para se utilizar as funcionalidades básicas do mesmo. Estes componentes podem ser integrados a todo o processo de despacho da parte MVC do framework através de plugins, o que permite manipular as requisições livremente e, baseado em determinados critérios, redirecionar o usuário para outros pontos da aplicação para informar mensagens de erro ou exigir algum formulário para entrada de dados. O objetivo deste artigo foi demonstrar de forma prática uma maneira de implementar autorização e integrá-la ao MVC, porém, vale ressaltar, que existem diversas formas de se chegar a esta funcionalidade, para maiores informações a seção de referências logo abaixo pode ser de grande valia. No próximo artigo os componentes de Internacionalização e Localização serão abordados, até a próxima pessoal!

Faça o download do código-fonte.

Referências

• Zend_Acl no guia de referência do Zend Framework;
• Plugins no guia de referência do Zend Framework;
• Livro Zend Framework em Ação.