Stoa :: Ewout ter Haar :: Blog :: OpenID e a USP

maio 08, 2007

default user icon
Postado por Ewout ter Haar

Semana passada fiz uma apresentação sobre OpenID para a USP. A sua identidade na rede é um problema cada vez mais urgente. Usamos muitos serviços no google, yahoo, msn, flickr, terra, uol, etc. etc. e temos uma identidade em cada um destes serviços. Precisamos comprovar que somos nos no outro lado da rede por meio de uma senha e mesmo assim, o serviço não pode confiar que uma pessoa realmente é quem ele/ela diz que é: "no internet, ninquém sabe que é cachorro".

O problema

Uma maneira tradicional de resolver o problema de identidade e senhas no meio corporativo é via um serviço de autenticação como LDAP. Tem dois problemas com LDAP que devem ser resolvidos com um sistema complementar:

  1. Para autenticar pessoas cada serviço (por exemplo Jupiter, o webmail da USP) pede a senha e autentica contra a base LDAP (central ou replicado) e isto significa que cada um dos serviços devem ser seguros e confiáveis: lidam com a senha única do usuário afinal. Isto implica numa barreira de entrada muito grande para serviços potencialmente inovadores e úteis oferecidos por grupos não diretamente ligado aos orgoes centrais. Estamos vivendo uma "democratização" do software de serviços. Qualquer um hoje em dia pode instalar um stack LAMP na sua máquina e começar desenvolver e oferecer serviços como blog, wiki, fóruns, etc. à comunidade USP. Estes desenvolvidores se beneficiaram muito se tivesse uma maneira de autenticar alguem como sendo da comunidade USP sem ter que passar pelos trâmites para obter acesso aos bases de dados corporativos da USP.
  2. LDAP fornece uma senha única, mas não oferece single sign on (SSO): o usuário tem que se logar e fornecer os seus credenciais em cada serviço que ele usa.

A proposta

O protocolo OpenID se propõe resolver parcialmente estes problemas. Com OpenID uma pessoa se identifica com um URL, por exemplo http://openid.usp.br/155469 ou htt//ewout.org. O usuário escolha um Provedor de Identidade (IdP) que gerencia este identidade. Nunca mais vai dar uma senha a um serviço onde é preciso criar uma conta: se o serviço suporta OpenID, o usuário se loga com o seu OpenID, o serviço redireciona para o IdP que faz a autenticação no serviço por trás das cortinas. Veja este demo do Simon Willison para ver como funciona do ponto de vista do usuário.

Uma possibilidade é que a USP ofereça um OpenID do tipo http://openid.usp.br/155469 para todo mundo. Este servidor (provedor de identidade OpenID) seria simples de implementar e manter. Poderia ser ligado com o base de dados LDAP num lado e usar senha/passwd ou certificados no lado do usuário. O DI poderia implementar a certificação das pessoas, gerenciamento da senha, etc. O fato que alguém tenha um OpenID no IdP openid.usp.br comprovaria que este pessoa é da comunidade USP.

Assim,

  • Desenvolvedores de serviços para a comunidade USP como stoa.usp.br, moodle.usp.br ou os serviços (por agora imaginários) wiki.fea.usp.br ou moodle.fe.usp.br podem configurar o seu software para usar OpenID como login. Para acertar que alguém é da comunidade USP estes serviços devem tratar os OpenID associdados com o IdP openid.usp.br como sendo da USP e tratar outros OpenID como "de fora".
  • Os nossos usuários podem usar este OpenID dentro e fora da USP.
  • Ou, usando delegação, os usuários podem configurar um OpenID deles mais amigável, por exemplo http://stoa.usp.br/ewout/ , continuando usando o servidor openid.usp.br

É uma solução SSO que pode estar pronto muito rapidamente, já que existem muitas bibliotecas e até servidores inteiros prontos.

Mais sobre OpenID

OpenID é um sistema onde o usuário pode controlar a sua identidade. Ao contrário de sistemas centralizados como o antigo Passport do Microsoft, o usuário escolha o seu IdP e pode mudar de provedor quando quiser. É importante que isto implica que um serviço do web não pode "confiar" num OpenID: qualquer um pode rodar o seu IdP e um OpenID pode ser associado a qualquer IdP. Em geral, a única coisa que um IdP faz é dizer: este pessoa que se cadastrou conosco controla esta URL. É só no caso do openid.usp.br que, na minha proposta, pode confiar que o DI cadastrou uma pessoa real com um determinado número usp, etc.

Do ponto de vista técnica, OpenID é uma tecnologia que faz pouco, mas faz bem. As principais vantagens são

  • OpenID é uma solução usando tecnologias "light-weight" e "do web": DNS, HTTP, URLs, etc.
  • É fácil de implementar (bibliotecas para PHP,Python, Ruby, Java, etc.)
  • É uma padrão aberta, com suporte global: um OpenID é usável no internet inteiro. A sua identidade é dereferenciável, fácil de lembrar (o meu OpenID é http://ewout.org/).
  • É um protocolo simples e são as aplicações desenvolvidos usando o protocolo que fornecem a "intelligência".

Porém, tem que ser claro que OpenID, do jeito que está, não implementa nenhum tipo de perfil ou papeis. Existem planos para extender o protocolo, mas hoje as únicas atributos que um serviço pode pedir de um IdP OpenID são somente os da extensão SREG: nome, email etc. Certamente a USP vai ter que implementar ou uma outra camada em cima de OpenID ou um outro protocolo SSO como Liberty ou Shibboleth para oferecer estes informações aos vários serviços.

Palavras-chave: identidade, openid

Postado por Ewout ter Haar

Comentários

  1. Nelson escreveu:

    Queria comentar que o "LDAP" por si só funciona como um repositorio de dados
     e informacoes assim como um banco de dados em MySQL, ou arquivos /etc/password e
     /etc/shadow dos sistemas operacionais Linux/Unix.

    A maioria das aplicacoes que usa o LDAP para se autenticar usa o de uma forma bem
    particular, por que nao existe algum modo "padrao" para se usar o LDAP. Com o LDAP
    podemos criar diretorios ou catalogos quaisquer mas nao existe uma regra dizendo
    como devem todos os catalogos. Os modos de acessar organizacao de catalogos sao
    conforme a conveniencia do criador do  catalogo  e das  necessidades  do  usuario do
    catalogo: Um lista telefonica e bem diferente de um catalogo de pecas de automoveis,
    que por sua vez sao bem diferentes  de um catalogo de  itens  de cosmeticos, etc.

    Quando se fala em diretorios centrais de identidade acaba-se mencionando LDAP pois ele
    é melhor quando se faz poucas escritas de dados e se faz muitas leituras aos dados gravados.

    Na minha opiniao, mesmo sem ter uma solucao de como se poderia chegar a isso, é que
    a identidade centralizada deve contar com um sistema que fundido ou nao com os sistemas
    da DI, permita que cada pessoa a ser identificada tenha um contato "face-to-face"  com um
    identificador responsavel que poderia ser um um funcionario credenciado ou professor credenciado
    para autenticar aquela identidade e os dados desta identidade: "alteracao de cadastro, contatos,
    mudanca de senha, comprovacao dos documentos pessoais, etc".  Com isso poderia existir uma
    ferramenta de software ( um middleware 'home-made' ou comprado ) que poderia distribuir dados
    para os sistemas que precisam desta identificacao acrescentando atributos de autorizacao conforme
    tipo de cadastro ou delegacoes que forem colocados nela, incluse ate um OpenID com URL criado
    em servidor externo e informado no "face-to-face" ou algum criado automaticamente num IdP de
    OpenID da propria USP. As aplicacoes também precisariam ser revistas, no tocante a gerencia pois
    por exemplo, se um determinado usuario fez um mal uso de uma aplicacao de rede o administrador
    deste servico deve poder suspender o usuario deste servico e esta informacao deve poder ser
    retroalimentada ate esta ferramenta de software central para que, dependendo da política de seguranca
    da corporacao se bloqueiem ou nao ate o caso ser esclarecido, deixando serviços menos críticos
    ainda autorizados ao usuario na universidade como um todo.

    Nelson_YNelson ‒ quarta, 09 maio 2007, 13:01 -03 # Link |

  2. Nelson escreveu:

    Queria aproveitar o espaço para inserir uns LINKS:

    SITE  do OpenID  http://openid.net/ com suas apresentações http://openid.net/presentations.bml

    Procurando sobre SSO ( Single-Sign-On ) - via google achei os Links:

    Falam sobre suporte a OpenID nos produtos SUN
    http://sun.systemnews.com/articles/111/2/news/18077
    http://biz.yahoo.com/prnews/070507/sfm045.html?.v=92

    Comunidade de "Gestao de Identidades" OpenSource ( nao sei se isso vai para frente ... )
    https://identitymanagement.dev.java.net/

    OpenDS
    https://www.opends.org/wiki//page/ProjectDefinition#section-Pr

    OpenSSO
    https://opensso.dev.java.net/public/about/faqcenter/faqoverview.html

    JA-SIG ( antes era CAS-Yale )
    http://www.ja-sig.org/products/

    JOSSO
    http://sourceforge.net/projects/josso/

    ===================================

    SSO
     http://www.opengroup.org/security/sso/

    SSO no Wiki
     http://en.wikipedia.org/wiki/Single_sign_on

    SSO da Microsoft - para Windows
     http://msdn2.microsoft.com/en-us/library/aa745042.aspx
    e mais ...
    Forma de arquivos *.doc ( zipados ) em Ingles:
    http://www.microsoft.com/downloads/details.aspx?FamilyId=794571E
    Forma on-line em Portugues:
    http://www.microsoft.com/brasil/technet/security/topics/identity

    Open Source Federated Identity Management
    http://www.sourceid.org/

    Incommon
    http://www.incommonfederation.org/about.cfm

    Para Identidade Federada da Internet2:
    http://shibboleth.internet2.edu/

     

     

     

    Nelson_YNelson ‒ segunda, 14 maio 2007, 17:25 -03 # Link |

  3. N.e.l.s.o.n. escreveu:

    Acrescente-se mais uma "Comunidade de Gestao de Identidades OpenSource"

    OpenPTK
    https://openptk.dev.java.net/

     

     

    Nelson_YN.e.l.s.o.n. ‒ segunda, 05 novembro 2007, 11:47 -02 # Link |

Você deve entrar no sistema para escrever um comentário.

Termo de Responsabilidade

Todo o conteúdo desta página é de inteira responsabilidade do usuário. O Stoa, assim como a Universidade de São Paulo, não necessariamente corroboram as opiniões aqui contidas.