SSO corporativo da Intranet para webapps no Active Directory

Question

Estou tentando planejar e implementar uma solução de SSO em um ambiente corporativo que serve aplicativos da Web de intranet executados no CentOS:

• Portal corporativo (backend do Drupal)
• Gerenciamento de projetos (Project.NET)
• Sistema de colaboração de documentos (Alfresco)
• Helpdesk (Redmine)
• Acompanhamento de problemas (Atlassian Jira)

A autenticação é implementada com sucesso no Active Directory por meio do LDAP, pois há suporte para esses aplicativos fora da caixa ou por um plug-in.

Dado que não há nenhum plug-in ou módulo SSO nativo estável para todos os aplicativos da Web acima, eu me apóio em uma implantação do Shibboleth como um provedor de identidade e uma solução de SSO. Como eu não tenho certeza se isso é adequado para a situação dada eu quero perguntar o seguinte:

• O Shibboleth é adequado para agir como um intermediário para fornecer um login de SSO neste esquema:

Active Directory < = Credenciais de domínio < = Shibboleth = > Identidade = > Login de aplicativo

• Tanto quanto eu sei, a autenticação fornecida pelo Shibboleth para o aplicativo é realmente conseguida através da configuração do servidor web (Apache, Tomcat etc.). Esse tipo de autenticação fornece apenas a permissão para visualizar apenas o conteúdo de uma determinada página ou pode se integrar totalmente à autenticação do aplicativo (como funciona a autenticação LDAP)?
• Se o login de identidade acima estiver funcionando, os recursos do aplicativo para um usuário autenticado ainda funcionarão como se o usuário estivesse normalmente logado com suas credenciais de domínio? (por exemplo, o Redmine suporta a criação de conta on-the-fly para um login de usuário de domínio pela primeira vez bem-sucedido).

Answer 1

Um Provedor de Identidade (IdP) manipula a autenticação em um banco de dados ou servidor LDAP e passa as informações do usuário para um aplicativo = Provedor de Serviços (SP).

Suponho que você queira usar a implementação do Provedor de Serviços fornecida pelos criadores do Shibboleth (apelidado de shibboleth-sp) conversando com um IdP do Shibboleth.

Isso funciona especificando quais recursos devem ser protegidos na configuração do servidor da web e aumentando os parâmetros passados a aplicação pelos atributos solicitados de o IdP pelo SP. Esses atributos devem ser liberados pelo IdP para o SP solicitante (attribute-filter.xml) e deve significar algo para o aplicativo. O IdP não faz controle de acesso, o aplicativo deve decidir como ele interpreta os parâmetros recebido do IdP.

Então, você tem um aplicativo que pode conversar diretamente com um IdP (via SAML2, por exemplo, Liferay EE) ou você usa o shibboleth-sp e usa os atributos para mapear um usuário para o modelo de papéis do aplicativo.

Um caso básico seria semelhante ao uso da Autenticação HTTP, desativando a autenticação no aplicativo e usando o parâmetro REMOTE_USER para identificar o usuário. Outros dados podem ser recuperados pelo aplicativo em seus armazenamentos de dados.

Visão geral: link