Autorización transparente para una aplicación en Oracle Weblogic Server

En este artículo, le contaré cómo cambiamos de NTLM a la autorización Kerberos para aplicaciones en Oracle Weblogic Server, lo que simplifica el inicio de sesión del usuario al eliminar la necesidad de ingresar una contraseña. Todos los usuarios, así como el servidor de aplicaciones, están en el mismo dominio; la autorización de dominio para las aplicaciones del servidor Weblogic también se configuró previamente. Todas las configuraciones se verificaron en WLS 12.1.2.

Primero, una pequeña teoría, muy brevemente para una mayor comprensión del proceso de interacción.

¿Qué es el inicio de sesión único?

Single Sign-On (SSO) es un mecanismo a través del cual una acción de autenticación de un solo usuario le permite al usuario acceder a todas las computadoras y sistemas donde tiene permiso de acceso sin tener que ingresar varias contraseñas. Las credenciales ingresadas previamente serán reutilizadas de forma transparente por varios componentes.

¿Qué es Kerberos?

Kerberos es un protocolo de autenticación de red que fue desarrollado por el Instituto de Tecnología de Massachusetts. Kerberos es un método seguro para autenticar una solicitud de un servicio en la red y está diseñado para proporcionar una autenticación sólida para aplicaciones cliente-servidor utilizando criptografía con una clave secreta.

¿Qué es SPNEGO?

SPNEGO es un motor de negociación GSSAPI simple y seguro. Esta es una interfaz estandarizada para la autenticación (por ejemplo, JNDI para búsquedas de directorio), la implementación predeterminada para SPNEGO en Windows es Kerberos (por ejemplo, LDAP para JNDI). La terminología de Microsoft utiliza "Autenticación de Windows integrada" como sinónimo de SPNEGO. En la autenticación integrada de Windows, se pueden negociar los protocolos Kerberos o NTLM.

Cuando un servidor recibe una solicitud de Internet Explorer (IE 6.1 o superior), puede solicitar que el navegador utilice el protocolo SPNEGO para la autenticación. Este protocolo realiza la autenticación Kerberos a través de HTTP y permite a Internet Explorer delegar la autoridad delegada para que la aplicación web pueda iniciar sesión en los servicios Kerberizados posteriores en nombre del usuario.

Cuando el servidor HTTP quiere ejecutar SPNEGO, devuelve una respuesta "401 no autorizada" a la solicitud HTTP con el título "Autorización WWW: Negociar". Internet Explorer se pone en contacto con el Servicio de tickets (TGS) para obtener un ticket. Elige el nombre especial del participante del servicio para solicitar un boleto, por ejemplo:

HTTP/webserver@<DOMAIN NAME> 

El ticket devuelto se envuelve en un token SPNEGO, que se codifica y se envía de vuelta al servidor mediante una solicitud HTTP. El token se despliega y el boleto se autentica.

Beneficios de Kerberos

El uso de Kerberos permite a los administradores deshabilitar la autenticación NTLM en cuanto todos los clientes de la red puedan autenticar Kerberos. Kerberos es más flexible y eficiente que NTLM y más seguro.

Configurar SSO basado en Kerberos en un entorno de servidor de aplicaciones Weblogic

Esquema de interacción:

1. Cuando un usuario registrado (PC) solicita un recurso de Oracle WebLogic Server (WLS), envía la solicitud HTTP GET original.
2. El servidor de Oracle WebLogic Server (WLS) que ejecuta el código de token SPNEGO requiere autenticación y emite un acceso 401 denegado, WWWAuthenticate: negociar respuesta.
3. Un cliente (navegador en la PC) solicita un ticket de sesión de TGS / KDC (AD).
4. TGS / KDC (AD) proporciona al cliente el ticket Kerberos necesario (siempre que el cliente esté autorizado), envuelto en el token SPNEGO.
5. El cliente reenvía la solicitud HTTP GET + Negociar token SPNEGO en el encabezado de autorización: Negociar base64 (token).
6. Al verificar la autenticación web SPNEGO en el servidor Weblogic, se ve un encabezado HTTP con el token SPNEGO. SPNEGO comprueba el token SPNEGO y obtiene información del usuario.
7. Después de que Weblogic recibe la información del usuario, valida al usuario en Microsoft Active Directory / KDC. Cuando se completa el proceso de autenticación, Weblogic ejecuta el código Java correspondiente (servlets, JSP, EJB, etc.) y verifica la autorización.
8. El código del manejador del token del servidor Oracle WebLogic acepta y procesa el token a través de la API GSS, autentica al usuario y responde con la URL solicitada.

Ahora vamos a practicar

1. Realizamos ajustes en el lado del servidor del dominio del controlador en el que están configurados los servicios TGS / KDC.

• Crear un usuario en Active Directory (la contraseña no debe caducar)
• Establezca el SPN apropiado para el nombre del servidor WLS

Realizar la verificación establecida por SPN

 setspn –l HTTP_weblogic 

debería devolver dos registros
Generar archivo de tabla de claves

 ktpass -princ HTTP_weblogic@mycompany.com -pass PASSWORD -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -kvno 0 -out c:\krb5.keytab 

Copie este archivo al servidor WLS

2. Configuración del servidor WLS

• Debe crear el archivo krb5.ini en la carpeta% windir%: C: \ Windows. Este archivo contiene ajustes de configuración para clientes, por ejemplo, donde se encuentra el KDC. El archivo se verá así:

 [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 

• Cree el archivo de configuración 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; }; 

Tenga en cuenta que el nombre de dominio debe estar en mayúscula . Para versiones anteriores, use com.sun.security.jgss.initiate en la configuración anterior en lugar de com.sun.security.jgss.krb5.initiate.

• Los archivos krb5Login.conf y krb5.keytab deben ubicarse en la raíz del directorio del dominio del servidor WLS.

• Edición del archivo setDomainEnv

Encuentre el conjunto de líneas JAVA_OPTIONS =% JAVA_OPTIONS% y agregue al final

 -Djava.security.auth.login.config=<  >\krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true 

• En este caso, no estamos considerando configurar la autorización WLS en AD, creemos que funciona, si necesita pintar este artículo, escriba los comentarios.
• Configurando SPNEGO en WLS
  Para hacer esto, vaya a la Consola de administración del servidor WebLogic
  Vaya a la sección Reinos de seguridad> myrealm> Proveedores y haga clic en el botón Agregar
  Seleccione el tipo de "Proveedor de Afirmación de Identidad de Negociación de WebLogic"
  Verifique que ambos parámetros estén seleccionados.
  
  
  
  Presionamos el botón Reordenar y al controlar las flechas establecemos la secuencia de los tipos de autorización. En primer lugar, debe instalarse el proveedor WebLogic Negotiate Identity Assertion en segundo lugar Proveedor que realiza la autenticación LDAP (autorización de dominio)
  
  

• Reiniciar el servidor

• A continuación, debe indicar a la aplicación el método de autorización CLIENTE-CERT; estos cambios se aplican en el archivo web.xml de la aplicación

 <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> 

El rol debe estar preinstalado en el sistema. En nuestro caso, se utiliza el rol incorporado para ADF (usuarios válidos) y, más adelante, según los grupos de dominio, se otorgan permisos.

• Depurar

Para identificar problemas con la autorización, debe habilitar la depuración. Para hacer esto, vaya a la sección.

Entorno -> Servidores, seleccione nuestro servidor -> Depurar -> weblogic (expandir) -> Seguridad -> atn, marque la casilla y actívelo.



Para habilitar y deshabilitar la depuración, no es necesario reiniciar.

• Reiniciamos el servidor para aplicar cambios de configuración.
• Implemente la aplicación con un método de autorización modificado (nuevo web.xml)
• Para deshabilitar este tipo de autorización para la consola administrativa, realice los siguientes cambios% Ora_Home% \ wlserver \ server \ lib \ consoleapp \ webapp \ WEB-INF \ web.xml.
  
  Cambiar la linea
  
  

    <auth-method>CLIENT-CERT,FORM</auth-method>  <auth-method>FORM</auth-method> 

Inicie sesión en la máquina de dominio, haga clic en el enlace de la aplicación e inicie sesión sin ingresar una contraseña. Vale la pena señalar que el botón Salir de la aplicación no funcionará en esta configuración.