Shibboleth para TYPO3

Universidades e instituições de pesquisa precisam de SSO com Shibboleth direto no TYPO3

No setor acadêmico, o Shibboleth é o padrão de fato para Single Sign-On. Mais de 3.000 instituições no mundo estão organizadas em federações Shibboleth: na Alemanha, na federação DFN-AAI, com mais de 700 organizações participantes; no Brasil, na CAFe, operada pela RNP. A extensão shibboleth para TYPO3 integra o Service Provider diretamente ao CMS. Estudantes, professores e servidores fazem login com a credencial institucional e ganham acesso às áreas protegidas do frontend e, quando necessário, ao backend do TYPO3. A extensão é irmã da shibboleth_auth e oferece a integração básica com o Shibboleth SP, que precisa estar instalado no servidor web.

Ao contrário da extensão saml2, que usa o SimpleSAMLphp como SP em PHP, a extensão shibboleth se apoia no Shibboleth Service Provider nativo (escrito em C++), que roda como módulo do Apache ou como módulo nativo do IIS. É a arquitetura mais robusta para ambientes de alta disponibilidade.

Os cenários típicos envolvem federações acadêmicas, sistemas de bibliotecas e portais de pesquisa

O cenário principal é a integração com a federação acadêmica nacional: a DFN-AAI, nas universidades alemãs, ou a CAFe, nas brasileiras. Uma universidade opera seu portal web em TYPO3. Os estudantes clicam em “Login”, são redirecionados ao IdP da universidade, se autenticam e voltam à página TYPO3 com uma sessão ativa. A extensão lê os atributos Shibboleth nas variáveis de ambiente do servidor (REMOTE_USER, eppn, mail, affiliation) e cria ou atualiza o usuário de frontend no TYPO3.

Um segundo cenário é o acesso a bibliotecas. As bibliotecas universitárias oferecem bases de dados online, periódicos eletrônicos e documentos de pesquisa pelo site TYPO3, com acesso restrito à comunidade acadêmica. É o mesmo modelo que pesquisadores brasileiros conhecem do acesso remoto ao Portal de Periódicos da CAPES via CAFe. A extensão shibboleth verifica o atributo “eduPersonEntitlement” e só libera o conteúdo licenciado para usuários com o valor “urn:mace:dir:entitlement:common-lib-terms”.

Terceiro cenário: portais de pesquisa federados. Um consórcio de pesquisa com parceiros de cinco universidades opera um portal comum em TYPO3. Cada parceiro tem o seu próprio IdP. Pela federação acadêmica (DFN-AAI na Alemanha, CAFe no Brasil) ou, entre países, pela interfederação eduGAIN, todos os pesquisadores e colaboradores dos parceiros conseguem fazer login sem que o portal precise administrar contas próprias. A extensão atribui cada usuário ao grupo do parceiro correto com base no atributo “schacHomeOrganization”.

A arquitetura técnica pressupõe um Shibboleth SP instalado no servidor web

A extensão em si não contém uma pilha SAML. Ela lê os atributos que o Shibboleth SP disponibiliza, depois da autenticação bem-sucedida, como variáveis de ambiente do servidor ou cabeçalhos HTTP. O SP precisa estar configurado como módulo do Apache (mod_shib) ou como FastCGI Authorizer. Em setups com nginx, é necessário um Shibboleth SP como backend FastCGI ou um proxy baseado em Lua.

A extensão TYPO3 registra um Authentication Service que, a cada login no frontend ou no backend, verifica se há atributos Shibboleth. Se houver, eles são mapeados para campos do usuário TYPO3: REMOTE_USER para username, mail para email, givenName e sn para first_name e last_name. A atribuição de grupos usa o atributo “eduPersonAffiliation”: student, faculty, staff e employee são mapeados para grupos de frontend do TYPO3.

A gestão de sessões segue o ciclo de vida do Shibboleth: quando a sessão Shibboleth expira, o usuário TYPO3 é desconectado automaticamente. O Single Logout (SLO) é feito pelo Shibboleth SP; a extensão TYPO3 reage ao evento de logout e encerra a sessão TYPO3.

Os problemas frequentes envolvem a configuração do Apache e atributos ausentes

O maior problema é a configuração correta do Apache. O Shibboleth SP precisa saber quais URLs deve proteger. Uma diretiva Location errada faz com que o SP proteja todas as páginas (inclusive as públicas) ou nenhuma. A configuração padrão protege /Shibboleth.sso/* para o próprio SP e /typo3/ para o backend. As áreas do frontend são protegidas por Lazy Session: o SP disponibiliza os atributos quando existe uma sessão Shibboleth, mas não força a autenticação. A extensão verifica então, no frontend do TYPO3, se há atributos e mostra o conteúdo protegido apenas a usuários autenticados.

Segundo problema: atributos ausentes ou vazios. Nem todo IdP entrega todos os atributos. Se o IdP não libera o atributo “mail”, a extensão não consegue gravar um endereço de e-mail no usuário TYPO3. A solução: combinar com quem opera o IdP (normalmente o centro de TI da universidade) quais atributos são liberados para o SP e configurar o mapeamento de atributos da extensão de acordo.

Terceiro tema: deploys em containers. Instalações TYPO3 baseadas em Docker muitas vezes não têm um Apache com mod_shib. A alternativa é um Shibboleth SP como reverse proxy à frente do container TYPO3, repassando os atributos como cabeçalhos HTTP. A extensão precisa então ser configurada para ler os atributos nos cabeçalhos, e não em variáveis de ambiente. Importante: os cabeçalhos precisam ser protegidos contra spoofing, com o reverse proxy removendo qualquer cabeçalho de entrada que use nomes de atributos Shibboleth.

A extensão shibboleth para no TYPO3 8.7

A extensão shibboleth usa a TYPO3 Authentication Service API. A última versão, 3.1.7, saiu em outubro de 2018 e suporta do TYPO3 7.6 ao 8.7; para versões mais novas do TYPO3 não há release, nem no repositório do autor no GitHub. Universidades que planejam upgrades do TYPO3 devem incluir a integração SSO como bloco de testes próprio no planejamento. A Gosign recomenda avaliar a extensão oidc em paralelo à shibboleth, porque muitos IdPs hoje suportam tanto SAML quanto OIDC, e o OIDC permite uma arquitetura mais simples, sem Shibboleth SP no servidor.