Federação no Noosfero

Suporte à Federação no Noosfero

Já existe uma iniciativa de federação no Noosfero em desenvolvimento por parte da comunidade , tendo o autor deste trabalho colaborado desde então. O objetivo é possibilitar a integração tanto com outras instâncias do Noosfero como com outras redes sociais, o que exige a adoção de especificações que tenham o mínimo de aderência na comunidade. A utilização de padrões difundidos amplia as possibilidades de integração dentre outras redes sociais federadas.

Antes da execução deste trabalho os protocolos Diaspora e OStatus já haviam sido escolhidos como referência para a implementação da federação no Noosfero, resultado de uma observação das discussões e execução de projetos como o Hubzilla, Friendica e o próprio Diaspora.

Federação entre Redes Noosfero

As atividades de implementação de federação já desenvolvidas podem ser separadas em quatro fases, que cumpriram objetivos distintos de integração, que cobrem desde as funcionalidades até a reestruturação da arquitetura da aplicação.

Foi definido que um usuário de uma rede Noosfero pode acessar qualquer outra instância com as credenciais de sua rede de origem. Um usuário federado deve ser capaz de visualizar conteúdos públicos, comentar publicações, seguir usuários, e deixar mensagens em murais. As notificações destas interações devem ser entregues tanto aos usuários na rede local, quanto ao usuário na rede de origem.

O protocolo construído entre redes Noosfero é baseado nas especificações do WebFinger e OAuth para a descoberta de identidade e autorização de perfis, respectivamente. Em relação à comunicação entre as redes, o protocolo Diaspora foi definido como referência.

Fase 1: preparação

Até a versão 1.5 do Noosfero, todos os relacionamentos entre as entidades da rede eram baseados no conceito de relacionamento simétrico. No entanto, as demais redes federadas, e a maioria dos padrões mais implementados, trabalham apenas com o conceito de relacionamentos assimétricos, o que incentivou o desenvolvimento da funcionalidade de seguidores no Noosfero.

Na fase de preparação foram introduzidos os relacionamentos assimétricos através desta funcionalidade. Os seguidores são notificados a respeito de atividades públicas de perfis seguidos. No Noosfero, cada perfil pode permitir ou não que usuários o sigam. Usuários por sua vez organizam os perfis seguidos em círculos, categorizando suas relações.

Fase 2: intercomunicações

Durante a fase de intercomunicações foi construída a infraestrutura básica para a integração entre redes Noosfero. Ambientes e usuários externos foram introduzidos à arquitetura do Noosfero, que passa a suportar ações de usuários que não possuem perfis locais.

O conceito de usuário externo introduzido nesta fase é importante para toda a implementação da federação do Noosfero. Um usuário local do Noosfero é definido por basicamente dois objetos de negócio — um usuário, que armazena as credenciais de acesso, e um perfil, que armazena suas demais informações na aplicação.

Um usuário externo não possui credenciais de acesso na instância visitada, apenas um objeto que representa o seu perfil externo, e que do ponto de vista da implementação deve ser capaz de reproduzir o comportamento de um perfil comum. A implementação alcançada faz uso de métodos stub e relações polimórficas para a reprodução do comportamento.

Nesta fase também foi implementada a especificação do WebFinger, que já está sendo utilizada para a descoberta de usuários na autenticação entre redes Noosfero.

Inicialmente, apenas as redes listadas no diretório central do Noosfero podem ser habilitadas no painel de administração da federação. A descentralização desta lista ou a automatização do processo de descoberta não fizeram parte do planejamento inicial.

Fase 3: integração externa

A fase de integração externa teve como objetivo aproveitar a infraestrutura de usuários externos para autenticar usuários de outros serviços sem a necessidade de perfis locais. Com isto, usuários de sistemas que suportem OAuth podem acessar o Noosfero, consumir conteúdo, e executar um conjunto limitado de ações.

Durante esta etapa, o plugin que torna o Noosfero em um cliente OAuth foi evoluído para permitir que usuários possam tanto criar um perfil local a partir das informações da rede de origem, como também apenas acessar o Noosfero com um perfil temporário. Por enquanto, os únicos fornecedores OAuth suportados são o Google, Facebook, Twitter, GitHub, e o próprio Noosfero. No entanto, novos fornecedores podem ser facilmente adicionados.

Fase 4: inter-relações

A última fase de desenvolvimento da federação de redes Noosfero foi implementar o relacionamento entre usuários de instâncias diferentes. De modo geral, esta fase consistiu em permitir que usuários externos sejam capazes de seguir perfis, comentar conteúdos, e publicar em murais de outros usuários.

De forma a permitir relações entre usuários federados foi necessário refatorar a funcionalidade de seguidores, adicionando o suporte a perfis externos. Neste ponto, usuários federados podem tanto seguir usuários locais, quanto serem seguidos por eles.

Essa fase também envolve a implementação da infraestrutura de troca de mensagens, que seria utilizada nas notificações e interações entre os usuários. Até a execução deste trabalho esse mecanismo não foi completamente definido.

Demais Contribuições

A documentação da biblioteca utilizada para a implementação do protocolo não cobre todos os aspectos da especificação, portanto foi necessário instanciar dois pods locais do Diaspora para analisar a comunicação. A comunicação do Diaspora depende que cada um dos pods responda a HTTPS e seja capaz de resolver os nomes dos demais servidores.

Para os testes desse trabalho foram utilizadas duas máquinas virtuais com Debian 8 em rede privada, com os nomes registrados no arquivo de hosts para a resolução local. Em cada uma das máquinas, o Diaspora foi servido por um servidor NGINX com SSL configurado com um certificado auto-assinado. Para que a comunicação não fosse prejudicada pela verificação dos certificados, eles foram manualmente adicionados aos certificados reconhecidos em cada uma das máquinas.

Autenticação com o Diaspora

A federação através do Diaspora foi planejada com base na implementação já existente no Noosfero, que conta com um mecanismo de autenticação entre as redes. Por esse motivo inicialmente se julgou necessário permitir a autenticação de usuários com credenciais de redes Diaspora.

O Diaspora não disponibiliza nenhum endpoint de login em sua API, mas implementa o papel de fornecedor de identidades OpenID Connect, um padrão de autenticação construído sobre a segunda versão do OAuth. Portanto, a fim de utilizar as credenciais do Diaspora, é necessário que o Noosfero possa desempenhar o papel de cliente OpenID.

Mesmo que o Noosfero também forneça identidades OpenID, ainda não seria possível usar credenciais locais para a autenticação em pods Diaspora, que utiliza apenas estratégias de autenticação local. Isso reforçou a decisão de implementar apenas a função de cliente OpenID por enquanto.

Ainda que o plug-in tenha sido implementado como parte deste trabalho, o restante da federação não depende deste mecanismo de autenticação, já que os usuários só interagem com o servidor remoto através de sua rede de origem.

Desenvolvimento do plugin OpenID Client

Apesar do Noosfero já oferecer suporte à autorização com OAuth 1.0 através de um plugin, foi necessário implementar o suporte ao OpenID. A decisão foi criar um novo plugin que transforme o Noosfero em um cliente OpenID.

A gem openid_connect foi utilizada na implementação do consumidor. A biblioteca já oferece as diretrizes de descoberta, registro de clientes e autenticação, todas interações que envolvem requisições HTTP ao servidor fornecedor. Um perfil externo também é criado no Noosfero para armazenar algumas informações do perfil remoto, como link para o seu perfil, ou sua imagem do avatar.

Os passos realizados pelo plugin na autenticação de um usuários são:

• O usuário digita o endereço do fornecedor OpenID de sua escolha;
• O Noosfero tenta descobrir informações a respeito do provedor, solicitando informações do emissor de identidades;
• Caso a resposta do provedor seja válida, o Noosfero solicita o registro como um novo cliente, solicitando acesso a informações necessárias para a criação de um perfil externo;
• A requisição é redirecionada ao fornecedor OpenID, onde o usuário deve se autenticar, e revisar a solicitação enviada pelo Noosfero;
• Se o usuário se autenticar no seu provedor e aprovar as informações solicitadas, a resposta do servidor será usada na criação de um perfil externo, e o usuário será autenticado no Noosfero.