Entendendo rbac no web2py, Teses de Auditoria. Centro Universitário do Distrito Federal (UniDF)
ovidio_marinho
ovidio_marinho17 de Outubro de 2015

Entendendo rbac no web2py, Teses de Auditoria. Centro Universitário do Distrito Federal (UniDF)

DOCX (756.0 KB)
23 páginas
5Números de download
805Número de visitas
Descrição
Artigo Pos-graduação Segurança da Informação
20pontos
Pontos de download necessários para baixar
este documento
baixar o documento
Pré-visualização3 páginas / 23
Esta é apenas uma pré-visualização
Consulte e baixe o documento completo
Esta é apenas uma pré-visualização
Consulte e baixe o documento completo
Pré-visualização finalizada
Consulte e baixe o documento completo
Esta é apenas uma pré-visualização
Consulte e baixe o documento completo
Esta é apenas uma pré-visualização
Consulte e baixe o documento completo
Pré-visualização finalizada
Consulte e baixe o documento completo

FACULDADE ESTÁCIO DE SÁ DE JOÃO PESSOA - PARAÍBA

Pós-Graduação em Segurança da Informação

RBAC NO FRAMEWORK WEB2PY

FALCÃO NETO, Ovidio Marinho* **

RESUMO

Este trabalho apresenta como RBAC – Role Based Access Control, traduzido para o português: Controle de Acesso Baseado em Papeis é aplicado no sistema de segurança de usuários e aplicações fornecidas com o framework web2py. RBAC fica implementado na aplicação “welcome”, que é uma aplicação de scaffolding, de exemplo, disponível no framework , como também sua otimização e modelagem, é software de código Livre. Neste trabalho especifico apresenta-se o RBAC no web2py e como ele é implementado.

Palavras-chave: RBAC, WEB2PY, PAPEIS, SEGURANÇA.

*Graduado no Curso de Sistemas para Internet – Faculdade de Tecnologia da Paraíba – João Pessoa – PB ** Membro daequipe de desenvolvimento do Framework Web2py - http://web2py.com/init/default/who

1 INTRODUÇÃO

O Acesso a informação hoje em dia é ofertado em diversas maneiras de se autenticar em sistemas na Internet para obter a informação ou o objetivo desejado, seja em um simples cadastro de acesso a matricula de um curso ou até mesmo o acesso restrito e sigiloso de uma conta bancária. O desenvolvimento web traz para este usuário em nuvem a opção segura, em se autenticar em sites que ofereçam um login e senha, assim o usuario ficará mais tranquilo, ao considerar esta autenticação um porto seguro.

Este será nosso objetivo, falar sobre autenticação e detalhar a tecnica ou o modelo RBAC, que vem desde a década de 1970 a preocupação com sistemas de autenticação.

I would like to take this opportunity to underscore the importance and relevance of research conducted by your laboratory into Role-Based Access Control(RBAC). In the area of security one of the features most requested by Sybase customers has been RBAC.They view this feature as indispensable for the effective management of large and dynamic user populations.”

(Thomas J. Parenty ,Director, Data and Communications Security ,Sybase, Inc.Emeryville, Ca. Apud Jonh Barkley, RBAC ppt slide 6 Disponível em: < http://www.powershow.com/ view/11da44-Y2U1M/ ROLE_BASED_ACCESS_CONTROL_powerpoint_ppt_presentat ion> Acessado em 01/09/2014)

Qualquer tecnologia aplicada ao procedimento eletronico , utilizada para produção, distribuição e compartilhamento de informações, requer mecanismos apropriados de controle de acesso com o objetivo de garantir sua confidencialidade, autenticidade e integridade. O RBCA é um modelo de acesso para proteção de informações e recursos em ambientes informatizados.

Quão importante é a segurança, em sua totalidade, são também os métodos disponíveis para implementá-lo e o impacto que isso tem na estrutura de TI como um todo, buscando uma maneira mais fácil de gerenciamento.

Os mecanismos praticados na Segurança da Informação facilitam proteger informações e seus ativos de diversos tipos e modalidades de ameaças (aceso não permitido, roubo ou desvio da informação,etc...), mecanismos estes que são instrumentos para garantir ao maximo o uso controlado de tais recursos no sentido de moldá-los as necessidades oferecidas no momento e na prevenção de mau uso pelos usuários que participem deste acesso a esses sistemas. Garantir os princípios é a obrigação do gestor responsável pelo desenvolvimento e implementação do projeto, os principios básicos devem ser respeitados, fielmente, a autenticidade, a confidencialidade e a integidade devem existir sempre, como uma cartilha obrigatória em um sistema proposto, para fornecer informação de forma segura.

Para isso o Framework Web2py traz uma abordagem a estes princípios, ele embarca em seu chassi, ou seja em seu start, o modelo que é a aplicação “Welcome”, no Auth, que nada mais é que a classe responsável para fazer, como em um passe de mágica,o surgimento em cada geração de uma nova aplicação, um sistema completo de autenticação , com criação hierárquica de tabelas relacionadas, em banco de dados e uma regra de negócio própria e escalável, utilizando o processo de hierarquia e permissões, com papeis e funções, que o usuario pode executar ou não em uma aplicação.

O RBAC baseia-se no controle de acesso em papeis definido nas funções que o usuário exerça dentro da empresa ou organização. Estas permissões ( funções ou papeis ) definem um elenco de atividades determinadas para cada usuário, que podem ser percebidas como uma patente de um cargo ou hierarquicamente a localização, setor ou lotação que este funcionário ou colaborador ocupa na organização, representando uma pirâmide de permissões, tendo acesso aos recursos de rede ou banco de dados de acordo com seu nivel de permissão, podendo executar ou não tarefas do tipo: gravação, visualização, deleção. A flexibilidade do modelo RBAC é o grande divisor de facilidade, em um mesmo cadastro de usuario no sistema posso definir que o usuario tenham varios papéis,e sofra metamorfoses de privilégios, em uma aplicação ele pode ser administrador, em outra um operador e em uma outra um simples usuario visualizador, esta maleabilidade faz do modelo RBAC a total diferença,facilitando até na administração e manutenção, promovendo a facilidade no gerenciamento dos usuários envolvidos no sistema. Ainda em sistemas não poderíamos deixar de falar em banco de dados, que vai permitir ao administrador do sistema uma auditoria completa de toda movimentação, com logs de login, desconexão, alterações de registros dentre outras funções de auditoria.

O Web2py já prevendo todas estas facetas do modelo RBAC o adota como modelo de autenticação para o padrão de segurança do framework, que tem fornecido enorme facilidade ao gerenciamento de usuários que o utilizam, como ferramenta inclusa, ou seja um built-in do Web2py ,o sistema criado pelo Auth do web2py acompanha a aplicação, desde a criação até mesmo se não desejar utilizar os niveis hierárquicos oferecidos, mesmo assim, é montado dinamicamente um sistema de autenticação em tabelas para cada aplicação nova e é criado o sistema onde o usuário já pode se autenticar no sistema.

A classe Auth do web2py é onde tudo acontece, detalharemos o seu funcionamento para que entendamos como estas funções de criação de tabelas dinamicas acontecem toda vez que se cria uma nova aplicação.

2 – O que é e como funciona RBAC?

A chave para entender o RBAC é perceber que os usuários não são

permitidos para executar diretamente uma operação em um objeto. Em vez

disso, os usuários são atribuídos a funções com base em suas funções de

trabalho. A estas funções são dadas permissões para executar operações em

objetos. Então, para um usuário acessar os dados, o usuário deve ser um

membro de uma função que tem permissão para executar operações sobre o

objeto.

O Surgimento da utilização de papéis ou funções com diferentes

privilégios e responsabilidades têm sido o modelo implementado em

organizações empresariais e aplicações comerciais desde a década de 1970

quando os sistemas adotaram uma sistemática na restrição ao seu acesso,

baseando em uma função ou um papel o que exerce o usuário dentro de uma

organização.

Estes tipos de sistemas de autenticações baseados em funções/

papeis eram relativamente simples. Não existia uma entidade ou uma norma

que regulassem este tipo de modelo nem que o orientasse de como seria a

melhor forma de empregá-lo. Os sistemas eram desenvolvidos por várias

organizações, não existia um comum acordo sobre a definição ou o

reconhecimento de padrões formais, para normalizar o uso de um modelo de

controle de acesso entre estas organizações.

O primeiro modelo de acesso baseado em papéis de uso

generalizado foi proposto em um artigo em 1992 por Ferraiolo e Kuhn, [Ferraiolo e Kuhn. 1992], este artigo mostra como o modelointegrava os recursos de abordagens específicas a aplicativos existentes em um novo

modelo de controle de acesso, baseado em uma função generalizada. Este

artigo foi revolucionário pois apresentou RBAC como uma alternativa aos

tradicionais modelos existentes o MAC - Mandatory Access Control e DAC -

Discretionary Access Controls , apresentando uma descrição formal, em termos de conjuntos, relações e mapeamentos, definindo papéis e hierarquias

dos papéis, bem como os tipos de restrições de usuário ou a associação de

função a usuário e ativação conjunto de permissões ao papel. Foram

necessárias três regras básicas:

1) Atribuição de Papeis: Um Usuário pode executar uma operação

apenas se o item escolhido tem permissão no assunto selecionado ou se foi

atribuído a ele este papel. O processo de identificação e autenticação por

exemplo: ”login”, não é considerado uma transação. Todas as outras

atividades do usuário no sistema são realizadas por meio de

transações. Assim, todos os usuários ativos são obrigados a ter algum papel

ativo.

2) Autorização do Papel: O ativação do papel do usuário deve ser

autorizada para o assunto em questão.Com a regra (1) acima mais esta regra

(2) garante-se que os usuários podem assumir apenas funções para as quais

são autorizadas.

3) Autorização da transação: Um usuário pode executar uma

operação, apenas se a transação é autorizada através de associações de

funções dando permissões ao usuário, e por sua vez o usuário sujeito a

quaisquer restrições que podem ser aplicadas entre os usuários, papéis e

permissões. Com a regra (1) e regra (2),mais esta (3) regra garante-se que os

usuários podem executar apenas as operações para as quais são autorizadas.

Uma característica chave deste modelo é que todo o acesso é feito

através de papéis. Um papel é essencialmente uma coleção de permissões, e

todos os usuários recebem permissões, apenas através dos papéis a que lhe

estão atribuídos, ou por meio de papéis que herdamos através da hierarquia

de funções.

Dentro de uma organização, os papéis são relativamente estáveis,

enquanto os usuários e permissões são numerosos e podem mudar

rapidamente. Controlando todos os acessos através de papéis, portanto,

simplifica o gerenciamento e revisão de controles de acesso.

O modelo Ferraiolo e Kuhn 1992 foi prorrogado até 1995 por

Ferraiolo,Cugini e Kuhn. Em 1996, Sandhu, Coyne, Feinstein e Youman , que

apresentaram um novo quadro de modelos para o RBAC, e incorporaram-se

ao RBAC puro, digamos assim , com as características descritas já acima,

mas em um arranjo modular. RBAC0, foi definido como o modelo base,

definido através de usuários, papéis e permissões. RBAC1, inclui o RBAC0

mas incorpora hierarquias, como uma relação parcial de ordens entre

papéis. RBAC2 também incorpora RBAC0, mas acrescenta restrições. O

RBAC1 e RBAC2 são independentes um do outro, ou seja, um sistema pode

implementar um, sem que tenha que utilizar o outro. RBAC3 é um modelo de

RBAC com muitos recursos, incorporando RBAC0, RBAC1 e RBAC2. O

RBAC3 é essencialmente equivalente ao modelo principal com a ressalva de

que RBAC3 permite uma hierarquia de ordem parcial, enquanto o modelo

Ferraiolo-Kuhn define a hierarquia como uma árvore enraizada em 1992 por

Ferraiolo e Kuhn.

Em termos de orientação a objetos, o modelo SCFY 1996 pode ser

considerado como a incorporação de herança múltipla enquanto Ferraiolo-

Kuhn usa herança simples. Finalmente em 2000, o NIST – National Institute

Standards Technology é chamado para criar um padrão unificado para RBAC,

integrando o modelo em 1992 por Ferraiolo-Kuhn integrando na pesquisa do

quadro RBAC introduzido por Sandhu em 1996. Esta proposta foi publicada

por Sandhu, Ferraiolo e Kuhn e apresentou esta nova função, ACM 5 no

Workshopon Based Access Control. Após debate e comentário nas

comunidades RBAC e de segurança, o NIST fez as revisões e propôs um

padrão nacional dos EUA para o RBAC através do Comitê Internacional de

Padrões de Informação Tecnologia (INCITS – Disponível em: <http://

www.incits.org/> Acessado em: 22/08/2014) , esta entidade foi a responsável

nos EUA para o desenvolvimento de padrões em tecnologia da informação e

comunicações. INCITS também é (Instituto Nacional Americano de Padrões da

ANSI - Advisory Group). Técnico de ISO / IEC Comitê Técnico Conjunto , que

é responsável pela padronização de TI a nível internacional. Em 2004, o

padrão recebeu aprovação e foi adotado como INCITS 359-2004 . (Disponível

em <http://profsandhu.com/journals/tissec/ANSI+INCITS+359-2004.pdf>

Acessado em: 22/08/2014).

Estava criada a proposta de uso de um modelo de autenticação

segura baseada em papeis o RBAC, bem agora ao foco de nosso trabalho que

é falar e mostrar a implementação e utilização deste modelo no framework

web2py.

3- O que é o Web2py?

Web2py é um framework de código aberto, livre e gratuito para

desenvolvimento de aplicações baseadas na web e banco de dados rápidos,

escaláveis, seguros e portáteis. Web2py também oferece ao desenvolvedor a

filosofia de desenvolvimento Ágil, utiliza o padrão MVC – Model, Views e

Controllers no modelo padrão inicial e pode ser totalmente otimizável pelo

desenvolvedor.

O Framework Web2py foi buscar no modelo RBAC sua configuração de segurança para o sistema MVC, já que os módulos precisam de autenticação para o acesso ao container e a segurança proposta pelo web2py necessitaria de um modelo aprovado. Como o acesso a esses controles precisam ficar no inicio ou no fronte do desenvolvimento proporcionando que o administrador permita ou não que os usuários utilizem as funções da regra de negócio no controlador e buscando os acessos ao model. O container do web2py pode ser mostrado na figura abaixo:

Figura nº 1 – Container do Modelo MVC com RBAC no Web2py.

O container do MVC utilizado pelo web2py, proporciona uma

segurança em camadas onde o cliente fica totalmente separado das regras de

negócio e a ORM de banco de dados, isto faz com que o web2py se preocupe

bastante com a segurança. Na figura acima conseguimos identificar bem estas

camadas, onde na View, que é a camada de visão, onde insere-se códigos

HTML, JavaScript, Python ,CSS e suas derivações. Nesta camada

acomodamos as entrada de dados que através de um Request(Requisição) é

inserido em uma tabela um dado ou simplesmente é pretendido uma resposta

através da busca de resultados. O dado é transferido pela nuvem de internet

e a Camada entre a View e o Controller é controlado o acesso pelo modelo

RBAC que faz parte de um controlador especial o controlador “appadmin.py”,

neste controlador o dado é analisado e neste momento existe uma operação

de checagem para conferir, se o que se está pretendendo é uma consulta ou

uma autorização para iniciar um processo de autenticação e continuidade

dando as devidas permissões para utilizar as funções do sistema pretendido.

Feita esta checagem e havendo autenticidade da informação um

Response(Resposta) é enviada com a autorização ou com o resultado da

pesquisa obtida la no cliente, para isso RBAC faz o controle desta solicitação

através de sua camada, mas utilizando dialetos SQL do Web2py, este dialeto

vai percorrer funções especificas no controlador appadmin.py , já citado

anteriormente, para validar o que se pede. Sendo autenticação a classe Auth

entra em ação, onde em suas tabelas ficam armazenados os dados de

Usuários, Grupos e permissões, onde iremos ver com mais detalhe a frente.

Sendo somente uma pesquisa publica, não necessariamente precisa-se de

uma autenticação, vai ai do tipo de busca que se necessita, sendo

informações publicas haverá um pedido e uma resposta ou um request e um

response naturalmente.

4- A classe Auth, a mãe do RBAC no web2py?

Figura nº 2 – Menu principal do Database Administration

O Auth é o grande mago do código do web2py, para entendermos o Auth

precisamos compreender de como o framework funciona e para que serve o

Auth. Pode-se fazer uma analogia como uma pessoa que precisa entrar em um

estabelecimento, é claro que para entrar em uma residência, precisa-se passar

por uma porta e esta porta deve haver uma chave, presume-se, fazendo uma

analogia com este tipo de investida pode-se ainda ir mais longe , esta

residência tem a porta de acesso diretamente para a rua?, tem algum portão

antes? É em um condomínio com guarita? É em algum prédio?, seriam varias

as variantes que estabeleceriam está adentrada ao imóvel, passar por uma

porta ou seja entrar em um ambiente, quer dizer sair de uma local para o outro,

se esta porta tem acesso publico, como as portas de vidro automáticas de

aeroportos, shoppings, lojas de magazine, etc.. o acesso e direto e simples,

mas se esta investida é em um edifício ou na residência privada, ou em uma

repartição publica, ou escritórios privados, precisamos de uma autorização.

Esta autorização ela é feita mediante uma identificação, se o pretendente se

identifica, ele pode ou não ter uma permissão para adentrar ao ambiente ou

para adentrar para um local específico.

A classe Auth existe no web2py para fazer exatamente isto, ela é a

responsável pela criação das tabelas automáticas iniciais que irá fazer este

armazenamento de dados e a partir deste modelo de relacionamento

implementar o RBAC que será utilizado ou não, depende do tipo da aplicação

se ela será publica ou privada. Se à aplicação necessita de segurança com

identificação, autenticação, permissões, restrições, grupos o RBAC é o modelo

escolhido por ele, veja na Figura nº 3 a estrutura da classe Auth.

A maneira de acesso as funções do web2py são através de funções

endereçadas em uma url, seguindo o padrão do MVC então em uma Url http://

localhost:8000/admin/default/index.html a tradução desta url seria: localhost

(host), 8000(Porta),admin(Nome da aplicação), default(Nome do

controlador,default.py),index.html (index = função e .html a view html de saída

para a função index.). Sempre será desta forma http://host[porta]/aplicação/

controlador/view.

Figura nº 3 – Tabelas da Classe Auth

Quando iniciamos uma nova aplicação no framework web2py, a

classe Auth cria para o desenvolvedor um sistema de autenticação RBAC

pronto para se utilizar em produção, independente de se utilizar ou não o

sistema é oferecido para toda aplicação criada. Esta aplicação é totalmente de

código aberto podendo ser otimizável, novos campos podem ser inseridos nas

tabelas ou suprimidos ou ainda alterados.

As tabelas do Auth se submetem a uma hierarquia:

Auth_user: Salva o nome, endereço de e-mail, senha e status(pendente de registro, aguardando aceite ou bloqueado ) do usuário , figura abaixo.

Figura nº 4 – Tabela auth_user

auth_group: Salva funções para usuários ou grupos em uma estrutura de muitos-para-muitos. Por default, cada usuário está em seu próprio

grupo, mas um usuário pode estar em vários grupos e cada grupo pode

conter múltiplos usuários. Um grupo é identificado por um papel(Role) e

uma descrição.

Figura nº 5 – Tabela auth_group

auth_membership: vincula usuários e grupos em uma estrutura de muitos-para-muitos.

Figura nº 6 – Tabela auth_membership

auth_permission: vincula grupos e permissões. Uma permissão é identificada por um nome e, opcionalmente, em uma tabela e um

registro. Por exemplo, membros de um determinado grupo podem ter

permissões para alterar um registro específico em uma tabela especifica.

Figura nº 7 – Tabela auth_permission •

auth_event: registra as modificações e acessos de logins bem sucedidos nas tabelas do Auth através de um CRUD controlados por RBAC.

Figura nº 8 – Tabela auth_event

5 – Utilizando o RBAC, sem sentir.

Inicialmente, não há uma limitação dos nomes de funções ou permissões;

o desenvolvedor pode criá-los de acordo com as exigências dos nomes das

organizações ou ficar livre para escolher. Uma vez que eles forem criados,

web2py fornece uma API de gerenciamento para verificar se um usuário é

autenticado, se um usuário é um membro de um grupo particular, ou se o

usuário for um membro de qualquer grupo que tenha uma permissão específica

atribuída a ele próprio.

Para utilizar o RBAC, os usuários precisam ser identificados. Isso significa

que eles precisam de um registro (ou ser(em) registrado(s)) e depois logar na

aplicação. A Classe Auth fornece vários métodos de login. O padrão consiste

em identificar os usuários com base na tabela local auth_user.

Alternativamente, ele pode logar usuários vindo de outros sistemas,

autenticação de terceiros e logon único com provedores tais como Google,

PAM, LDAP, Facebook, LinkedIn, Dropbox, OpenID, OAuth, etc... Para

começar a usar Auth, você precisa pelo menos esse código em um arquivo de

modelo, que também é fornecido com a aplicação de inicial "Welcome" do

web2py e supõe que um objeto de conexão exista com a variável de nome db:

1.from gluon.tools import Auth

2.auth = Auth(db)

3.auth.define_tables(username=False,signature=False)

Figura nº 9 – Código python (configuração no db.py)

Por padrão web2py utiliza o e-mail como Login. Se você deseja utilizar o

nome como tipo de Login l então você precisa na criação das tabelas linha n.3

acima auth.define_tables(username-True, signature=True). A Configuração da

opção signature=True adiciona nas tabelas do auth o usuário e a data para

uma posterior auditoria ou simplesmente checagem de movimentação e etc. o

Auth também tem uma forma de forçar uma autenticação segura, é a opção

secure=True que forçará o uso da pagina em https.

Também por default o Auth, mesmo não sendo aqui o assunto debatido,

mas precisaríamos citar a segurança neste momento em que a classe protege

logons contra cross-site request forgeries (CSRF). Isso na verdade é fornecido

pela proteção de CSRF padrão do web2py, sempre que formulários são

gerados em uma sessão. Para que estes controles sejam acessados pelo

administrador do sistema, a classe Auth necessita ser invocada por uma função

em um controlador (o default.py ), tem este nome por ser o controlador default

da aplicação modelo que é oferecida como exemplo para desenvolvimento do

web2py.

Figura nº 10 – URL’s default.py – Função user():

Web2py apresenta o resultado da função “user():” em uma visão HTML

simples em: "http://[...]/welcome/views/default/user.html" , como mostra o

código na figura abaixo:

Figura nº 11 – default/user.html – Retorno da função user():

Observe que essa função simplesmente exibe um formulário e, portanto,

ele pode ser personalizado usando a sintaxe html, js e python normal ou de

forma personalizada. A única ressalva é que o formulário exibido pelo

form=auth() depende do request.args(0); Portanto, se você substituir o

formulário de login padrão do auth(), com um formulário de login personalizado,

pode ser necessário um “if” na instrução, como está no modo de exibição da

linha nº 6 da figura acima.

A visão descrita na figura de numero 10, expõe varias ações

contidas no framework web2py e acessadas pelas urls listadas a seguir:

a. http://.../[app]/default/user/register - Permite que os usuários se

registrem, é integrado com CAPTCHA que por padrão é dasativado. O

login vem integrado com uma calculadora de entropia (Disponível em:

http://www.mat.ufmg.br/~tcunha/entropia.pdf acessado em: 29/08/2014),

não entraremos em detalhe sobre a entropia, foge de nosso escopo,

mas no link ao lado tem uma vasta literatura interessante sobre suas

teorias. A calculadora indica a força da nova senha. Você tem a opção

de utilizar um validador próprio o “IS_STRONG” para que o web2py não

aceite senhas fracas, esta calculadora fica do lado cliente e seu código

pode ser visto no arquivo “web2py.js” de cada aplicação.

Figura nº 12 – default/register.html – Registo de Usuários

b. http://.../[app]/default/user/login - login permite que os usuários que são

registrados para logar-se (se o registo é verificado ou não exige

verificação, se foi aprovado ou não requer aprovação, e se ele está ou

não está bloqueado).

Figura nº 13 – default/login.html – Autenticação de Usuários

c. http://.../[app]/default/user/logout - Logout faz o que você esperaria, mas

também, como os outros métodos, registra o evento em auth_event e

pode ser usado para acionar um evento.

LogoutUsuário logado

Figura nº 14 – default/logout.html – Logout de Usuário

d. http://.../[app]/default/user/profile - Profile permite aos usuários editar seu

perfil, ou seja, o conteúdo da tabela auth_user. Observe que essa tabela

não tem uma estrutura fixa e pode ser personalizada, como mostra a

figura nº 14.

Figura nº 15 – default/user/profile – Alterar dados do Usuário

e.

http://.../[app]/default/user/change_password - Altera senha atual.

Figura nº 16 – default/user/change_password – Altera senha atual.

As próximas url’s listadas abaixo, não apresentam visões html, são

controladas através de parâmetros de habilitação ou não, vejamos:

f. http://.../[app]/default/user/verify_email – Se a verificação de e-mail

estiver ativada, então o visitante, na hora de confirmar o registro,

receberá um e-mail com link para verificar as informações fornecidas no

registro. O link fornecido apontará para esta ação.

g. http://.../[app]/default/user/retrieve_username - Por padrão a classe Auth

usa e-mail e senha para login, mas pode-se personalizar, usar o nome

do usuário ,por exemplo, neste caso se o usuário esquecer o nome do

usuário que foi cadastrado , basta digitar o endereço de e-mail e ai

receberá em seu e-mail os dados da recuperação do seu usuário

h. http://.../[app]/default/user/request_reset_password - Permite a

recuperação de senhas esquecidas pelos usuários. Se escolher esta

opção, receberá em seu e-mail link apontando para a opção de

recuperação.

i. http://.../[app]/default/user/reset_password - recebido o link por e-mail na

opção de request reset password, esta opção permite que você crie uma

nova senha.

j. http://.../[app]/default/user/groups - Lista de grupos dos quais o usuário

atual que estiver logado é membro.

Por padrão, todos eles estão habilitados para o funcionamento, mas é

possível restringir o acesso a apenas algumas dessas ações. Todos os

métodos acima podem ser estendidos ou substituídos por subclassificação no

Auth. Também todos os métodos podem ser usados em ações separadas.

Exemplo:

def meulogin(): return dict(form=auth.login())

def meuregistro(): return dict(form=auth.register())

def meuprofile(): return dict(form=auth.profile())

Para restringir o acesso um decorator é utilizado antes da função de login,

assim o visitante terá que se registrar para utilizar esta função.

Figura nº 17 – Função ola(): em um controlador

Qualquer função pode ser precedida de um decorador ou decorator

que suprime a ação direta a função, exigindo um login. Claro, este é apenas um

exemplo muito simples de controle de acesso. Exemplos mais complexos serão

discutidos mais adiante.

A tabela auth_user contém uma cópia dos registos de quem está

atualmente logado, o usuário ou None. Há também um auth.user_id que é o mesmo que auth.user.id (ou seja, a identificação do agente), ou None. Da

mesma forma, o auth.user_groups contém um dicionário onde cada chave é a

identificação de um grupo com o qual o usuário atual logado é membro, o valor

da chave é o papel exercido no grupo correspondente.

Todos os componentes do Auth para o funcionamento do RBAC foram

apresentados, e formando o princípio da segurança RBAC em web2py.

¨6 – Autorização e Decoradores ( @ )

Como foi mostrado na seção 5 acima, após o cadastro de um usuário ,

automaticamente ele já estará em um grupo onde ficará registrado seus

passos , mas ainda pode-se implementar uma configuração especial de

permissões e papeis para este usuário, veremos a seguir. Quando criamos um

papel atribuído na base de dados será user_[id] onde [id] é o ID do novo

usuário. Se não desejar que esta criação se torne automática pode desabilitar

a criação de grupos com o comando ‘auth.settings.create_user_groups = None’

no seu model.py (arquivo python inicial de configuração). Desta forma podemos

personalizar e criar grupos, endereçar os membros e permissões para estes

membros de grupos no ‘appadmin’ como foi mostrado no inicio. A forma mais

comum de verificação de permissão não é por chamadas explícitas para os

métodos, mas por funções decoradoras antes das funções reais. Aqui estão

alguns exemplos:

a. @auth.requires_login() # Decorador que requer Login

def exemplo_1(): # inicio da função exemplo_1

return 'Requer um login' # Retorno da função

b. @auth.requires_membership('agente') # Decorador requer que o

usuário participe

def exemplo_2(): # do grupo com o papel de agente

return 'So aceita os agentes'

c. @auth.requires_permission('read', secreto) # Leitura aos que

participem

def exemplo_3(): # do grupo com o papel secreto

return 'Só ler documentos secreto'

d. @auth.requires_permission('delete', 'todos Arquivos') #

permissão para deletar

def exemplo_4(): # todos os arquivos

import os # Se utilizada

for file in os.listdir('./'):

os.unlink(file)

return 'Todos arquivos deletados'

e. @auth.requires(auth.user_id==1 or request.client=='127.0.0.1',

\ requires_login=True)

def exemplo_5(): #Aqui se o usuário for o ID nº 1 e estiver em

return 'ler documentos secreto' # localhost e se Logado entra

na função.

f. @auth.requires_permission('add', 'number') # Prepara uma função

para receber

def add(a, b): # dois parametros

return a + b # e soma-los no retorno

g. def exemplo_6(): # reaproveitamento da função add

return add(3, 4)

Como se pode observar, os decoradores podem estabelecer

condições prévias para que a função seja executada, e isto não fica do lado

cliente, são regras de negócio estabelecidas nos controladores, que ecoam na

visão aguardando que uma entrada request seja estabelecida em um args(),

com o preenchimento e a condição que o decorador estabeleceu, se foi um

simples ‘@auth.requires_login()’ ou até uma decorador mais incrementado do

tipo ‘@auth.requires(auth.user_id==1 or request.client=='127.0.0.1',

requires_login=True)’.

O Artifício do decorador é uma forma muito segura de estabelecer os

critérios de permissões, distribuir papeis exclusivos na administração do

sistema.

Pode implementar o controle de acesso através de um modulo

administrativo, de decoradores antes das funções ou pode também

simplesmente criar um modulo CRUD para gerenciar estes papeis e

permissões. O Web2py permite que no gerenciamento isto fique a escolha do

desenvolvedor com a melhor maneira de administrar o sistema. Isto impedirá

que o visitante de acessar qualquer uma das funções CRUD, a menos que o

visitante esteja logado e tem acesso permitido. Por exemplo, para permitir que

um visitante possa postar comentários, mas apenas atualizar os seus

comentários (vamos supor um crud, auth e a tabela chamaremos de

db_comentarios estejam definidas já):

def cria_fornece_permissao(form):

group_id = auth.id_group('user_%s' % auth.user.id)

auth.add_permission(group_id, 'read', db.comentarios)

auth.add_permission(group_id, 'create', db.comentarios)

auth.add_permission(group_id, 'select', db.comentarios)

def altera_fornece_permissao(form):

comentarios_id = form.vars.id

group_id = auth.id_group('user_%s' % auth.user.id)

auth.add_permission(group_id, 'update', db.comentarios,

comentarios_id)

auth.add_permission(group_id, 'delete', db.comentarios,

comentarios_id)

auth.settings.register_onaccept = cria_fornece_permissao

crud.settings.auth = auth

def posta_comentarios():

form = crud.create(db.comentarios, onaccept=

altera_fornece_permissao)

comentarioss = db(db.comentarios).select()

return dict(form=form, comentarioss=comentarioss)

def atualiza_comentarios():

form = crud.update(db.comentarios, request.args(0))

return dict(form=form)

As permissões pre-estabelecidas para utilização são: ‘read’, ’create’,

’update’, ‘delete’, ‘select’, ‘impersonate’. Este exemplo acima é um exemplo de

aplicação de postagem de mensagens, que que se utiliza RBAC para gerenciar

as permissões de usuários e o que eles podem realmente fazer com o registro

que esta sendo postado ou com registros que já existam, podem criar, ler,

consultar ,alterar e deletar , podem fazer o que quiser na verdade, pois não

temos nenhum decorador impedindo ou solicitando uma autenticação ou

validando uma condição para que seja executada alguma operação. Veja que

a função de cria_fornece_permissao(form): não tem a opção de deleção nem

de alteração, ela somente ler, cria e seleciona, mas nada impede o usuário de

utiliza-la, pois ele precisa postar comentários, então logo a opção de criar é

permitida livremente. A segunda função de altera_fornece_permissao(form): ,

se altera e deleta os registro. Veja também que estas duas funções tem retorno

o próprio formulário, então fica claro que são funções que serão utilizadas

como validadoras de ações de outras funções, que vem logo abaixo que seria

a função posta_comentarios e atualiza_comentarios.

7 – Considerações Finais

Web2py por ser de código aberto e livre oferece inúmeras maneiras de

gerenciamento, cada desenvolvedor se não quiser dispor ou se utilizar das

ferramentas oferecidas de fabrica do web2py, podem criar suas próprias api’s,

contando que se utilizem da regra do Modelo RBAC para fazer seus papeis e

permissões, e permanecer com a continuidade ao modelo criado por Ferraiolo,

D.F. and Kuhn, D.R. (October 1992). "Role-Based Access Control" (PDF). 15th

National Computer Security Conference: 554–563. Sandhu, R., Coyne, E.J.,

Feinstein, H.L. and Youman, C.E.. (August 1996). "Role-Based Access Control

Models" (PDF). IEEE Computer 29 (2): 38–47 pp.. IEEE Press.

Desenvolver para a Internet é o futuro da programação de computadores

e quanto antes conhecer as facilidades para isto, mais o profissional de

desenvolvimento ganha na corrida do compromisso com a qualidade e a

disponibilidade de serviços para internet. O web2py está ai pronto e é grátis ,

para qualquer desenvolvedor utilizar os meios mais simples de produzir suas

aplicações em nuvem e com simplicidade.

Referências

1. DF Ferraiolo e DR Kuhn (1992) (Disponível em: < http://csrc.nist.gov/rbac/

sandhu-ferraiolo-kuhn-00.pdf > Acessado em 01/09/2014).

2. D.F. Ferraiolo and D.R. Kuhn (1992) "Role Based Access Control" 15th

National Computer Security Conference, Oct 13-16, 1992, pp. 554-563. -

introduced formal model for role based access control Disponível em: <http://

csrc.nist.gov/groups/SNS/rbac/documents/

Role_Based_Access_Control-1992.html> Acessado em: 01/09/2014).

3. Di Pierro Massimo – Web2py Book ( Disponível em: <http://www.web2py.com/

books/default/chapter/29/09/access-control > Acessado em 01/09/2014)

4. Classe Auth – Implementando RBAC (Disponível em: <http://localhost:8000/

web2py/applications/examples/static/epydoc/web2py.gluon.tools.Auth-

class.html> acessado em 01/09/2014)

5. RBAC – (Disponível em: http://csrc.nist.gov/groups/SNS/rbac/ Acessado em:

01/09/2014)

comentários (0)
Até o momento nenhum comentário
Seja o primeiro a comentar!
Esta é apenas uma pré-visualização
Consulte e baixe o documento completo
Docsity is not optimized for the browser you're using. In order to have a better experience we suggest you to use Internet Explorer 9+, Chrome, Firefox or Safari! Download Google Chrome