13.8. Configuração do Kerberos ou Microsoft Active Directory Desktop SSO para os Aplicativos da Web

Introdução

Para autenticar os seus aplicativos EJB ou da web usando sua infraestrutura da autorização e autenticação baseado no Kerberos existente de sua organização, tal como o Microsoft Active Directory, você pode usar as capacidades do JBoss Negotiation construídas no JBoss Enterprise Application Plataform 6. Caso você configure o seu aplicativo da web de maneira apropriada, um login de network ou desktop é suficiente para autenticar o seu aplicativo da web, de forma que nenhuma solicitação de login adicional é requerida.

Diferença de Versões Anteriores da Plataforma

Existem poucas diferenças notáveis entre o JBoss Enterprise Application Plataform 6 e as versões anteriores:

  • Os security domains são configurados centralmente, para cada perfil de um managed domain ou de cada servidor autônomo. Eles não fazem parte da implantação. O security domain que uma implantação deve usar está nomeado no arquivo jboss-web.xml ou jboss-ejb3.xml.
  • As propriedades de segurança são configuradas como parte do security domain, como parte de sua configuração central. Elas não fazem parte da implantação.
  • Você não precisa mais substituir os autenticadores como parte de sua implantação. No entanto, você pode adicionar uma válvula ao seu descritor jboss-web.xml para atingir o mesmo efeito. A válvula continua requerendo os elementos <security-constraint> e <login-config> a serem definidos no web.xml. Eles são usados para decidir quais recursos são assegurados. No entanto, o método de autorização escolhido será substituído pela válvula do NegotiationAuthenticator no jboss-web.xml.
  • Os atributos CODE nos security domains usam agora o nome simples ao invés de um nome de classe inteiramente qualificado. As seguintes tabelas apresentam os mapeamentos entre as classes usadas para o JBoss Negotiation e suas classes.

Tabela 13.2. Códigos do Módulo de Login e Nomes de Classe

Nome Simples Nome da Classe Propósito
Kerberos com.sun.security.auth.module.Krb5LoginModule Módulo de login Kerberos
SPNEGO org.jboss.security.negotiation.spnego.SPNEGOLoginModule Os mecanismos que habilitam seus aplicativos da Web para autenticar o seu servidor de autenticação Kerberos.
AdvancedLdap org.jboss.security.negotiation.AdvancedLdapLoginModule Usado para os servidores LDAP além do Microsoft Active Directory.
AdvancedAdLdap org.jboss.security.negotiation.AdvancedADLoginModule Usado com os servidores Microsoft Active Directory LDAP.
Jboss Negotiation Toolkit

O JBoss Negotiation Toolkit é uma ferramenta de depuração que está disponível para download a partir do https://community.jboss.org/servlet/JiveServlet/download/16876-2-34629/jboss-negotiation-toolkit.war. Isto é fornecido como uma ferramenta extra para ajudá-lo a depurar e testar os mecanismos de autenticação antes da introdução de seu aplicativo à produção. Isto é uma ferramenta não suportada, porém é considerada de muita ajuda, uma vez que o SPNEGO pode ser difícil de ser configurado para os aplicativos da web.

Procedimento 13.1. Configuração da Autenticação SSO para os seus Aplicativos EJB

  1. Configure um security domain para representar a identidade do servidor. Determine as propriedades caso seja necessário.

    O primeiro security domain autentica o próprio contêiner ao serviço do diretório. Ele precisa usar um módulo de login que aceita algum tipo de mecanismo de login estático, uma vez que o usuário real não está envolvido. Esta amostra usa um principal estático e referencia um arquivo keytab que contém o credencial.
    O código XML é gerado aqui para clareza, porém você deve usar o Management Consolo ou Management CLI para configuração de seus security domains.
    <security-domain name="host" cache-type="default">
       <authentication>
          <login-module code="Kerberos" flag="required">
             <module-option name="storeKey" value="true"/>
             <module-option name="useKeyTab" value="true"/>
             <module-option name="principal" value="host/testserver@MY_REALM"/>
             <module-option name="keyTab" value="/home/username/service.keytab"/>
             <module-option name="doNotPrompt" value="true"/>
             <module-option name="debug" value="false"/>
          </login-module>
       </authentication>
    </security-domain>		
    		
    
    
  2. Configure o segundo security domain para assegurar o aplicativo da web ou aplicativos. Determine as propriedades do sistema caso seja necessário.

    O segundo security domain é usado para autenticar o usuário individual ao Kerberos ou servidor de autenticação SPNEGO. Você precisa de pelo menos um módulo de login para autenticação do usuário e outro para buscar as funções a serem aplicadas ao usuário. O seguinte código XML apresenta um modelo de autorização para mapeamento das funções no próprio servidor de autenticação.
    <security-domain name="SPNEGO" cache-type="default">
       <authentication>
          <!-- Check the username and password -->
          <login-module code="SPNEGO"  flag="requisite">
             <module-option name="password-stacking" value="useFirstPass"/>
             <module-option name="serverSecurityDomain" value="host"/>
          </login-module>
          <!-- Search for roles -->
          <login-module code="UserRoles" flag="required">
             <module-option name="password-stacking" value="useFirstPass" />
             <module-option name="usersProperties" value="spnego-users.properties" />
             <module-option name="rolesProperties" value="spnego-roles.properties" />
          </login-module> 
       </authentication>
    </security-domain>		
    		
    
    
  3. Especifique o security-constraint e login-config no web.xml

    O descritor web.xml contém informação sobre as restrições de segurança e configuração de login. Segue abaixo algumas amostras de valores para cada uma.
    <security-constraint>
       <display-name>Security Constraint on Conversation</display-name>
       <web-resource-collection>
          <web-resource-name>examplesWebApp</web-resource-name>
          <url-pattern>/*</url-pattern>
       </web-resource-collection>
       <auth-constraint>
       <role-name>RequiredRole</role-name>
       </auth-constraint>
    </security-constraint>
    
    <login-config>
       <auth-method>SPNEGO</auth-method>
       <realm-name>SPNEGO</realm-name>
    </login-config>
     
    <security-role>
       <description> role required to log in to the Application</description>
       <role-name>RequiredRole</role-name>
    </security-role>		
    		
    
    
  4. Especifique o security domain e outras configurações no descritor jboss-web.xml.

    Especifique o nome do security domain ao lado do cliente (a segunda amostra) no descritor jboss-web.xml de sua implantação para direcionar o seu aplicativo para uso de seu security domain.
    Você não pode mais substituir os autenticadores diretamente. Ao invés disto, você pode adicionar o NegotiationAuthenticator como um valor ao seu descritor jboss-web.xml, caso seja necessário. O <jacc-star-role-allow> permite você usar o caractere (*) de asterisco para coincidir com os nomes de função múltiplos e é opcional.
    <jboss-web>
       <security-domain>java:/jaas/SPNEGO</security-domain>
       <valve>
          <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
       </valve>
       <jacc-star-role-allow>true</jacc-star-role-allow>
    </jboss-web>		
    		
    
    
  5. Adicione uma dependência ao seu MANIFEST.MF do aplicativo para localizar as classes de Negociação.

    O aplicativo da web precisa de uma dependência no org.jboss.security.negotiation da classe a ser adicionada ao manifesto do META-INF/MANIFEST.MF da implantação, com o objetivo de localizar as classes do JBoss Negotiation. Segue abaixo uma entrada propriamente formatada.
    Manifest-Version: 1.0
    Build-Jdk: 1.6.0_24
    Dependencies: org.jboss.security.negotiation
    
Resultado

O seu aplicativo da web aceita e autentica os credenciais em relação ao Kerberos, Microsoft Directory ou outro serviço do diretório compatível com o SPNEGO. Caso o usuário executar o aplicativo a partir de um sistema que já está conectado ao serviço do diretório, e onde as funções solicitadas já são aplicadas ao usuário, o aplicativo da web não solicita a autenticação e as capacidade SSO são atingidas.