44 comentários

• Eduardo Santos(usuário não autenticado)

  22 de Junho de 2007, 15:01

   

  Olá Juliano. Bastante interessantes suas dúvidas. Vou tentar responder e tenho certeza que o pessoal da comunidade pode complementar.

  1 - Em relação à necessidade de clicar em sair, isso pode ser controlado por alguns parâmetros do kernel. O parâmetro AllowPersistentLoginP diz se vc deseja que o cookie nunca expire, ou seja, se o usuário deve ser deslogado quando religar o computador. Existe o LoginTimeout que diz o maior tempo possível para o usuário ficar logado; após esse intervalo ele tem que digitar sua senha. Acesso o link /admin/site-map e clique sobre o pacote kernel para verificar seus parâmetros. Por padrão, como o OpenACS é muito utilizado em instituições de ensino, o parâmetro AllowPersistentLoginP está definido como 1, o que também é o padrão aqui para o Portal, mas pode ser alterado de acordo com sua política de utilização.

   2 - Em relação aos logs e à ferramento user-tracking, depende do que você pretende fazer. É possível sim observar o log do servidor; para isso existe o pacote monitoring. Todavia, não há como tornar um log totalmente legível, pois ele acaba contendo coisas ininteligíveis. Se deseja saber sobre todos os usuários que acessam o site,  o User-tracking nada mais é que uma interface para o OpenACS da aplicação AWSTATS, bastante conhecida e que traz bastante informações. O que o pacote faz é executar o awstats e pegar somente as informações que ele considera necessárias para o sistema. Vc pode utilizar a própria aplicação ou "incrementar" o pacote User-tracking solicitando-lhe que mais informações sejam reolhidas. Ambos requerem algum conhecimento, e precisaria saber qual o seu nível de entendimento em OpenACS e desenvolvimento Web como um todo para ser mais específico.

  3 - É possível sim alterar a forma de login. O OpenACS atualmente autentica no LDAP, tem uma integração com o moodle no PHP/Apache, aceita conexão https para login e tem algumas outras funcionalidades de segurança já implementadas, mas você sempre pode criar a sua. Afinal, é software livre. 

  4 - É até bastante fácil desablitar essa opção no código, mas não tenho certeza se isso é controlado por parâmetro. Vou verificar e te respondo depois, mas por que vc quer retirar essa opção? É importante lembrar que ela é disponível somente para o adminstrador do site inteiro; nem sequer o administrador de um subsite tem essa opção.  

  Espero ter ajudado. Continue postando suas dúvidas, pois elas engradecem a comunidade. Abraços!!! 

  
  
• Orzenil Silva Junior(usuário não autenticado)

  23 de Junho de 2007, 1:46

   

  Olá Juliano,

   vou procurar apenas complementar as respostas que o Eduardo já passou nesse tópico.

  Mas parece-me, e corrija-me se eu estiver enganado, que as suas dúvidas sobre segurança e auditoria se referem mais a negociações do cliente (navegador web) com o servidor web (no caso do OpenACS, o AolServer) do que propriamente ao funcionamento dos softwares OpenACS-like (dotLRN, ProjectOpen, dotCommunity etc). É nesse sentido que tento complementar as respostas.

  Dúvida 1.  o Eduardo lembrou bem o parâmetro sobre persistência de login e do controle oferecido pelo OpenACS por meio de parametrização do pacote acs-kernel.

  Dúvida 2.  a questão não tem  relação com o OpenACS. Você pode escolher qualquer software livre ou proprietário que você desejar para analizar e produzir logs legíveis. A sua única questão vai ser configurar o arquivo config.tcl de configuração do servidor web AolServer para produzir o formato de log desejado e esperado pelo analisador que você deseja usar.

  O pacote user-tracking é oferecido pelo OpenACS para contabilizar acesso de usuários a objetos específicos do sistema (mensagens de fóruns, faqs, arquivos no file-storage etc). Essa contabilização é relevante no caso de rastreamento para fins por exemplo de um curso online em que você deseja saber as leituras realizadas por um estudante. Com certeza, e como vc bem relata, essas informações podem não ser necessárias e muito menos relevantes no caso de auditoria e segurança.

  Como sugestão de bons analisadores de log você pode usar o próprio awstats (http://awstats.sf.net) que vem com o user-tracking. Veja que não é preciso instalar o user-tracking,você pode diretamente usar o awstats somente e configurar adequadamente o config.tcl para produzir formatos reconhecidos pelo awstats. A vantagem do awstats é que vc tem uma série de plugins disponíveis (http://awstats.sourceforge.net/docs/awstats_contrib.html#PLUGINS). Inclusive, você pode programar os seus proprios plugins awstats (por exemplo, o user-tracking simplesmente utiliza o plugin userinfo um pouco modificado para coletar os dados de acesso de usuários a object_id de objetos openacs)

  Dê 1 olhada em www.​cogn​ovis​.de/​deve​lope​r/en​/aws​tats​_set​up para ver um exemplo de configuração do awstats para o AolServer utilizando alguns plugins.

  Outros analisadores de log são o Analog (http://www.analog.cx/) ou o Webalizer (http://www.mrunix.net/webalizer/)

  Se você desejar pode até desenvolver pacotes OpenACS que atuem como frontend para outputs gerados por esses analisadores :-) 

  Dúvida 3. Mais relacionada com o OpenACS mas também diz mais respeito ao AolServer.  Se entendi bem o que você deseja é que um usuário autentique-se em um site web OpenACS/dotLRN usando um certificado tipo A3 ICP-Brasil, é isso?

  Bom, o AolServer possui integração com autenticação PAM via o módulo nspam. O OpenACS provê uma interface com o nspam por meio do pacote auth-pam. Até onde me lembro, o ITI tem um pacote PAM, produzido pela empresa módulo, com suporte ao certificado tipo A3 ICP-Brasil. Não sei como isso funciona (ou se está disponível) mas creio que poderia ser uma maneira de abordar o seu problema. Se isso for viável, e uma vez resolvida o uso do módulo pam com certificação ICP-Brasil no Aolserver seria bastante simples trabalhar os módulos auth-pam e o acs-authentication do OpenACS para prover a interface necessário para o login dos seus usuários.

  Sobre PAM com o AolServer/OpenACS veja open​acs.​org/​doc/​acs-​auth​enti​cati​on/e​xt-a​uth-​pam-​inst​all.​html

  Dúvida 4. Essa aí é fácil de resolver com adição de parâmetro no OpenACS (se ele já não existir... não me lembro).

  Um abraço

  
  
• Orzenil Silva Junior(usuário não autenticado)

  23 de Junho de 2007, 13:43

   

  Juliano,

  esqueci de colocar na mensagem anterior e talvez possa te ajudar em algum esclarecimento adicional quanto a sua dúvida 1, sobre persistência de login.

  É importante que você saiba que você saiba que independente da configuração sobre login persistente na sua instalação OpenACS, a senha do usuário nunca fica armazenada em cookie.  O que é armazenado no cookie é um token computado utilizando o módulo nssha1 do AolServer e que o sistema usa para identificar que aquele usuário em um momento anterior sabia qual é a sua senha.

  Existem basicamento dois cookies que são enviados no login: ad_user_login e ad_user_login_secure. O segundo é enviado quando você tem todo o seu site ou parte dele usando https.  Também existe um cookie para a sessão chamado ad_session_id, que é sempre enviado para qualquer usuário que estabelece uma conexão ao site. O cookie ad_session_id não é persistente, e deve existir enquanto o navegador estiver aberto. É possível que você configure também o tempo de expiração desse cookie tornando o comportamento dele mais predizível. Tanto os parâmetros de persistência de login (nos cookies ad_user_login/ad_user_login_secure) quanto o de expiração da sessão (ad_session_id) têm o comportamento controlado por parâmetros do pacote acs-kernel.

  No entanto, mesmo sem armazenar a senha, é óbvio que o token gerado quando o login é definido como persistente pode causar insegurança uma vez que o cookie poderia ser roubado da maquina do usuário e colocado em uma outra máquina. Por essa razão, creio, que a sua preocupação é muito pertinente uma vez que poderia ser muito danoso permitir que administradores do seu sistema pudessem ter login persistente.

  O que tenho feito no caso de sites seguros com OpenACS é, além de restringir partes deles com https, é modificar o script de login para previnir que grupos de administradores do site possam logar de forma persistente. Para isso basta você alterar o comportamento do script

  packages/acs-subsite/lib/login.tcl

  acrescentando a restrição de que um determinado grupo não possa ter login persistente. Por exemplo, crie um  grupo qualquer (' Staff'). Adicione, usuários a esse grupo. No script login.tcl, em

  if { $allow_persistent_login_p } {
   set default_persistent_login_p [parameter::get -parameter DefaultPersistentLoginP -package_id [ad_acs_kernel_id] -default 1]
  } else {
    set default_persistent_login_p 0
  }

  subsititua por:

  if { $allow_persistent_login_p } {
       if [db_string is_staff_member {
          select count(1)  from group_member_map m, groups g
           where m.group_id = g.group_id and g.group_name = 'Staff'
      }] {
          set default_persistent_login_p 0
      } else {
      set default_persistent_login_p [parameter::get -parameter DefaultPersistentLoginP -package_id [ad_acs_kernel_id] -default 1]
      } 

  } else {
    set default_persistent_login_p 0
  }

  Dê uma olhada também em:

  www.​open​acs.​org/​doc/​curr​ent/​secu​rity​-des​ign.​html
  www.​open​acs.​org/​doc/​curr​ent/​secu​rity​-not​es.h​tml

  para mais informações.

  
  
• Juliano Neves(usuário não autenticado)

  25 de Junho de 2007, 10:01

   

  Inicialmente, muito obrigado ao Eduardo e ao Orzenil pela presteza e qualidade das respostas fornecidas.

  Eu encontrei o módulo PAM do ITI disponível para download no sítio deles:

  www.​iti.​gov.​br/t​wiki​/pub​/Cer​tifi​caca​o/Do​wnlo​adSw​/Mod​ulo_​pam.​tar.​gz

  Vou pesquisar sobre a integração dele com o AolServer e, caso tenha sucesso (ou dúvidas), relato a experiência aqui no fórum.