Neste artigo, mostrarei como mudamos da autorização do NTLM para o Kerberos para aplicativos no Oracle Weblogic Server, simplificando assim o login do usuário, removendo a necessidade de digitar uma senha. Todos os usuários, bem como o servidor de aplicativos, estão no mesmo domínio; a autorização de domínio para aplicativos do servidor Weblogic também foi configurada anteriormente. Todas as configurações foram verificadas no WLS 12.1.2.
Primeiro, um pouco de teoria, muito brevemente para uma melhor compreensão do processo de interação.
O que é Logon Único?
O Logon único (SSO) é um mecanismo através do qual uma ação de autenticação de usuário único permite que um usuário acesse todos os computadores e sistemas onde ele tem permissão para acessar sem precisar digitar várias senhas. As credenciais inseridas anteriormente serão reutilizadas de forma transparente por vários componentes.
O que é o Kerberos?
O Kerberos é um protocolo de autenticação de rede que foi desenvolvido pela primeira vez pelo Massachusetts Institute of Technology. O Kerberos é um método seguro de autenticar uma solicitação de serviço na rede e foi projetado para fornecer autenticação forte para aplicativos cliente-servidor usando criptografia com uma chave secreta.
O que é SPNEGO?
O SPNEGO é um mecanismo de negociação GSSAPI simples e seguro. Essa é uma interface padronizada para autenticação (por exemplo, JNDI para pesquisas de diretório), a implementação padrão do SPNEGO no Windows é Kerberos (por exemplo, LDAP para JNDI). A terminologia da Microsoft usa "Autenticação Integrada do Windows" como sinônimo de SPNEGO. Na autenticação integrada do Windows, os protocolos Kerberos ou NTLM podem ser negociados.
Quando um servidor recebe uma solicitação do Internet Explorer (IE 6.1 ou superior), pode solicitar que o navegador use o protocolo SPNEGO para autenticação. Esse protocolo executa a autenticação Kerberos por HTTP e permite ao Internet Explorer delegar autoridade delegada para que o aplicativo Web possa efetuar logon nos serviços Kerberizados subsequentes em nome do usuário.
Quando o servidor HTTP deseja executar o SPNEGO, ele retorna uma resposta "401 Não Autorizada" à solicitação HTTP com o título "Autorização da WWW: Negociar". O Internet Explorer entra em contato com o TGS (Ticket Service) para obter um ticket. Ele escolhe o nome especial do participante do serviço para solicitar um ticket, por exemplo:
HTTP/webserver@<DOMAIN NAME>
O ticket retornado é agrupado em um token SPNEGO, que é codificado e enviado de volta ao servidor usando uma solicitação HTTP. O token se desdobra e o ticket é autenticado.
Benefícios do Kerberos
O uso do Kerberos permite que os administradores desabilitem a autenticação NTLM assim que todos os clientes da rede puderem autenticar o Kerberos. O Kerberos é mais flexível e eficiente que o NTLM e mais seguro.
Configurar o SSO baseado em Kerberos em um ambiente de servidor de aplicativos Weblogic
Esquema de interação:
- Quando um usuário registrado (PC) solicita um recurso do Oracle WebLogic Server (WLS), ele envia a solicitação HTTP GET original.
- O servidor Oracle WebLogic Server (WLS) que executa o código do token SPNEGO requer autenticação e emite uma resposta 401 Access Denied, WWWAuthenticate: Negotiate.
- Um cliente (Navegador no PC) solicita um tíquete de sessão do TGS / KDC (AD).
- O TGS / KDC (AD) fornece ao cliente o ticket Kerberos necessário (desde que o cliente esteja autorizado), agrupado no token SPNEGO.
- O cliente reenvia a solicitação HTTP GET + Negociar token SPNEGO no cabeçalho da autorização: Negociar base64 (token).
- A verificação da autenticação da Web SPNEGO no servidor Weblogic vê um cabeçalho HTTP com o token SPNEGO. O SPNEGO verifica o token SPNEGO e obtém informações do usuário.
- Depois que o Weblogic recebe informações do usuário, ele valida o usuário no Microsoft Active Directory / KDC. Quando o processo de autenticação é concluído, o Weblogic executa o código Java correspondente (servlets, JSP, EJB etc.) e verifica a autorização.
- O código do manipulador de manipulador de token do Oracle WebLogic Server aceita e processa o token por meio da API GSS, autentica o usuário e responde com a URL solicitada.
Agora vamos praticar
1. Realizamos configurações no lado do servidor do domínio do controlador no qual os serviços TGS / KDC estão configurados.
- Crie um usuário no Active Directory (a senha não deve expirar)
- Defina o SPN apropriado para o nome do servidor WLS
Realize a verificação estabelecida pelo SPN
setspn –l HTTP_weblogic
deve retornar dois registros
Gerar arquivo Keytab
ktpass -princ HTTP_weblogic@mycompany.com -pass PASSWORD -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -kvno 0 -out c:\krb5.keytab
Copie este arquivo para o servidor WLS
2. Configuração do servidor WLS
- Você precisa criar o arquivo krb5.ini na pasta% windir%: C: \ Windows. Este arquivo contém definições de configuração para clientes, por exemplo, onde o KDC está localizado. O arquivo ficará assim:
[libdefaults] default_realm = <DOMAIN NAME> ticket_lifetime = 600 [realms] <DOMAIN NAME> = { kdc = <HOSTNAME OF AD/KDC> admin_server = <HOSTNAME OF AD/KDC> default_domain = <DOMAIN NAME> } [domain_realm] . <DOMAIN NAME>= <DOMAIN NAME> [appdefaults] autologin = true forward = true forwardable = true encrypt = true
- Crie o arquivo de configuração krb5Login.conf:
com.sun.security.jgss.krb5.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="user@MYCOMPANY.COM" useKeyTab=true keyTab=krb5.keytab storeKey=true debug=true; }; com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required principal="user@MYCOMPANY.COM" useKeyTab=true keyTab=krb5.keytab storeKey=true debug=true; };
Observe que o nome do domínio deve estar em
maiúsculas . Para versões anteriores, use com.sun.security.jgss.initiate na configuração anterior em vez de com.sun.security.jgss.krb5.initiate.
- Os arquivos krb5Login.conf e krb5.keytab devem estar localizados na raiz do diretório de domínio do servidor WLS.
- Editando o arquivo setDomainEnv
Encontre o conjunto de linhas JAVA_OPTIONS =% JAVA_OPTIONS% e adicione no final
-Djava.security.auth.login.config=< >\krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true
- Nesse caso, não estamos pensando em configurar a autorização WLS no AD, acreditamos que funcione, se você precisar pintar esse item, escreva nos comentários.
- Configurando o SPNEGO no WLS
Para fazer isso, acesse o Console de administração do WebLogic Server
Vá para a seção Security Realms> myrealm> Providers e clique no botão Add
Selecione o tipo de "provedor WebLogic Negotiate Identity Assertion"
Verifique se os dois parâmetros estão selecionados.
Pressionamos o botão Reordenar e controlamos as setas para definir a sequência dos tipos de autorização. Em primeiro lugar, deve ser instalado o provedor WebLogic Negotiate Identity Assertion em segundo lugar. O provedor que executa autenticação LDAP (autorização de domínio)
- Em seguida, você precisa informar ao aplicativo o método de autorização CLIENT-CERT, essas alterações são aplicadas no arquivo web.xml do aplicativo
<security-constraint> <display-name>Security Constraint for SSO </display-name> <web-resource-collection> <web-resource-name>My webapp</web-resource-name> <description>Group of Users</description> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> <security-role> <description>Role description</description> <role-name>valid-users</role-name> </security-role>
A função deve ser pré-instalada no sistema. No nosso caso, a função interna do ADF (usuários válidos) é usada e, posteriormente, com base em grupos de domínio, as permissões são concedidas.
Para identificar problemas com a autorização, você deve habilitar a depuração. Para fazer isso, vá para a seção
Ambiente -> Servidores, selecione nosso servidor -> Depurar -> weblogic (expanda) -> Segurança -> atn, marque a caixa e ative-a.
Para habilitar e desabilitar a depuração, não é necessário reiniciar.
Faça login na máquina do domínio, clique no link do aplicativo e faça o login sem inserir uma senha. Vale ressaltar que o botão Sair no aplicativo não funcionará nesta configuração.