Protección del servidor WebLogic 12c

Capítulo 1. Conceptos de
seguridad de WebLogic

Seguridades una cuestión compleja, y Java EE no es una excepción a esta

regla. Para complicar aún más las cosas, WebLogic amplía la seguridad
estándar con algunas características importantes y útiles que se analizarán en
este capítulo; son los siguientes:

 Asertividad de identidad

 Credential Mappers

 Interfaz de proveedor de servicios de autenticación Java para

contenedores ( JASPIC ) y Servicio de autenticación y autorización de

Java ( JAAS )

Concepto general de seguridad

en Java EE

Estándar de Java la seguridad se implementa con el administrador de seguridad

y los archivos de políticas, y Java Enterprise Edition la amplía de manera
completamente transparente para el desarrollador; como cualquier otro servicio
ofrecido por la plataforma.

Si es un desarrollador de Enterprise Bean, puede desarrollar sabiendo que el

contenedor se encargará de la delicada tarea de proteger sus datos de la misma
forma que se encarga de la comunicación remota, desde el protocolo HTTP
hasta la llamada al método de servlet y la gestión de transacciones. Obviamente,
es imposible que el contenedor tenga conocimiento de la infraestructura en la
que se implementará, por lo que hay muchas formas estándar de ampliarlo para
que funcione con un nuevo RDBMS: instalar elArchivos JAR del controlador
de conectividad de bases de datos Java ( JDBC ) o un nuevo recurso
transaccional que implementa el contrato del adaptador de recursos.

Este principio también se aplica a la seguridad; pero hasta Java EE 6 no existían

métodos estándar para implementar un nuevo Proveedor de autenticación, o lo
que sea inherente a la seguridad. Como veremos, esta nueva versión hace que
sea obligatorio que los contenedores implementen JASPIC 1.0, pero muchos de
ellos lo implementan en paralelo y WebLogic 12c no es una excepción. Si
necesita implementar algo que no sea "simple", se requieren Proveedores
personalizados con API personalizada.

En Java EE, el desarrollador interactúa con el contenedor utilizando anotaciones

declarativas o descriptores XML. Cuando necesite proteger una URL
administrada por un servlet, todo lo que necesita hacer es anotar ese servlet con
la @ServletSecurityanotaciónjunto con una lista de roles permitidos, como se
muestra en el siguiente fragmento de código:

Dupdo

@WebServlet("/mysecuredurl")
@ServletSecurity(@HttpConstraint(rolesAllowed={"myrole"}))
public class MySecuredServlet extends HttpServlet {
...
}

Esta única línea de meta-código abre el mundo mágico de la seguridad Java EE,
como se explica en los siguientes puntos:
  Si el usuario es no autenticado, el contenedor web le pedirá sus credenciales; cómo

se le preguntará al usuario depende de la configuración de la aplicación web y del

tipo de cliente que esté utilizando.

 El agente de usuario acepta las credenciales y envía esa información al servidor. El

servidor intenta validarlos utilizando un proveedor de autenticación. Si esto tiene

éxito, se creará un contenedor adecuado para los principales del usuario (un Sujeto),

que se correlacionará con el agente de autenticación mediante una especie de

cookie de sesión.

 Una vez conocidos los principales del usuario, se asignan a los roles de la aplicación

que se declaran en los descriptores de implementación personalizados de su

servidor de aplicaciones.

 Si el servlet necesita recursos adicionales o necesita realizar una llamada a un

método EJB, el contexto de seguridad se "propagará" (consulte las especificaciones

de Java EE 6, v.3.2, en http://www.oracle.com/technetwork/java).

/javaee/tech/index.html ).

Cada uno de los pasos descritos aquí implica una serie de tareas muy
complejas, y todas ellas son gratuitas para el desarrollador de Java EE; están
hechos detrás de la cortina por el contenedor.

Arquitectura de seguridad de WebLogic

Arquitectura de seguridad de WebLogic se basa en un conjunto de clases en

el weblogic.security.* paqueteen el WebLogic Security Framework ( WSF ), que se

utilizan para desarrollar proveedores de seguridad que se ejecutan bajo los auspicios del

servicio de seguridad de WebLogic.

Este tiempo de ejecución es el orquestador que permite que los componentes de la

aplicación, como los EJB y los servlets, se comuniquen con los recursos del servidor, con la

intermediación del proveedor de seguridad.

Aquí, repasaremos algunos conceptos básicos del FSM que debemos entender para

desarrollar proveedores personalizados.

Identificación: sujetos, directores y

credenciales

WebLogic sigue la arquitectura JAAS de Java SE para su infraestructura de seguridad:

temas, directores y Cartas credenciales. Estos se explican de la siguiente manera:

 Asunto : información relacionada con la entidad que solicita los recursos

asegurados, como identidades (principal) o atributos (credenciales)

 Principal : identidad asociada con la entidad autenticada, como su nombre

completo, el nombre de usuario, un protocolo ligero de acceso a

directorios ( LDAP ) grupo, y todo lo que lo identifica

 Credenciales : Atributos relacionados con la entidad que se autentica; pueden estar

relacionados con la seguridad, como Entrada de

Kerberos (sun.security.krb5.Credentials ) o no relacionada con la seguridad,

como los atributos que utiliza la aplicación

En JAAS, cuando el login()método se llama en la corriente LoginContext clase, un

nuevo Subjectobjetoes creado y configurado LoginModule se llama en secuencia para

enriquecer ese objeto con principios.

Entonces, por ejemplo, es posible configurar una LoginModuleinterfaz que agregue

credenciales Kerberos, otra LoginModule, como la de

WebLogic UsernamePasswordLoginModule , que se agrega PasswordCredential . Estos

son utilizados por WebLogic para acceder a los recursos restringidos.

Recursos de WebLogic
Java EE 6 define la seguridad de componentes como un EJB o una conexión a

un Enterprise Information System ( EIS ); Los recursos de WebLogic extienden este nivel

de seguridad. La siguiente es una cita que define los recursos de la documentación oficial de

WebLogic 12c:

Un objeto estructurado utilizado para representar una entidad de servidor

WebLogic subyacente que puede protegerse del acceso no autorizado.
Esto significa que un DataSourceobjeto no se puede acceder directamente sino solo a

través de un JDBCResourceobjeto, y cada recurso también se representa como una

jerarquía; si no se especifica la seguridad para la hoja, se puede inspeccionar su padre

único hasta que se encuentre una configuración adecuada.

Supongamos, para Por ejemplo, el contenedor está verificando si el usuario puede acceder

a un determinado método de un EJB, cuya representación de recursos es la siguiente:

Dupdo

type=<ejb>, app=SecuredApp, module=EJBModule, ejb=VeryImportantEJB,

method=callItSecure, methodInterface=Home, methodParams={String, int}

Si la EJBResourceclaseno puede encontrar una política adecuada para ese método, le

preguntará a su empresa matriz, Enterprise Bean, que puede verificar si el usuario está

autorizado o no.

Escribir proveedores personalizados - MBeans

Extensiones de administración de Java ( JMX ) es una parte obligatoria de la

especificación Java EE 6 que define estándares para el monitoreo y la administración de

aplicaciones empresariales de una manera dinámica y no intrusiva. Con JMX, es posible

consultar una aplicación arbitraria para obtener información de diagnóstico sin saber nada

sobre la forma en que se implementa, pero solo con una herramienta estándar como

JConsole. o VisualVM. Esto se implementa de forma estructurada, donde JMX define el

tiempo de ejecución, el caminoLos beans de administración se desarrollan y cómo acceder a

esa información. La implementación es directa; solo necesita definir lo que desea, de la

siguiente manera:

Dupdo

@MXBean
public interface MyManagedProperties {
public int getCached();
public void callOperation();
}

Y la implementación, en Java EE 6 es realmente unas pocas líneas de código, es la

siguiente:

Dupdo

@Singleton
@Startup
public class MyManagedPropertiesBean implements MyManagedProperties {
private MBeanServer platformMBeanServer;
private ObjectName objectName = null;
@PostConstruct
public void registerInJMX() {
try {
objectName = new ObjectName("MyMXBean :type=" +
this.getClass().getName());
InitialContext ctx = new InitialContext();
platformMBeanServer = (MBeanServer)
ctx.lookup("java:comp/env/jmx/runtime");
ctx.close();
platformMBeanServer.registerMBean(this, objectName);
} catch (Exception e) {
throw new IllegalStateException("Problem during registration of
Monitoring into JMX:" + e);
}
}
public int getCached() {//doSomething}
public void callOperation() {//doSomething}

@PreDestroy
public void unregisterFromJMX() {
try {
platformMBeanServer.unregisterMBean(this.objectName);
} catch (Exception e) {
throw new IllegalStateException("Problem during unregistration of
Monitoring into JMX:" + e);
}
}
}
Una MXBeaninterfazse implementa en el código anterior; es un Bean Administrado al que

puede acceder un cliente JMX, que no necesita saber nada sobre nuestra aplicación. Es el

deber del agente convertir cada clase específica de dominio a propiedades simples.

Desafortunadamente, el desarrollo MBeans para WebLogic no es tan fácil, debido a una

forma personalizada de generar los MBeans que se ejecutan en el MBeanServerinterfaz. Es

necesario escribir un archivo XML personalizado, llamado MBean Definition File ( MDF ), y

luego generar un archivo JAR que se puede instalar en el servidor WebLogic usando

WebLogic'sHerramienta MBeanMaker.

Proveedores de autenticación

Desarrollar un proveedor de autenticaciónes una tarea bastante compleja con

muchos conceptos que deben ser entendidos. Aquí, presentaremos los
conceptos relacionados con las partes que componen un proveedor y diferentes
tipos de autenticación.

Autenticación bajo WebLogic

Autenticación se delega por completo a las entidades denominadas Proveedores de

autenticación, que son un conjunto de clases y archivos de configuración que incorporan un

MBean y un LoginModule interfaz. Cada vez que solicita un recurso protegido, se solicita a

cada Proveedor configurado que agregue los principales extraídos de las credenciales

proporcionadas.

Este mecanismo es muy similar al configurable en el cliente con solo JAAS

(y jaas.config); la principal diferencia es que se hace con la consola de

administración. Esta consola nos permite configurar parámetros visualmente, a través de la

página JSP generada automáticamente, sin tocar ningún archivo XML, como se muestra en

la siguiente captura de pantalla:

MBean y JAAS

En el marco de seguridad de WebLogic, todo está envuelto por MBeans. los la

infraestructura de seguridad estándar JAAS se crea e invoca utilizando un MBean, que se

puede configurar utilizando el consola estándar. Esto tiene sentido porque la consola y todas

las utilidades que se ejecutan bajo el ecosistema WebLogic deben ser consistentes y hay

muchas tecnologías alrededor de Java que deben integrarse.

Por lo tanto, si necesita implementar su propia LoginModuleinterfaz, recuerde que debe

"decorarla" con el MBean correcto, que a su vez es generado automáticamente por

WebLogic.Herramienta MBeanMaker.

Proveedor de autenticación multiparte

Cada Proveedor tiene una sola oportunidad de contribuir al proceso de autenticación: recibe

Credenciales y, finalmente, agrega Principales al Sujeto actual. Este escenario de seguridad

tiene muy limitado potencialidades si se requiere interacción con el agente de usuario. Por

ejemplo, para negociar un mecanismo de autenticación, redirigir a un sitio de inicio de

sesión remoto, o incluso implementar un apretón de manos de desafío / respuesta, esta es

una tarea adecuada para filtros de servlet, pero si están configurados para un recurso

protegido no se invocan hasta que usted sea autenticado

WebLogic Security Framework ofrece a los desarrolladores la oportunidad de devolver una

matriz de filtros que se ejecutan en nombre del mecanismo de Autenticación estándar, pero

no en el contexto de seguridad del componente de la aplicación.

Autenticación Perimetral

Autenticación Perimetral usualmente usa Aserción de identidad y filtros de seguridad para

autenticar usuarios. Esto será elaborado más tarde.

Asertividad de identidad

Muchas organizaciones tienen sistemas heterogéneos que necesitan servicios

de seguridad, y muchos de estos sistemas interactúan con usuarios que ya han
declarado quiénes son, por ejemplo, durante la fase de inicio de sesión de su
estación de trabajo al comienzo de su jornada laboral.

Esta es la base para introducir el concepto de perímetro, donde la autenticación

se realiza una vez y luego siempre se confía durante el día. Lo mismo ocurre
cuando usa su insignia para ingresar a su empresa; se confía en que se le
permita ingresar a los edificios, con la necesidad de exponer la insignia para
expresar que usted es un empleado. En el caso de la Autenticación Perimetral,
se usa un token lanzado por un tercero para extraer quién es el usuario,
realizando unAserción de identidad y no autenticación completa.
Esto significa que cuando se desarrollan LoginModuleinterfaces para
proveedores de Aserción de identidad, las credenciales se utilizan para no
decidir si el usuario está autenticado, sino simplemente para llenar el asunto con
los principales que se pueden encontrar utilizando el token.

Credential Mapper

Antes de Java EE 6 y la introducción de la SecurityContext interfazen

la especificación de Java EE Connector Architecture ( JCA ) 1.6 (consulte
la SecurityContext interfaz en las especificaciones de JCA 1.6
en http://jcp.org/en/jsr/detail?id=322 ), no había formas estándar de asignar
el SecurityContextobjeto de seguridad actual a la ConnectionSpecinterfaz de un
adaptador de recursos.

Esto podría significar las dos cosas siguientes:

 Sin inicio de sesión único de extremo a extremo del usuario al EIS

 Codifique en los componentes de la aplicación que implementan el mapeo de

credenciales

Seguridad WebLogic Framework admite la asignación de credenciales del

usuario autenticado actual a un formato que pueda ser entendido por el
adaptador de recursos / EIS.

La implementación es muy sencilla. Antes de llamar alexecute()método sobre la

interacción en el ConnectionSpec interfaz, se le pide al Mapper que convierta las
Credenciales actuales almacenadas en el Sujeto en una o más Credenciales
válidas para el sistema remoto.

Actualmente, si BasicPasswordes el tipo de mecanismo de autenticación actual

y PasswordCredentialesla interfaz que se debe usar para la comunicación, es
suficiente para el desarrollador del proveedor de asignación de credenciales
personalizado escribir una función que mapee el espacio de seguridad local con
el de la llamada EIS.

Conceptualmente, esto no es muy diferente de lo que se hace con la aserción de

identidad y la autenticación perimetral; pero esta vez la confianza es entre
WebLogic y un sistema externo, siendo el primero responsable de la
seguridad. Por supuesto, también puede haber asignaciones que puedan realizar
una autenticación completa, pero en ambos casos, el enlace débil es el servidor
de aplicaciones Java que tiene la posibilidad de autenticar a los usuarios en un
sistema remoto.

JASPIC y Java EE

Después de tantos páginas que hablan de seguridad y cómo implementarlo en

WebLogic, la pregunta es: ¿por qué todo esto está hecho a medida y no está
regulado por Java EE?

Java EE 6tiene la respuesta correcta a esta pregunta: la especificación JASPIC

1.0, un marco de procesamiento de mensajes que es independiente del protocolo
y que puede hacer lo que un Proveedor de Autenticación hace por nosotros; es
decir, rellenar sujetos con principales y, por lo tanto, autenticar a un agente de
usuario remoto.

De una manera que es diferente de WebLogic Security Framework, donde todo

está dentro de una API segura porque el mensaje y el protocolo son
administrados por el servidor de aplicaciones, esto se hace en el nivel del
mensaje. De esta manera, se aplica el concepto de que la seguridad es algo
relacionado con el protocolo y la forma en que se intercambia la información.
De hecho, actualmente tenemos tres perfiles que forman parte de la
especificación estándar, uno que puede autenticar clientes HTTP, otro que
funciona con mensajes SOAP y un tercer perfil que intenta unir la nueva
especificación con el módulo de inicio de sesión JAAS existente en El mercado.

Este es el primero la implementación en WebLogic y su inmadurez es evidente

por la falta total de documentación y el hecho de que la configuración no está
integrada en los descriptores de implementación personalizados. Por lo tanto,
considere usarlo solo en sistemas no críticos.

JACC

Java Contrato de autorización para contenedores ( JACC ) es una extensión

de la seguridad estándar basada en políticas de la JVM para el mapeo de roles y
la autorización de servlets y EJB. El funcionamiento de esta seguridad basada en
políticas se muestra en la siguiente captura de pantalla:
A pesar de que es implementado por WebLogic, Oracle mismo desalienta su uso
debido a la falta de características y flexibilidad en comparación con los
proveedores personalizados, y también debido a problemas de rendimiento. Por
estas razones,JACC no será cubierto en este libro.

Resumen

Este capítulo fue una introducción rápida a los fundamentos de seguridad de

WebLogic, la teoría del aprendizaje que se utilizará más adelante cuando se
desarrolle o configure un proveedor personalizado dentro de nuestro dominio
mediante la consola WebLogic.

Comenzó desde la seguridad de Java EE y luego se redujo al Marco de

seguridad de WebLogic, desde MBeans hasta recursos.
Finalmente, dos solicitudes de especificación de Java ( JSR ) las
especificaciones fueron cubiertas, JASPIC y JACC, para mostrar cuán limitadas
se comparan con proveedores personalizados.

Capítulo 2. Reino de seguridad de

WebLogic

La configuración de seguridad de WebLogic puede ser difícil de entender. Este

capítulo cubre claramente todos los aspectos que debe tener en cuenta para
activar un usuario interno o externo y la estructura de un grupo. Aquí, también
puede encontrar una sección muy útil sobre errores y sugerencias de
depuración, necesaria para resolver sus problemas de configuración. Este
capítulo incluye lo siguiente:

 Configuración del servidor LDAP local: usuario / roles / lockout

 Configuración de un LDAP externo para Autenticación / Autorización

 Usar la aserción de identidad

Configuración del servidor LDAP

local: usuario / roles / lockout

La forma más sencilla de configurar su reino de seguridad es a través de la

consola de administración de WebLogic; puede encontrar todo sobre seguridad
en la sección, en el árbol principal, Security Realms , donde se coloca la
configuración predeterminada llamada myrealm .
En Security Realms , tenemos un subconjunto preconfigurado de usuarios,
grupos, métodos de autenticación, asignación de roles, proveedores de
correlación de credenciales y algunas otras configuraciones de seguridad.

Puede configurar conjuntos de seguridad de muchos ámbitos, pero solo uno

estará activo.

En la sección myrealm , encontramos todos los parámetros de seguridad de las

configuraciones internas del servidor LDAP, incluidos los usuarios y grupos.

Considera esto; Oracle declara que el servidor LDAP integrado de WebLogic

funciona bien con menos de 10,000 usuarios; para más usuarios, considere usar
un servidor LDAP diferente y un proveedor de autenticación, por ejemplo, un
servidor de Active Directory.

Usuarios y grupos

Obviamente, aquí puede agregar y configurar algunos usuarios internos y algunos grupos

internos. Un usuario es una entidad que puede ser autenticada y utilizada para proteger

nuestros recursos de aplicación. Un grupo es una agregación de usuarios que

generalmente tienen algo en común, como un subconjunto de permisos y autorizaciones.

Sección de usuarios
La ruta de la consola parala sección Usuarios es la siguiente:

Haga clic en Security Realms | myrealm | Usuarios y Grupos | Usuarios .

En esta sección, de forma predeterminada encontrará su cuenta de administrador, que se

utiliza para iniciar sesión en la Consola de administración de WebLogic y configurarse en el

asistente durante la fase de instalación; también puede crear algunos otros usuarios (nota:

los nombres son insertos insensibles a las mayúsculas y minúsculas) y establecer las

siguientes configuraciones:
  Descripción del usuario : una etiqueta de descripción de cadena interna

 Contraseña de usuario : contraseña de usuario sujeta a algunas reglas

 Ver atributos de usuario : algunos atributos de usuario

 Grupos asociados : predefinidos en lasección Grupos

Preste atención para preservar la integridad del usuario administrativo creado en el asistente

de configuración de instalación; este usuario es vital para el Servidor WebLogic (proceso de

inicio); no elimine a este usuario si no tiene un conocimiento avanzado de lo que está

haciendo y cómo revertir los cambios.

Tenga cuidado también de cambiar la contraseña del usuario administrador después de la

fase de instalación; si utiliza el proceso de inicio automático sin proporcionar un usuario y

una contraseña (necesarios cuando sea necesario para iniciar la consola de administración

en el sistema operativo como un servicio, sin solicitar ninguna solicitud interactiva) deberá

reconfigurar el archivo de credenciales para iniciar el servidor de administración en bota. El

siguiente archivo debe ser cambiado:

Dupdo

$DOMAIN_HOME\servers\Adminserver\security\boot.properties
username=weblogic
password=weblogicpassword

Nota
Después del primer arranque, el servidor de administración de WebLogic cifrará este archivo
con su método de cifrado interno.

Sección de grupos
La ruta de la consola para La sección de grupos es la siguiente:

Reinos de seguridad | myrealm | Usuarios y Grupos | Grupos

En esta sección, de manera predeterminada, encontrará algunos grupos utilizados para

perfilar las concesiones de usuarios (solo se rellenaron los grupos de Administradores y

Oracle) cuyos nombres no distinguen entre mayúsculas y minúsculas. Defina nuevos grupos

antes de crear un usuario para asociarlos. Los grupos más importantes son los siguientes:

 Administradores : este es el grupo más poderoso, que puede hacer todo en el

entorno de WebLogic. No agregue mucha gente, de lo contrario tendrá demasiados

usuarios con la capacidad de modificar la configuración de su servidor.

 Implementadores : este grupo puede administrar aplicaciones y recursos (por

ejemplo, JDBC, servicios web) y es muy apropiado para el equipo de operaciones

que necesita implementar y actualizar diferentes versiones de aplicaciones a

menudo durante el día.

 Monitores : Estogroup proporciona acceso de solo lectura a WebLogic y es

conveniente para monitorear los recursos y el estado de WebLogic.

 Operadores : este grupo proporciona el privilegio de concesión para detener, iniciar

y reanudar los nodos de WebLogic.

Todos los usuarios sin un grupo asociado son reconocidos por un rol anónimo . En este

caso, el grupo implícito (no presente en la lista) será el grupo de todos .

Condición del rol de seguridad

La ruta de la consola para roles y políticas son las siguientes:

 Ir a Security Realms | myrealm | Usuarios y Grupos | Roles del Reino | Políticas

de Reino | Roles

 Ir a Security Realms | myrealm | Usuarios y Grupos | Roles del Reino | Políticas

de Reino | Políticas
En WebLogic, puede configurar algunas colecciones de reglas avanzadas para confiar o

denegar el acceso sobre la configuración de seguridad de roles dinámicamente; todas las

condiciones deben ser verdaderas si desea otorgar un rol de seguridad.

Hay algunas condiciones disponibles en el mapeo de roles de WebLogic, que ahora

exploraremos en la siguiente sección.

BASIC
El disponible las opciones son las siguientes:

 Usuario : esta opción agrega al usuario a un rol específico si su nombre de usuario

coincide con la cadena especificada

 Grupo : esta opción agrega el grupo especificado al rol de la misma manera que la

regla anterior

 El servidor está en modo de desarrollo : esta opción agrega al usuario o grupo en

una función si el servidor se inicia en el modo de desarrollo

 Permitir acceso a todos : esto la opción agrega todos los usuarios y grupos al rol

 Denegar acceso a todos : esta opción rechaza que todos los usuarios participen en

el rol

Fecha y hora
Cuando se usa, este rol condición puede configurar una regla basada en una fecha o en un

tiempo (entre, después, antes y especificado) para otorgar una asignación de función.

Elemento de contexto
El servidor recupera información del ContextHandlerobjeto y le permite definir condiciones

de función basadas en los valores de los atributos de solicitud de servlet HTTP, los atributos

de sesión HTTP y los parámetros del método EJB.

Bloqueo del usuario
La ruta de la consola para el bloqueo del usuario es Security Realms | myrealm

| Bloqueo del usuario .

Bloqueo de usuario está habilitado por defecto; este proceso evita la intrusión del usuario y

ataques de diccionario. También mejora la seguridad del servidor y puede configurar

algunas políticas para bloquear a nuestros usuarios configurados locales. Esta opción se

aplica globalmente a cualquier proveedor de seguridad configurado.

En esta sección, puede definir la cantidad máxima de intentos de inicio de sesión no válidos

consecutivos que pueden ocurrir antes de que se bloquee la cuenta de un usuario y cuánto

tiempo dura el bloqueo. Después de ese período, la cuenta se vuelve a habilitar

automáticamente.

Si está utilizando un Proveedor de autenticación que tiene su propio mecanismo para

proteger cuentas de usuario, deshabilite la opción Bloqueo habilitado .

Cuando un usuario está bloqueado, puede encontrar un mensaje similar al siguiente

mensaje en los registros del servidor:

Dupdo

<Apr 6, 2012 11:10:00 AM CEST> <Notice> <Security> <BEA-090078> <User Test in

security realm myrealm has had 5 invalid login attempts, locking account for
30 minutes.>

Desbloquear usuario
El resultado de las configuraciones de bloqueo son un usuario bloqueado; si necesita

desbloquearlo de inmediato, debe dirigirse a la sección denominada Dominio , creada en la

fase de instalación del asistente en el panel izquierdo debajo de la sección Seguridad . Aquí

puede ver la pestaña Desbloquear usuario , donde puede especificar que el nombre de

usuario se vuelva a habilitar. Recuerde hacer clic en el botón Bloquear y editar antes de

realizar cualquier cambio.

Cuando desbloquea manualmente a un usuario, puede encontrar un mensaje similar al

siguiente mensaje en los registros del servidor:

Dupdo

…. <1333703687507> <BEA-090022> <Explicitly unlocked, user Test.>

Puede leer una configuración de aplicación de muestra para proteger su recurso y probar los

pasos anteriores en la sección de Seguridad en Java EE que se describe en el siguiente

capítulo de este libro.

Configuración de un LDAP
externo para Autenticación /
Autorización

Soporte de WebLogic varios tipos de proveedores de autenticación

externa. Cualquier servidor LDAP compatible con LDAP v2 o v3 debería
funcionar. A continuación, cubrimos la configuración del proveedor de Microsoft
Active Directory en detalle, para proporcionarnos también la compatibilidad con
el inicio de sesión único de Kerberos ( SSO)integración en una red de dominio
de Microsoft; veremos esto en el Capítulo 5 , Integración con Kerberos
SPNEGO Identity Assertion .

Hay muchas ventajas al conectar una infraestructura existente

de Usuarios y Grupos . Nos permite centralizar cualquier objeto
( Usuarios y Grupos ) y administrar centralmente las reglas y políticas de
seguridad sin la necesidad de acceder al servidor de WebLogic. Además,
cualquier cambio aplicado en Active Directory se propaga lógica y
dinámicamente a la seguridad de WebLogic.
Para configurar nuestro proveedor de manera más rápida y sencilla, podemos
usar la consola WebLogic (los usuarios avanzados también pueden usar
la WebLogic Scripting Tool ( WLST ) para hacer muchos cambios de
configuración) con un usuario administrativo. Vaya almenú de los dominios de
seguridad y haga clic en Proveedores . Ahora necesitamos información
importante, que es la siguiente:

 Tipo de proveedor de autenticación LDAP

 Atributos de configuración específicos del proveedor del proveedor de autenticación

LDAP

 Revise las opciones de rendimiento que controlan el caché

Nota
Planifique cualquier cambio en el momento de la configuración en un entorno de
producción, ya que necesita reiniciar el servidor y el servidor de administración.

Configurando un nuevo proveedor

La ruta de la consola para Proveedores es Security Realms | myrealm | Proveedores .

Haga clic en el botón Bloquear y Editar , vaya al botón Nuevo , nombre a su proveedor con

una referencia personal, seleccione el tipo como LDAPAuthenticator y haga clic

en Aceptar .

Más importante es el orden de los proveedores; WebLogic Security Framework es

compatible con más de un proveedor de autenticación para la autenticación de varias partes.

Los proveedores de autenticación necesita ser arreglado en el orden en que serán

llamados; es importante planificar la secuencia correcta en el proceso de inicio de sesión, la

primera comienza en la parte superior. Necesita usar el botón Reordenar para hacerlo.
Te aconsejo que dejes los proveedores predeterminados tal como están. De esta forma,

separe y preserve los grupos y usuarios internos, lo que es más importante, el administrador

de WebLogic, y comience a administrar WebLogic sin proveedores externos (piense en

algunos problemas de conectividad con el servidor LDAP / Active Directory). Luego, la

asignación de grupos internos a grupos externos se convierte en una tarea fácil.

Debe crear el mismo nombre de grupo en el proveedor externo y asociarle los usuarios

externos. Para esta regla, recuerde que el servidor de Active Directory también tiene un

grupo predeterminado llamado Administradores ; estos usuarios se agruparán

automáticamente como administradores de WebLogic cuando el proveedor esté

configurado.

Bandera de control

La ruta de la consola para trabajar con el parámetro Control Flages Security Realms

| myrealm | Proveedores | Autenticación . Otro parámetro importante presente en todo

autenticador es el parámetro Bandera de control . Establece cómo la secuencia de inicio

de sesión utiliza el Proveedor de autenticación. Utilizándolo, podemos modificar el proceso

de flujo de seguridad. Las opciones disponibles son las siguientes:

 REQUERIDO : Esta configuración establece que el proveedor siempre será

utilizado; el usuario necesita ser verificado para obtener un acceso de confianza. En

cualquier caso, la autenticación continúa a los demás proveedores de la lista.

 REQUERIDO : Esta configuración establece que el usuario debe pasar la verificación

del proveedor para que se le otorgue acceso, luego de eso, se ejecutarán los

proveedores subsiguientes.

 SUFICIENTE : Esta configuración establece que el proveedor no requiere que el

usuario apruebe su verificación. Si falla, se consultará al siguiente proveedor de la

lista. Si la autenticación tiene éxito, no se usarán otros proveedores.

  OPCIONAL : esta configuración establece que el cheque del proveedor se puede

aprobar o no. Si todos los proveedores están configurados en OPCIONAL , el

usuario debe pasar la fase de autenticación en uno de esos.

En nuestro escenario, necesitamos configure un proveedor conectado a Active Directory y

abandone el proveedor predeterminado, vuelva a ordenar el proveedor más usado en la

parte superior (en nuestro caso Active Directory) y cambie a SUFFICIENT todos los

indicadores de control del proveedor, como se muestra en el siguiente diagrama:

Configuración específica del proveedor de

Active Directory

Obviamente, para configurar este proveedor, necesitamos tener una estructura de dominio

de Active Directory configurada con algunos grupos y usuarios, y conocer algunos atributos

específicos de cualquier personalización sobre su LDAP interno.

Comencemos por revisar los parámetros en detalle.

Conexión
Una explicación detallada de los parámetros de conexión son como sigue:

 Host : Aquí, necesita especificar uno o más servidores de Active Directory; el

separador de lista es un espacio en blanco. En un entorno de producción, es una

buena opción especificar más de un servidor para alta disponibilidad. Si algún host

tiene un puerto de escucha diferente, especifíquelo en la lista; de lo contrario, se

usará el puerto especificado en el siguiente campo. Por

ejemplotest.directory.int:1090 test2.directory.int:1091

test3.directory.int ,.

 Puerto : aquí debe especificar el puerto de escucha del TCP / IP del catálogo global

(predeterminado3268).

 Director : Aquí debe especificar una base válida de Active Directory. El usuario

puede conectarse al catálogo global y realizar una consulta LDAP. Necesitamos

especificar un Nombre Distinguido correcto(DN )del usuario de LDAP. Supongamos

que tenemos un EXAMPLEDOM.INT\Users\tecnicalusrusuario de LDAP,

utilizamos cn=tecnicalusr , cn=Users, dc=exampledom , dc=int. Recuerde, las

carpetas preconfiguradas en Active Directory se definen como cn(por

ejemplo, Usuarios ), los objetos de las carpetas personalizadas estarán ouen su ruta

principal de definición.

 Credencial : contraseña de usuario principal utilizada para conectarse al servidor

LDAP.

 SSLEnabled : especifica si se usará un canal SSL cifrado para conectarse a un

servidor LDAP. Esto depende de su configuración de Active Directory.

Usuarios
Los parámetros para Los usuarios son los siguientes:
  DN de base de usuario : Aquí, especifica el nombre completo de base, donde

nuestros usuarios y grupos se encuentran en el árbol de Active Directory. Puede

configurar el árbol completo de Active Directory o un subárbol , considerando un

rendimiento mejorado mientras realiza la búsqueda, para dedicar unsubárbol a un

pequeño subconjunto de usuarios y grupos. Por ejemplodc=exampledom ,,dc=int.

 User From Name Filter : Aquí, especifica el filtro correcto para buscar usuarios de

Active Directory; la configuración predeterminada de Active Directory puede informar

esta consulta como(&(sAMAccountName=%u)(objectclass=user))

 Ámbito de búsqueda de usuario : aquí puede seleccionar el subárbol: al elegir

esta opción, la consulta puede navegar en el subárbol de niveles de Active

Directory. Es una buena opción, si su configuración no tiene un nivel dedicado y

necesita cortar algunos de los árboles.

 un nivel : en este caso, la consulta finaliza en el nivel de Active Directory

especificado en el DN base del usuario .

Grupos
Los parámetros para el Las pestañas de Grupos son las siguientes:

 DN de base de grupo : Aquí, especifica el nombre completo de base en las mismas

líneas que el DN basede usuario y en qué nivel se inicia la consulta LDAP para

encontrar los grupos. Por ejemplodc=exampledom, dc=int ,.

 Group From Name Filter : Aquí, especifica el filtro para buscar grupos de Active

Directory; la configuración predeterminada de Active Directory informa la consulta

como(&(cn=%g)(objectclass=group)).

 Alcance de búsqueda de grupo : de la misma manera que laconfiguración

de usuario , puede definir si la consulta cae en el subárbol o permanece en el árbol

especificado en elparámetro DN de base de grupo .

  Búsqueda de membresía grupal : aquí puede seleccionar las opciones de

búsqueda grupal. Se pueden realizar búsquedas limitadas e ilimitadas en los grupos

usando esta configuración.

 Nivel máximo de búsqueda de membresía de grupo : si, en el parámetro anterior,

seleccionó laopciónlimitada , aquí puede especificar cuántos grupos de usuarios

anidados siguen. Si especifica0, solo se encontrará el grupo de membresía

directa. Si especifica un número positivo, por ejemplo,1WebLogic podrá encontrar la

primera membresía del grupo y el segundo nivel de inclusión del grupo.

Grupos estáticos
Los parámetros para Los grupos estáticos son los siguientes:

 Atributo de nombre de grupo estático : en Active Directory, debe configurar este

parámetro paracn

 Clase de objeto de grupo estático : en Active Directory, debe configurar este

parámetro paragroup

 Miembro Estático DN Atributo : En el Active Directory, debe configurar este

parámetro para member

 DN de grupo estático del filtro DN de miembro : estos filtros de búsqueda, que

extraen el nombre completo de un miembro de un grupo, devuelven el nombre

completo de los grupos LDAP estáticos que contienen ese miembro y lo configuran

como(&(member=%M)(objectclass=group))

General
Los parámetros generales la sección es la siguiente:

 Tamaño del conjunto de conexiones : para empezar, podemos dejar el valor

predeterminado tal como está. Posteriormente, podemos ajustar este parámetro si

las consultas individuales toman mucho tiempo y el grupo se agotará.

 Tiempo de espera de conexión : aquí, especifique el tiempo máximo en segundos

que debe esperar hasta que se establezca la conexión con el servidor LDAP.

Te recomiendo que especifiques la cantidad de segundos; si configura este

parámetro 0, no se establecerán límites de tiempo y puede incurrir en una

ralentización en el rendimiento y un posible problema de rosca atascada. Otro

aspecto importante de la 0configuración de segundos impactantes es que si tiene

una lista de servidores de Active Directory, esto no se usará porque el proceso aún

está esperando una respuesta del primer servidor en la lista. Para una buena

conmutación por error, el tiempo está bien establecido entre 10-15segundos en un

entorno de producción en el que más de un servidor de Active Directory no aumenta

demasiado este número. Si este tiempo de espera es bajo, puede mejorar el

rendimiento de la fase de autenticación de inicio de sesión en caso de una falla de

Active Directory; esto nos permite equilibrar el segundo nodo de Active Directory en

la lista.

 Límite de reintento de la conexión : este número especifica los intentos totales que

se realizarán para conectarse al servidor LDAP si falla la primera conexión. Aumente

este número a un valor más alto si tiene un solo servidor de Active Directory; de lo

contrario, establezca este parámetro en un valor inferior 1para pasar rápidamente al

segundo servidor de respaldo de Active Directory; de esta manera, la fase de inicio

de sesión del usuario no puede esperar en el lado del navegador y evitar un

problema de tiempo de espera.

 Retardo de conexión en paralelo : este parámetro especifica el retraso en

segundos entre intentos de conexión simultánea para múltiples servidores

LDAP; establezca este parámetro en uno o más para crear conexiones en paralelo y

no serializar si tiene una lista de conmutación por error de Active Directory.

 Límite de tiempo de resultados : este parámetro especifica el número máximo de

milisegundos para que el servidor LDAP espere los resultados antes de que se

produzca un error de tiempo de espera. Si lo especifica0, no hay tiempo de

 espera; configure0solo si tiene más de un servidor de Active Directory y algunas

conexiones paralelas, de lo contrario, considere configurar algunos segundos

después de que se agote el tiempo de espera de la consulta, para evitar un problema

de subprocesamiento atascado en una respuesta de consulta en espera.

 Caché habilitada : Estoparámetro habilita o deshabilita un indicador LDAP de caché

WebLogic interno para mejorar su rendimiento.

 Tamaño de caché : este parámetro define el tamaño de la memoria caché en

KB. Aumente este tamaño si tiene objetos de estructura de Active Directory grandes

y algunos recursos de servidor WebLogic gratuitos.

 Cache TTL : este parámetro especifica cuánto tiempo se vaciará y volverá a cargar

el caché interno. Oracle recomienda un valor de6000. Considere ajustar este valor,

de acuerdo con la dinámica de las configuraciones de usuario y grupo de Active

Directory.

 Atributo GUID : este parámetro especifica el nombre delGroupIDatributo definido en

el Directorio Activo; El valor predeterminado es objectguid.

Deje cualquier otra configuración al valor predeterminado o personalícela si tiene algún

requisito específico. Ahora, recuerde guardar los cambios realizados si ha configurado su

instalación de WebLogic en modo de producción. Aplique estos cambios con el botón de

bandera verde y reinicie todos los servidores y también el Servidor de administración.

Después del inicio, vaya a Security Realms | myrealm | Usuarios y grupos y verifique si

los usuarios y grupos están configurados en su servidor de Active Directory; de lo contrario,

verifique el archivo de registro del Servidor de administración de WebLogic y vaya a

la sección Problemas de solución de problemas .

Si tiene demasiados resultados en la lista, puede filtrar en la parte superior de la tabla

utilizando el enlace Personalizar esta tabla . Aquí, puede insertar un filtro usando una

cadena de texto de criterios de filtrado o buscar usando una consulta

como username*. También puede especificar el número de filas que se muestran por

página.

Opciones de desempeño

La ruta de la consola para trabajar con La opción de rendimiento es Security Realms

| myrealm | Proveedores | MyProvider | Rendimiento .

En esta sección, puede ajustar algunos parámetros de acuerdo con las dimensiones de

jerarquía de usuarios y grupos de Active Directory. La opción Caché de jerarquíapuede

mejorar el rendimiento del servidor; deshabilite esta función solo si tiene recursos del

sistema de servidor WebLogic deficientes o un árbol pequeño de Active Directory sin grupos

anidados.

El primer indicador define si el servidor WebLogic podrá almacenar en caché algunos

niveles de membresías del grupo jerárquico o no. Algunas funciones de jerarquía son las

siguientes:

 Jerarquías máximas de grupo en caché : define el tamaño de la memoria caché

utilizada para almacenar jerarquías de membresía de grupo; el valor predeterminado

es100. Aumente este valor si tiene muchos grupos anidados. Oracle recomienda un

valor de1024.

 TTL de memoria caché de jerarquía de grupo : define el número de segundos que

el objeto en caché se almacenará en la memoria. Si tiene una situación de

membresía de grupo estática silenciosa, aumente este parámetro para reducir las

consultas al servidor LDAP y agilice el proceso aprovechando los datos internos en

caché. De lo contrario, si tiene cambios de membresía dinámicos altos, deje este

parámetro en el valor predeterminado de 60segundos. Oracle recomienda establecer

este valor en10minutos, pero tenga en cuenta todas las consideraciones anteriores.
Caché Validador Principal
La ruta de la consola para trabajar con esta opción es Security Realms | myrealm

| Rendimiento | Habilite la memoria caché del validador principal de WebLogic .

Para mejorar el rendimiento de su WebLogic Security Framework, mantenga esta opción

habilitada; está habilitada de manera predeterminada. Aquí puede establecer el número de

principales que se almacenarán en caché; el valor predeterminado es 500.

Problemas de solución de problemas

WebLogic el reino de la seguridad es una parte fundamental de la fase de inicio. Aquí, en

primera instancia, el servidor necesita encontrar al usuario configurado para iniciar el

servicio de administración; después de esto, necesitamos que todos los proveedores de

seguridad, incluido el proveedor de autenticación, tengan un indicador de

control JAAS configurado en OPCIONAL para completar la fase de inicialización.

Si la fase de inicialización no puede completarse correctamente, el arranque del servidor

WebLogic falla, mostrando un error similar al siguiente:

Dupdo

<BEA-090870> <The realm "myrealm" failed to be loaded:

Si tiene problemas para conectarse desde el lado de Active Directory, puede buscar algunos

errores en sus archivos de registro de WebLogic. Déjame mostrarte algunos mensajes de

error, como se muestra en el siguiente fragmento de código:

Dupdo

Caused by: netscape.ldap.LDAPException: error result (49); 80090308: LdapErr:

DSID-0C0903AA, comment: AcceptSecurityContext error, data 525, v1772; Invalid
credentials

En el mensaje de error anterior, el error result (49) valor del error se encuentra cuando

ha proporcionado credenciales no válidas para iniciar sesión en el servidor de Active

Directory. En el mensaje de error anterior, también puede encontrar el código de error

LDAP 525.

Los siguientes son algunos Códigos de error LDAP y sus descripciones correspondientes:

 525: Usuario no encontrado

 52e: Credenciales no válidas

 530: No se permite iniciar sesión en este momento

 531: No se permite iniciar sesión desde esta estación de trabajo

 532: La contraseña expiró

 533: Cuenta deshabilitada

 701: Cuenta expirada

 773: El usuario debe restablecer la contraseña

 775: Cuenta de usuario bloqueada

La siguiente excepción se puede encontrar cuando WebLogic no se puede conectar al

servidor de Active Directory. Para solucionar este problema, consulte su Nombre de host / IP

o Puerto:

Dupdo

Caused by: netscape.ldap.LDAPException: Connection refused (91)

Si el error (32)mensaje de error aparece, entonces verifique las configuraciones del

filtro. Este error se encuentra cuando el filtro no puede encontrar ninguna entrada que

coincida con los criterios del filtro de búsqueda.

Para obtener más información sobre el código de error LDAP, consulte

la com.novell.ldap.LDAPException clase

de http://developer.novell.com/documentation/jldap/jldapenu/api/com/novell/ldap/LDAPExcep
tion.html o intente buscar la clase LDAPExceptionen la Web usando su motor de búsqueda

favorito.

Bloqueo de usuario en un contexto de Active

Directory
Bloquear un usuario es una Proceso interno; no afecta a los usuarios de Active Directory. Si

habilita la opción Bloqueo de usuario con una configuración de Active Directory, recuerde

que debe desbloquear este usuario utilizando la Consola de administración de WebLogic y

no usar la herramienta de utilidad Usuarios de Active Directory y Grupo de Microsoft.

Piense en esto como un prefiltro que almacenará en caché un estado de usuario (habilitado

o deshabilitado) en la capa de WebLogic. Es una mejor opción para simplificar y centralizar

el bloqueo de la política de seguridad del usuario en el lado de Active Directory para

desactivar esta función.

Usar la aserción de identidad

Típicamente a admite un proceso SSO, necesita tener un LoginModuleobjeto y un

proveedor de Aserción de identidad. Con estos objetos, puede aprovechar los
tokens almacenados por el sistema operativo para realizar el proceso de
autorización HTTP sin ingresar el nombre de usuario y la contraseña y obtener
acceso a sus recursos seguros.

Los LoginModuleobjetos confían en que el usuario ha obtenido el token

proporcionando el nombre de usuario y la contraseña a otra autoridad.

Su token puede pasar de un cliente a otro de diferentes maneras, como

encabezados HTTP, cookies, certificados SSL u otros mecanismos
personalizados. La declaración de identidad necesita tomar este token y extraer
la información de seguridad para permitir el acceso a las rutas de contexto
seguras.

Utilizaremos el proveedor de Identity Asserter de SPNEGO en el Capítulo

5 , Integración con Kerberos SPNEGO Identity Assertion para configurar la
integración de SSO en un contexto de Active Directory.

Resumen

Este capítulo cubrió la administración básica de usuarios y grupos del servidor

interno de LDL de WebLogic y algunas facilidades para administrar y comprender
los roles de seguridad y las condiciones que configurará en su servidor.

Este es un capítulo importante, que cubre en detalle los parámetros y conceptos

necesarios para conectar su servidor WebLogic en un entorno existente de
Active Directory, ajustando y comprendiendo algunos trucos para mejorar su
rendimiento.

También discutimos los problemas que a menudo ocurren durante la

configuración, junto con algunos códigos de error típicos y sus posibles
soluciones.

Capítulo 3. Seguridad de Java EE

con WebLogic

En este capítulo veremos cómo implementar la seguridad Java EE estándar en

una aplicación WebLogic Enterprise, con uso extensivo de ejemplos del mundo
real, y finalizar con un proyecto Maven completamente completo que puede
implementar con un objetivo en su servidor de desarrollo.
Configuración de un proyecto de
Enterprise Maven

Ahora lo haremos cree, paso a paso, una aplicación segura utilizando Maven, el
complemento Oracle Maven y, por supuesto, el servidor WebLogic. Un requisito
previo para esto es que Maven 3 se debe instalar y configurar
correctamente. Ver el oficial Mavensitio para obtener información sobre cómo
descargar e instalar Maven, en http://maven.apache.org .

Creando los módulos con maven-archetype-

plugin

El seguimiento son los pasos que debemos seguir para crear la aplicación que vamos a

utilizar durante este capítulo:

1. Crear el Modelo de Objeto de Proyecto primario ( POM ) navegando a la carpeta

del proyecto desde la herramienta de línea de comandos y ejecutando el siguiente

comando:

Dupdo

mvn archetype:generate -Dversion=1.0-SNAPSHOT -

DgroupId=net.lucamasini.security -DartifactId=chapter3 -
DarchetypeArtifactId=pom-root -
DarchetypeGroupId=org.codehaus.mojo.archetypes

2. Navegue a la chapter3carpeta recién creada usando la herramienta de línea de

comandos y cree el módulo EAR, de la siguiente manera:

Dupdo

mvn archetype:generate -Dversion=1.0-SNAPSHOT -

DgroupId=net.lucamasini.security -DartifactId=chapter3-ear -
 DarchetypeArtifactId=ear-javaee6 -
DarchetypeGroupId=org.codehaus.mojo.archetypes

3. De la misma manera, crea un módulo EJB usando el siguiente comando:

Dupdo

mvn archetype:generate -Dversion=1.0-SNAPSHOT -

DgroupId=net.lucamasini.security -DartifactId=chapter3-ejb -
DarchetypeArtifactId=ejb-javaee6 -
DarchetypeGroupId=org.codehaus.mojo.archetypes

4. Finalmente, crea un módulo web usando el siguiente comando:

Dupdo

mvn archetype:generate -Dversion=1.0-SNAPSHOT -

DgroupId=net.lucamasini.security -DartifactId=chapter3-web -
DarchetypeArtifactId=webapp-javaee6 -
DarchetypeGroupId=org.codehaus.mojo.archetypes

Para probar si todo estaba correctamente configurado, ahora podemos iniciar una

instalación navegando a la carpeta principal y ejecutando el siguiente comando:

Dupdo

mvn install

También verifique si se creó un archivo EAR en la chapter3-ear/targetcarpeta; busque

el siguiente archivo:

Dupdo

chapter3-ear-1.0-SNAPSHOT.ear

El archivo EAR que se crea está completamente vacío, porque el plugin Maven EAR

examina las dependencias del módulo EAR para crear un módulo empresarial, por lo que

ahora necesitamos agregar las siguientes dependencias al pom.xmlarchivo EAR :

Dupdo

<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>${parent.artifactId}-ejb</artifactId>
<version>${project.version}</version>
 <type>ejb</type>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>${parent.artifactId}-web</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
</dependencies>

EAR aún no es una aplicación Enterprise válida para WebLogic; aún necesitamos agregar

un Enterprise Bean en el módulo EJB. El siguiente es el Bean más simple que podemos

codificar:

Dupdo

package net.lucamasini.security;

import javax.ejb.Stateless;

@Stateless
public class MySimpleNoInterfaceBean {
public String echo(String input) {
return "$"+input+"$";
}
}

Finalmente nosotros tener un EAR de trabajo! Si tiene WebLogic ejecutándose, puede

implementarlo e ir a la http://localhost:7001/chapter3-webURL, después de lo cual

se muestra el siguiente resultado:

En caso de que no tenga uno, aprenderá cómo crear un dominio, iniciar un servidor y

desplegar el EAR en las próximas secciones.

Instalación del servidor WebLogic y el plugin

Maven de WebLogic

Se puede descargar una copia de WebLogic Server 12c de Oracle TechNet

en http://www.oracle.com/technetwork/index.html (el archivo ZIP de tamaño reducido para

desarrolladores debe ser de aproximadamente 180 MB). Después obtenemos los binarios,

tenemos que extraer los dos archivos siguientes del archivo utilizando los siguientes

comandos para los archivos respectivos:

Dupdo

unzip /Users/lucamasini/Downloads/wls1211_dev.zip wlserver/server/lib/wls -

maven-plugin.jar.pack
unzip /Users/lucamasini/Downloads/wls1211_dev.zip wlserver/server/lib/pom.xml

Use el siguiente comando para descomprimir el JAR:

Dupdo
unpack200 -r wlserver/server/lib/wls-maven-plugin.jar.pack
wlserver/server/lib/wls-maven-plugin.jar

Ahora que tenemos todo lo que necesitamos para emitir la instalación del complemento en

el localRepository elemento, ejecute el siguiente comando:

Dupdo

cd wlserver/server/lib
mvn install
mvn install:install-file -Dfile=wls-maven-plugin.jar -DpomFile=pom.xml

También agregue el Complemento groupIdal conjunto de grupos predeterminados, de la

siguiente manera:

Dupdo

<pluginGroups>
<pluginGroup>com.oracle.weblogic</pluginGroup>
</pluginGroups>

Edite el settings.xmlarchivo global(corre mvn -X | grep globalpara ver dónde

puedes encontrarlo en tu entorno).

Ahora debemos navegar a la carpeta EAR chapter3/chapter3-eare iniciar una

instalación local de WebLogic Server, la que utilizaremos a lo largo de este libro, de la

siguiente manera:

Dupdo

mvn wls:install -DartifactLocation=/Users/lucamasini/Downloads/wls1211_dev.zip

Ahora solo necesitamos un dominio para comenzar, con un nombre de usuario y contraseña

para la cuenta de administrador, así que ejecute el siguiente comando:

Dupdo

mvn wls:create-domain -Duser=weblogic -Dpassword=weblog1c

Propina
Máquina virtual Java de 64 bits

Debajo Sistemas de 64 bits, tenemos que ampliar el espacio de Generación permanente si

estamos utilizando el HotSpot JVM. Exporte esta variable de entorno antes de iniciar el
servidor, de la siguiente manera:

Dupdo

export USER_MEM_ARGS="-Xms256m -Xmx512m -XX:CompileThreshold=8000 -

XX:PermSize=128m -XX:MaxPermSize=256m"

Finalmente, podemos lanzar nuestro servidor de desarrollo de la siguiente manera:

Dupdo

mvn wls:start-server

Si todo está bien, podemos alinear el archivo de salida (busque en el registro de comando

anterior para stdoutver si el servidor está en RUNNINGmodo, de la siguiente manera:

Dupdo

<Notice> <WebLogicServer> <BEA-000360> <The server started in RUNNING mode.>

Otra prueba que puede hacer es verificar si podemos detenerlo con gracia, usando lo

siguiente:

Dupdo

mvn wls:stop-server -Duser=weblogic -Dpassword=weblog1c

Configurando wls-maven-plugin en EAR POM

Ya que los elementos usery passwordse usan a menudo durante el desarrollo, podemos

configurar el complemento en el pom.xmlarchivo del módulo EAR para que no tengamos

que pasarlos cada vez, usando el siguiente fragmento de código:

Dupdo

<build>
<plugins>
<plugin>
 <groupId>com.oracle.weblogic</groupId>
<artifactId>wls-maven-plugin</artifactId>
<version>12.1.1.0</version>
<configuration>
<user>weblogic</user>
<password>weblog1c</password>
<verbose>true</verbose>
</configuration>
</plugin>
</plugins>
</build>

Ahora que hemos configurado nuestro entorno de desarrollo, podemos comenzar a

implementar la aplicación en el dominio del servidor WebLogic en ejecución.

Propina
Depuración de su aplicación Enterprise

A menudo tenemos que adjuntar un depurador a nuestra aplicación en ejecución; para esto
podemos exportar la siguiente variable de entorno antes de ejecutar el objetivo de servidor
de inicio. De esta forma, la Máquina Virtual Java aceptará conexiones en el 55822puerto
desde el depurador local / remoto.

Dupdo

export JAVA_OPTIONS="-Xdebug -
Xrunjdwp:transport=dt_socket,address=127.0.0.1:55822,suspend=n,server=y"

Split deploy y beabuild-maven-plugin

Ahora que tenemos nuestra aplicación simple y estamos ejecutando el Servidor WebLogic,

podemos comenzar a desarrollar simplemente haciendo una instalación usando el siguiente

comando:

Dupdo

mvn install
Este comando se ejecuta en la carpeta POM raíz. Desde la carpeta del módulo EAR, ejecuta

lo siguiente:

Dupdo

wls:deploy -Dname=chapter3-ear

Hay muchos razones por las que no puede considerar esto como un ciclo de vida de

desarrollo ágil, pero la razón principal es que debe volver a empaquetar toda la aplicación

cada vez que cambie una clase o un descriptor de implementación.

De hecho, se trata de dos problemas separados que se resuelven mediante herramientas /

tecnologías que se envían con WebLogic: implementación de intercambio rápido y división,

que se describe a continuación:

 Dividir despliegue: este es un conjunto de herramientas de diseño de carpetas y

WebLogic que permite al desarrollador volver a desplegar la aplicación más rápido

sin necesidad de copiar archivos ni crear archivos de aplicaciones.

 Fast-swap: Esta es una mejora de la redefinición de la clase de tiempo de ejecución

de Java EE que permite la recarga de clases modificadas en el cargador de clases

de una aplicación en ejecución.

Pero no puede usarlos de fábrica en su aplicación Maven, debido a las siguientes razones:

 Fast-swap no es compatible con la caja de desarrollo de 64 bits, una configuración

de desarrollo común en estos días

 La implementación dividida utiliza un diseño de carpeta que no es convencional para

los usuarios de Maven

Para resolver el problema del intercambio rápido, puede usar una JVM que admita la

recarga de bytecode, como la fuente abierta. Dynamic Code Evolution VM ( DCEVM ) -o

use JRebeldesde http://zeroturnaround.com/ (que también es compatible con la recarga de

recursos).
Resolver el problema de despliegue dividido nos lleva a escribir algunas configuraciones de

Maven. Primero tenemos que configurar el complemento beabuild-generator-plugin en

el pom.xmlarchivo raíz de la siguiente manera:

Dupdo

<pluginRepositories>
<pluginRepository>
<id>beabuild.release</id>
<name>Beabuild Release Repository</name>
<url>http://maven-beabuild-
plugin.googlecode.com/svn/maven2/releases</url>
</pluginRepository>
</pluginRepositories>

<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>beabuild-generator-plugin</artifactId>
<version>0.9.3</version>
<executions>
<execution>
<id>generate</id>
<goals>
<goal>generate-beabuild</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>

Y luego en el pom.xmlarchivo de los módulos EAR y WAR , inserte el siguiente código:

Dupdo

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>beabuild-generator-plugin</artifactId>
</plugin>

Ahora ejecuta mvn installdesdese generará el POM raíz y un nuevo archivo,

nombrado .beabuild.txt . Esto contendrá un catálogo que WebLogic utilizará en lugar del

diseño estándar de Java EE para crear la aplicación que se implementará. El complemento

sabe cómo funciona Maven, por lo que encontrará en esos archivos todas las dependencias
requeridas en tiempo de ejecución a las que se hace referencia como bibliotecas, clases en

target / classes y la webappcarpeta donde están contenidos nuestros recursos de WAR.

Al trabajar de esta manera, podemos olvidarnos de empacar nuestra aplicación; todo lo que

tenemos que hacer es realizar una instalación desde la carpeta raíz cada vez que

agreguemos o eliminemos una dependencia, y luego ejecutemos el objetivo de despliegue

estándar apuntando como sourceen la carpeta que contiene

el .beabuild.txt archivo. Esto se puede configurar en el POM de nuestro módulo EAR

agregando las siguientes etiquetas a la configuración del complemento WebLogic:

Dupdo

<name>${project.artifactId}</name>
<source>${basedir}/src/main/application</source>

Nosotros también necesita el application.xml archivo, que no es obligatorio en una

aplicación Java EE 6, pero que es necesario para WebLogic cuando utilizamos este tipo de

implementación. El siguiente código, si está insertado en EAR POM, generará

automáticamente el application.xmlarchivo para nosotros:

Dupdo

<executions>
<execution>
<id>generate-application-xml</id>
<phase>install</phase>
<goals>
<goal>generate-application-xml</goal>
<goal>ear</goal>
</goals>
</execution>
</executions>

También necesitamos excluir el .beabuild.txtarchivo. Desde el EAR generado o

WebLogic se intentará hacer una distribución dividida en modo de producción cuando se

encuentre este archivo y se indicará dónde application.xml se generará, utilizando el

siguiente código:

Dupdo
<generatedDescriptorLocation>${project.basedir}/src/main/application/META-
INF/</generatedDescriptorLocation>
<earSourceExcludes>.beabuild.txt</earSourceExcludes>

La etiqueta anterior en la configuración del complemento EAR hace todo el trabajo

sucio. Ahora podemos ejecutar installdesde el módulo raíz por primera vez para

que application.xml y .beabuild.txt se genere, utilizando el siguiente comando:

Dupdo

mvn install

De ahora en adelante, despliegue nuestra aplicación desde el módulo EAR con solo el

siguiente comando simple:

Dupdo

mvn wls:deploy

¡Ya no necesitamos empaquetar la aplicación!

Para resumir, usando una JVM que recarga clases y recursos y el plugin de beabuild,

nuestro ciclo de vida de desarrollo podrá hacer lo siguiente:

 Compilar con el IDE para cambios en el código fuente

 Si también cambia algunos descriptores de implementación o anotaciones, inicie mvn

wls:deploydesde el módulo EAR, sin empaquetar la aplicación

¡Eso es lo que llamamos un flujo de trabajo de desarrollo ágil!

Lanzamiento de nuestra aplicación mundial

Hello Maven y WebLogic

Ahora que nosotros tener un servidor WebLogic en ejecución y una aplicación configurada

para un desarrollo ágil, simplemente podemos iniciar nuestra aplicación de la siguiente

manera:

Dupdo
mvn wls:deploy

Ahora podemos llamar http://localhost:7001/chapter3-webpara ver la aplicación de

inicio en acción.

Asegurar el módulo web

El primer recurso que queremos proteger es el recurso web, un servlet, de la

siguiente manera:

Dupdo

package net.lucamasini.security;

@WebServlet(name="MyWorkServlet",
urlPatterns={"/myprotectedresource"})
public class MyProtectedServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException {
Principal userPrincipal = req.getUserPrincipal();
resp.getWriter().println(userPrincipal!=null?userPrincipal.getName():
"anonymous");
}
}

Aquí podemos ver el poder de Java EE 6: no necesitamos escribir XML para

declarar un servlet y vincularlo a una URL, una sola anotación es
suficiente. Ahora, después de compilar y lanzar, el objetivo de implementación
nos permitirá llamar http://localhost:7001/chapter3-
web/myprotectedresource y ver la cadena anonymous; esto significa que nuestro
servlet se ha implementado y el usuario sigue siendo anónimo.

Ahora podemos ir un paso más allá y proteger el recurso web. Nuevamente, una
anotación simple hace el trabajo sin la necesidad de editar web.xml, de la
siguiente manera:

Dupdo
@ServletSecurity(@HttpConstraint(rolesAllowed={"my-user"}))

Si llamamos a la URL ahora, al ingresar los principios de administrador de

WebLogic ( weblogic/ weblog1ccuando creamos el dominio con el create-
domainobjetivo) debería obtenerse un código de estado HTTP PROHIBIDO
403 . Esto significa que el usuario ha sido reconocido, pero no tiene derechos
para acceder al recurso. Esto puede sonar un poco extraño: el grupo de
administradores puede hacer todo lo que está en nuestro dominio, pero es
perfectamente válido que nuestra aplicación no confíe en dichos usuarios.

El problema es que nunca especificamos a WebLogic que el my-userrol está

asignado al principal del administrador.

Ahora tenemos que decidir qué tipo de estrategia de asignación de roles

necesitamos usar. Una asignación Java EE típica se realiza utilizando
descriptores de implementación personalizados (como el weblogic.xmldescriptor
de implementación personalizado), pero esto tiene el requisito previo de conocer
los grupos y usuarios que utilizarán nuestra aplicación.

Si, en cambio, no podemos saber de antemano cuáles son los usuarios y cuáles
son los grupos, necesitamos cambiar esas asignaciones sin redistribución, o si la
asignación es demasiado compleja para definirla mediante una relación de uno a
varios (un rol asignado a muchos principios), tenemos otro oportunidad en
WebLogic usando su tiempo de ejecución personalizado Roles Mapper.

Mapeo estándar de DD

Comencemos con el mapeo DD estándar. Para esto, finalmente, necesitamos escribir XML,

el descriptor de despliegue personalizado weblogic.xml , en la src/main/webapp/WEB-

INFcarpeta, de la siguiente manera:

Dupdo
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
<security-role-assignment>
<role-name>my-user</role-name>
<principal-name>users</principal-name>
</security-role-assignment>
</weblogic-web-app>

Aquí, estamos utilizando uno de los grupos integrados en WebLogic; todos los usuarios son

implícitamente también miembros del usersgrupo, y esta vez llamar a la URL funcionará y

veremos que weblogic aparece en nuestro navegador.

Asignación de roles personalizados

El mapeo de roles es hecho por WebLogic Server XACML Role Mapping Provider, que nos

permite usar la consola o su MBEan en tiempo de ejecución, para declarar roles bajo ciertas

condiciones. De hecho, podemos hacer todo lo que hace el DD estándar, como declarar un

rol si uno o más grupos son directores del tema actual, pero también declarar reglas como

está en modo de desarrollo o no en el grupo. Para obtener una lista completa, puede ver la

documentación oficial.

Ahora comenzamos a hacer lo mismo en el DD, es decir, declarar que cada director que

está en el usersgrupo tiene el rol my-user. Podríamos hacer esto de una manera muy

rápida e intuitiva utilizando la consola web, pero en este capítulo haremos todo lo posible

con Maven y esta no es una excepción.

Debemos crear el archivo create-roles.pydebajo de la chapter3-earcarpeta con el

siguiente contenido:

Dupdo

connect('weblogic','weblog1c')
xacml =
cmo.getSecurityConfiguration().getDefaultRealm().lookupRoleMapper('XACMLRoleMa
pper')
xacml.createRole(None,'my-user',None)
xacml.setRoleExpression(None,'my-user', 'Grp(users)')
Y luego corre el siguiente script WLST con el plugin Maven:

Dupdo

mvn wls:wlst -DfileName=create-roles.py

Al hacer esto, creamos una función global llamada my-userque podemos verificar debajo de

la consola en Inicio | Resumen de los reinos de seguridad | myrealm | Roles del

Reino | Roles globales .

Propina
Roles de implementación

No estamos limitados a crear roles globales; también podemos crear un rol que sea local
para una aplicación implementada específica

Por supuesto, llamar http://localhost:7001/chapter3-

web/myprotectedresource tendrá el mismo efecto deseado de mostrarnos el usuario

registrado actualmente.

Seguridad programática

Hay ciertas situaciones cuando no podemos confiar solo en la seguridad declarativa; cuando

necesitamos otro nivel de inteligencia para entender si el usuario puede o no puede acceder

al recurso solicitado. En efecto, la semántica de la seguridad declarativa estándar es

bastante primitiva: una lista de principios en O lógico; no es suficiente para muchos casos de

negocios.

Imagine, por ejemplo, que necesita verificar si un usuario es miembro de al menos dos

grupos, si la hora del día está en un cierto rango o si el usuario está en una tabla de

negocios.
En todos estos casos, necesitamos codificar la seguridad de nuestra aplicación, y Java EE

no ayuda mucho. En el nivel web, solo tenemos una llamada API que nos puede decir si un

usuario tiene o no un rol determinado. Podemos agregar la siguiente línea de código a

nuestro servlet para experimentar:

Dupdo

resp.getWriter().
println("my-user: "+req.isUserInRole("my-user"));

Ahora, llamando a nuestro La URL también mostrará my-user: true , porque también

estamos usando seguridad declarativa para permitir el acceso a ese recurso. Por lo general,

debemos deshabilitar la seguridad declarativa cuando necesitamos seguridad programática

y luego codificar nuestra regla comercial.

Seguridad programática con el proveedor

WebLogic XACML

En WebLogic, nosotros tener la oportunidad de omitir la codificación de seguridad cuando

usa las Funciones del cliente. De hecho, cuando declaramos nuestros roles tenemos una

semántica más rica, y si se necesita un usuario que es miembro de dos

grupos: usersy Administrators -se puede escribir lo siguiente:

Dupdo

Grp(users)&Grp(Administrators)

Pero este Proveedor no se limita a esto. También podemos hacer lo siguiente:

 Negar las condiciones

 Compruebe si el servidor está en el modo de desarrollo

 Verifique si la fecha y la hora siguen algunas condiciones, como el día de la semana

y el rango de horas
  Elementos contextuales, como la solicitud HTTP actual o el puerto del socket

El uso del proveedor de asignación de roles XACML de forma correcta puede evitar que

codifiquemos la seguridad programática utilizando un estándar bien definido como

OASIS. Lenguaje de marcado de control de acceso extensible( XACML ).

Un componente EJB RESTful y

seguro

Java EE 6 no solo nos permiteempaquetar los EJB en su propio módulo, pero

también desplegar nuestros Beans directamente en el módulo WAR que los
usará. Veremos cómo proteger estos dos escenarios.

Bean empaquetado en el módulo WAR

A menudo, no necesitamos paquete Enterprise Beans en un módulo separado; podemos

ubicarlos dentro del mismo módulo cliente WAR y simplificar nuestra arquitectura de

aplicaciones. Ahora, desarrollaremos un EJB simple que se inyectará en el

existenteMyProtectedServlet clase. También veremos el contexto de seguridad que se

aprobará y la configuración que necesitamos hacer.

Comencemos simple; podemos codificar este StatelessBean realmente simple sin vista de

interfaz, como se muestra en el siguiente fragmento de código:

Dupdo

package net.lucamasini.security;

import javax.ejb.Stateless;

@Stateless
public class NoInterfaceBeanInWarModule {
public String echo(String input) {
return "$"+input+"$";
}
}

Este archivo Java debe estar en la misma carpeta que contiene nuestro servlet, y también

debemos modificar el servlet para incluir la inyección. Usa el siguiente código:

Dupdo

@EJB
private NoInterfaceBeanInWarModule service;

Y agregue la invocación del servicio de la siguiente manera:

Dupdo

resp.getWriter().println("echo:"+service.echo("echo"));

Nada especial hasta ahora, podemos encontrar muchos tutoriales que nos muestran cómo

hacer esto. Si llamamos a la URL habitual ahora, veremos otra línea en el navegador que

muestra lo siguiente:

echo: $ echo $

Propina
¿Cuándo a menudo cambiamos los metadatos?

En esta sección, a menudo cambiaremos la anotación de nuestro experimento, por lo que mi

consejo es lanzar el objetivo de implementación cada vez para evitar incurrir en resultados
inesperados. Esto será innecesario durante el ciclo de vida de desarrollo estándar.

Comencemos introduciendo seguridad en nuestro EJB agregando la siguiente anotación a la

clase Bean:

Dupdo

@RolesAllowed("my-user")

Ahora, al volver a llamar a la URL, veremos el mismo resultado, pero ahora Bean está

protegido. De hecho, cada llamada a cualquier método verificará si el principal tiene el my-
userrol, y si no se generará un error de seguridad. Comprobemos esto agregando la misma
anotación al único método con otra función, de la siguiente manera:

Dupdo

@RolesAllowed("my-special-user")

Ahora no podemos acceder a la URL de prueba; veremos el siguiente mensaje de error en el

registro del servidor (y también en la ventana del navegador):

Dupdo

javax.ejb.EJBAccessException: [EJB:010160]Security violation: User weblogic

has insufficient permission to access EJB type=<ejb>, application=chapter3-
ear, module=/chapter3-web, ejb=NoInterfaceBeanInWarModule, method=echo,
methodInterface=Local, signature={java.lang.String}.

La excepción es muy clara y nos dice que la conexión actual useres weblogic, y también

muestra la firma del método que estamos tratando de llamar, para permitirnos identificar

rápidamente el problema. Para resolverlo, podemos agregar asignación de roles al

descriptor de despliegue personalizado o usar el Role Mapper de XACML. En el último caso,

podemos agregar las siguientes dos líneas a la create-roles.py Archivo Python utilizado

para nuestro servlet:

Dupdo

xacmlRoleMapper.createRole(None,'my-special-user',None)
xacmlRoleMapper.setRoleExpression(None,'my-special-user', 'Grp(users)')

Y entonces Inicie el WLST para ejecutarlo de la siguiente manera:

Dupdo

mvn wls:wlst -DfileName=create-roles.py

Esto soluciona el problema y nos permite ejecutar nuestro servlet de nuevo. Pero queremos

ir un paso más allá y configurar esto usando un grupo diferente y el descriptor de despliegue

personalizado de WebLogic.
El primer paso es configurar el servidor LDAP interno, crear un nuevo bookreadersgrupo y

luego agregar un nuevo usuario luca,a ese grupo. Esto se puede hacer con la Consola de

administración como hemos visto en el Capítulo 2 , Reino de seguridad de

WebLogic . Luego debemos crear el weblogic-ejb-jar.xmlarchivo en la WEB-

INFcarpeta con el siguiente contenido:

Dupdo

<?xml version="1.0" encoding="UTF-8"?>

<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar">
<security-role-assignment>
<role-name>my-special-user</role-name>
<principal-name>bookreaders</principal-name>
</security-role-assignment>
</weblogic-ejb-jar>

Mediante la redistribución de nuestro ejemplo, ahora podemos llamar con éxito nuestra URL

de prueba utilizando el nuevo usuario configurado, luca.

Cambiar la identidad de seguridad con RunAs

Hay algunos usos casos en los que necesitamos llamar a algunos métodos comerciales sin

tener el derecho de hacerlo. Por ejemplo, es posible que deba llamar a un método que los

usuarios administrativos suelen llamar desde una cuenta no administrativa.

La solución para ese caso de uso es la RunAs anotación, que nos permite suplantar a

cualquier principal, porque por defecto Java EE confía en las identidades entre los

contenedores y no necesitamos ninguna configuración especial para que esto funcione.

Podemos ver esto en funcionamiento en nuestra aplicación eliminando el usuario / grupo

recién creado y cualquier asignación de roles, y luego agregando la siguiente anotación en

la definición de la clase Bean:

Dupdo

@RunAs("my-special-user")
Por supuesto, luego debemos especificar el usuario real que se ejecutará con esa función,

dentro del weblogic-ejb-jar.xmlDD personalizado, de la siguiente manera:

Dupdo

<run-as-role-assignment>
<role-name>my-special-user</role-name>
<run-as-principal-name>weblogic</run-as-principal-name>
</run-as-role-assignment>

Esto permite la confianza entre contenedores; el contenedor EJB ahora confiará en

que weblogic-authenticated en el contenedor serlvet-tiene el my-special-userrol y, como

tal, también puede invocar sus métodos.

Asegurar el módulo EJB

Acabamos de Terminé de explorar cómo podemos proteger servlets y EJB en el módulo

WAR. La codificación y la configuración requeridas no son diferentes si decidimos

implementar un Bean en un Módulo EJB; la única diferencia es que el weblogic-ejb-

jar.xmlarchivodebe estar escrito en la src/main/resources/META-INFcarpeta, y que

los módulos WAR y EJB dentro de un EAR tienen diferentes cargadores de clase.

Por supuesto, si su EAR tiene muchas WAR que comparten lógica comercial, esta es la

configuración de implementación deseada; pero si su aplicación está compuesta de un único

WAR y un solo EJB, considere cambiar a un despliegue solo de WAR.

Resumen

En este capítulo, aprendimos cómo configurar WebLogic para desarrollo, cómo

desarrollar una aplicación Enterprise simple y cómo podemos configurar
seguridad específica para WebLogic.
Capítulo 4. Creación de
proveedores de autenticación
personalizados con Maven

En este capítulo, aprenderemos cómo implementar un proveedor personalizado

que integre algunos de nuestros sistemas SSO heredados.

Desarrollar un proveedor consiste en las siguientes tareas:

 Creando y configurando un proyecto Maven

 Escribiendo nuestro delegado MBean

 Desarrollar un JAAS LoginModuleque interactúa con nuestro SSO y devuelve

Principals a WebLogic

Como veremos, el trabajo más difícil será configurar a Maven para que tenga un
proyecto reproducible y listo para la industria que pueda crear el archivo MBean
JAR para nosotros.

El proyecto Maven

No hay El plugin WebLogic MBeanMaker en nuestra aplicación y también la

herramienta existente no es realmente compatible con Maven.

Propina
WebLogic MBeanMaker

Esta es una utilidad de línea de comandos que genera todos los archivos que necesita para
formar un Tipo MBean , desde clases parciales de Java hasta interfaces de contrato y
algunos archivos personalizados utilizados por WebLogic para introspectar el MBean una
vez que se implementa en JAR dentro del cargador de clases del sistema.

Lo que haremos es una integración de las tecnologías existentes en Maven

utilizando el maven-antrun-pluginplugin como un puente entre estos dos
mundos. Estas tecnologías son tan invasivas que tendremos que desactivar
algunos plugins Maven estándar y comunes como maven-jar-plugin y maven-
install-plugin. En cierto sentido, el trabajo del plugin de compilación se
realizará con esta pieza de la antigua tecnología BEA.

Pero todo esto tiene sentido si queremos tener una pieza de software que pueda
integrarse en los sistemas de compilación modernos, y si queremos tener un
buen entorno de desarrollo donde podamos trabajar en un ciclo de vida de
ejecución de escritura.

Creando el proyecto Maven

Comenzaremos de manera simple, con el El POM de Maven más corto y simple que

podemos tener, como se muestra en el siguiente fragmento de código:

Dupdo

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>net.lucamasini.security</groupId>
<artifactId>chapter-4-auth-provider</artifactId>
<version>1.0-SNAPSHOT</version>

</project>

Aquí, no especificamos un POM padre y dejamos el empaque estándar JARtal como está,

incluso si Maven no lo gestiona, porque WebLogic MBeanMaker lo hará directamente. No

vamos a especificar, aquí, todas las propiedades que se necesitan porque so n demasiadas

y se introducirán progresivamente a medida que avancemos con este capítulo.

Dependencias

Nuestros proyectos necesitan algunas dependencias de los binarios de WebLogic para

compilar. Los diferentes binarios que se deben agregar se explican en los siguientes pasos:

1. Primero, debemos agregar el JAR que contiene la API de seguridad WebLogic

personalizada de nuestro MBean, como se muestra en el siguiente fragmento de

código:

Dupdo

<dependency>
<groupId>com.bea.core</groupId>
<artifactId>commons.security.api</artifactId>
<version>1.1.0.0_6-2-0-0</version>
<scope>system</scope>
<systemPath>
${middleware.home}/modules/
com.bea.core.common.security.api_1.1.0.0_6-2-0-0.jar
</systemPath>
</dependency>

2. Luego, necesitamos agregar un JAR que contenga las clases que usaremos en

nuestro LoginModule ( WLSUsery WLSGroup), como se muestra en el siguiente

fragmento de código:

Dupdo

<dependency>
<groupId>com.bea.core</groupId>
<artifactId>weblogic.security</artifactId>
<version>1.1.0.0_6-2-0-0</version>
<scope>system</scope>
<systemPath>
${middleware.home}/modules/
com.bea.core.weblogic.security_1.1.0.0_6-2-0-0.jar
</systemPath>
</dependency>
 3. Finalmente, necesitamos el mega JAR de WebLogic, donde se encuentran la

mayoría de las clases utilizadas; se puede agregar usando el siguiente código:

Dupdo

<dependency>
<groupId>oracle</groupId>
<artifactId>weblogic</artifactId>
<version>${weblogic.version}</version>
<scope>system</scope>
<systemPath>
${middleware.home}/wlserver/server/lib/weblogic.jar
</systemPath>
</dependency>

4. Como puede ser visto desde esta primera pieza de POM, necesitamos agregar dos

propiedades; uno de ellos apunta a la instalación de WebLogic, como se muestra en

el siguiente código:

Dupdo

<middleware.home>/path/to/wls1211_dev</middleware.home>

5. La otra es la versión que estamos desarrollando, como se muestra en el siguiente

código:

Dupdo

<weblogic.version>12.1.1.0</weblogic.version>

Reconfigurar plugins estándar

Otro paso fácil es reconfigure algunos plugins comunes de Maven, como la compilación y

los recursos. Dentro de<build> etiqueta, agregamos el siguiente código:

Dupdo

<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.0.2</version>
<configuration>
 <encoding>UTF-8</encoding>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.5</version>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
<executions>
<execution>
<id>default-install</id>
<phase>install</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>
${domain.dir}/lib/mbeantypes
</outputDirectory>
<resources>
<resource>
<directory>
${project.build.directory}
</directory>
<includes>
<include>
${project.build.finalName}.jar
</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>

Aquí, configuramos UTF-8 como codificación estándar para que sea independiente de la

plataforma (recuerde configurar su editor de código fuente) y

configuramos source/ targetversión para eljavaccompilador. Por supuesto, necesitamos

definir las siguientes dos nuevas propiedades:

Dupdo

<maven.compiler.source>1.6</maven.compiler.source>
<maven.compiler.target>1.6</maven.compiler.target>
Como ahora explicado, el MBeanMaker de WebLogic se encarga de empaquetar el artefacto

creado, por lo que debemos deshabilitar el estándar maven-jar-pluginenchufar. Además,

el objetivo de instalación listo para usar no tiene ningún sentido en este entorno, por lo que

configuramos una ejecución ad hoc maven-resources-pluginque mueve el archivo JAR

generado dentro de la carpeta correcta, por lo que también podemos desactivar el

estándarmaven-install-plugin complemento, como se muestra en el siguiente

fragmento de código:

Dupdo

<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
</plugin>

Podemos ver que para desactivar uno de los plugins estándar de Maven, todo lo que

tenemos que hacer es vincular su ID de ejecución interna a la nonefase de ejecución.

El installcomplemento se reemplaza por la default-installejecución de maven-

resources-plugin, donde le decimos que mueva el lib/mbeantype archivo JAR

generado dentro de la carpeta del dominio de WebLogic , que es la carpeta predeterminada

para Proveedores personalizados. Para eso tenemos que definir una nueva propiedad, como

se muestra en el siguiente fragmento de código:

Dupdo
<domain.dir>/path/to/your/domain</domain.dir>

La ruta debe apuntar a la carpeta donde creamos el dominio de desarrollo.

Ahora otro plugin, esta vez es un plugin personalizado del proyecto Mojo de Codehaus, uno

que hace algo que Maven debería hacer por sí mismo: agregar otra carpeta fuente.

Muy a menudo tiene más de un lugar donde sourcesse colocan porque uno de ellos fue

escrito por un desarrollador y los otros se generaron automáticamente. Este tipo de

configuración no es posible utilizando el conjunto estándar de complementos de

Maven. Afortunadamente, este simple complemento que hace muchas otras cosas

interesantes, nos permite agregar otras carpetas como sourcecarpetas. Este complemento

se utiliza en el siguiente fragmento de código:

Dupdo

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${generated.sources.dir}</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>

La ejecución del add-sourceobjetivo está ligada a la generate-sourcesfase para que

todo sea coherente dentro de esta configuración POM. Que

es ${generated.sources.dir} ? Es una propiedad nueva, definida de la siguiente

manera:

Dupdo
<generated.sources.dir>
${project.build.directory}/generated-source
</generated.sources.dir>

Es el destino donde le diremos a WebLogic MBeanMaker que escriba sus clases

personalizadas generadas.

La última tarea simple que haremos dentro de este POM es habilitar el filtrado de

recursos. De nuevo dentro de la <build>etiqueta, agregamos el siguiente código:

Dupdo

<resources>
<resource>
<filtering>true</filtering>
<directory>src/main/resources</directory>
</resource>
</resources>

Agregar WebLogic MBeanMaker al POM

MBean de WebLogic es una antigua tecnología patentada por BEA y se basa en lo

siguiente:

 Un archivo de definición de XML MBean

 Un conjunto de API

 Un generador que, en dos pasos, genera el MBean que ejecuta

nuestro LoginModule y luego lo empaqueta para su implementación en WebLogic

como un Proveedor de autenticación.

Dicho esto, es una pieza de software realmente antigua y está ligada a WebLogic y su

entorno de desarrollo personalizado, basado en API y API propietarias. La integración con

Maven es posible de las dos maneras siguientes:

 La ruta principal: escribir un complemento personalizado que utiliza la utilidad de

Oracle y también configura la fase de ejecución

  Déjalo pensar: engañar a MBeanMaker para que piense que se está ejecutando

dentro de Ant usando el mave-antrun-plugin enchufar

Por supuesto, la primera es una mejor solución que nos puede ahorrar mucho tiempo

configurando el POM, pero necesita tener algo de tiempo para escribirlo y mantenerlo

durante un período prolongado y en diferentes versiones de WebLogic.

Usar la última solución en su lugar es mucho menos elegante porque necesitamos escribir

alguna configuración antigua de Ant XML. Pero de esta manera es muy fácil integrarlo con

Maven.

Dicho esto, exploraremos la segunda solución y configuraremos Ant para que ejecute el

generador para nosotros. Lo primero que debe hacer es configurar el complemento y sus

dependencias, como se muestra en el siguiente fragmento de código:

Dupdo

<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.3</version>
<dependencies>
<dependency>
<groupId>weblogic</groupId>
<artifactId>weblogic</artifactId>
<version>${weblogic.version}</version>
<scope>system</scope>
<systemPath>
${middleware.home}/wlserver/server/lib/weblogic.jar
</systemPath>
</dependency>
</dependencies>
<executions>
…
…

Luego lo haremos codifica las dos executionetiquetas Primero, se lee el archivo de

definición MBean y luego se crean los archivos intermedios, como se muestra en el

siguiente fragmento de código:

Dupdo

<execution>
<id>generate-mbean</id>
 <phase>process-resources</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<java fork="true"
classname="weblogic.management.commo.WebLogicMBeanMaker"
classpathref="maven.plugin.classpath">
<jvmarg
value="-DMDF=${project.build.outputDirectory}/
PacktSiteUsersAuthentication.xml" />
<jvmarg
value="-Dfiles=${project.build.outputDirectory}" />
<jvmarg value="-DcreateStubs=true" />
<jvmarg value="-Dverbose=true" />
</java>
</tasks>
</configuration>
</execution>

Aquí, lanzamos el MBeanMaker de WebLogic diciéndole que analice el archivo XML dentro

de la carpeta de salida. Esto funciona porque vinculamos esta ejecución con el process-

resourcesy así podemos estar seguros de quemaven-resources-pluginfiltró nuestros

recursos y los colocó dentro de la carpeta de salida configurada. También le decimos que

coloque los archivos intermedios dentro de la carpeta de salida y eventualmente sobrescriba

los apéndices existentes (no en nuestro caso porque estamos usando una carpeta

generada). Finalmente, habilitamos el modo detallado para mostrar cualquier información

importante en caso de que los necesitemos.

En el segundo execution, los archivos intermedios y el código del desarrollador se

compilan y empaquetan como un MBean, como se muestra en el siguiente fragmento de

código:

Dupdo

<execution>
<id>generate-jar</id>
<phase>compile</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<java fork="true"
 classname="weblogic.management.commo.WebLogicMBeanMaker"
classpathref="maven.plugin.classpath">
<jvmarg value="-DMJF=${jar.file}" />
<jvmarg value="-Dfiles=${project.build.outputDirectory}" />
<jvmarg value="-DcreateStubs=true" />
<jvmarg value="-DpreserveStubs=true" />
<jvmarg value="-Dverbose=true" />
<arg value="-preserveStubs" />
</java>
<move
todir="${generated.sources.dir}/${package.dir}"
file="${project.build.outputDirectory}/
PacktSiteUsersAuthenticationImpl.java" />
<move todir="${generated.sources.dir}">
<fileset
dir="${project.build.outputDirectory}">
<include name="**/*.java" />
</fileset>
</move>
</tasks>
</configuration>
</execution>

Por supuesto, aquí necesitamos definir dos nuevas propiedades de Maven; los primeros

puntos del archivo JAR que queremos que se generen, como se muestra en el siguiente

fragmento de código:

Dupdo

<jar.file>
${project.build.directory}/${project.build.finalName}.jar
</jar.file>

El segundo se usa para preservar la estructura del paquete durante la tarea de movimiento,

como se muestra en el siguiente código:

Dupdo

<package.dir>
net/lucamasini/security
</package.dir>

Maven la configuración ahora está completa. Este POM se puede utilizar como una plantilla

para cada Proveedor de autenticación que tenemos que hacer, y podemos proceder a la

implementación central del MBean, comenzando con su definición XML.

Definiendo el MBean con un archivo MDF

El central El punto de nuestra iteración de desarrollo es el archivo MDF, donde definimos el

MBean que es un contenedor de LoginModule, que implementaremos. Este es un XML

personalizado y necesita el commo.dtdarchivo que se puede encontrar dentro de la

instalación de WebLogic (debajo de la $MW_HOME/wl_server/server/lib carpeta) y

copiarlo dentro de la src/main/resources carpeta de su proyecto, ya que de ahora en

adelante se usará como referencia el SYSTEMtipo de documento, como se muestra en

siguiente fragmento de código:

Dupdo

<?xml version="1.0" ?>

<!DOCTYPE MBeanType SYSTEM "commo.dtd">

Por supuesto, la etiqueta principal se nombra MBeanTypey define cómo se generará la clase

MBean; el MBeanTypese define de la siguiente manera:

Dupdo

<MBeanType
Name = "PacktSiteUsersAuthentication"
DisplayName = "PacktSiteUsersAuthentication"
Package = "net.lucamasini.security"
Extends =
"weblogic.management.security.authentication.Authenticator"
PersistPolicy = "OnUpdate"
>

Cada atributo de esta etiqueta es muy importante, comenzando con el nombre que se usará

para definir un nuevo tipo de esquema XML para el espacio de nombres de seguridad dentro

de la WebLogic. config.xml archivo, como se define en el siguiente fragmento de código:

Dupdo

<sec:authentication-provider
xmlns:ext="http://xmlns.oracle.com/weblogic/security/extension"
xsi:type="ext:packt-site-users-authenticationType">
<sec:name>packt</sec:name>
<sec:control-flag>OPTIONAL</sec:control-flag>
</sec:authentication-provider>
Aquí, podemos ver que xsi:typees el nombre de MBean rebajado, con un -signo entre

minúsculas y con Typeun sufijo.

El DisplayNameatributoen su lugar se usa dentro de la consola de WebLogic y eso es lo

que vemos en el menú desplegable cuando agregamos un nuevo Proveedor de

autenticación.

Packagees el paquete de Java de los artefactos generados y Extendses el MBean estándar

que decidimos

extender- weblogic.management.security.authentication.Authenticator cuando

desarrollamos un Proveedor de autenticación.

El último atributo- PersistPolicy = "OnUpdate" indica que se generará un MBean que

se escribirá en el archivo de almacenamiento (generalmente el config.xml) cada vez que

se modifique uno de sus atributos.

Finalmente, podemos ejecutar una mvninstalación para generar nuestro Proveedor de

Autenticación, como se muestra en el siguiente comando:

Dupdo

mvn install

Este proveedor es todavía no es un proveedor que funciona, pero podemos echar un vistazo

a lo que vamos a construir.

Se puede instalar bajo la consola de WebLogic, pero luego WebLogic se negará a comenzar

con un [Security: 097533] Nombre de la clase de servicio SecurityProvider para

PackProvider no se ha especificado el mensaje de error porque aún no hemos

configurado el MDF, y tampoco hemos escrito el implementación de nuestro MBean. Pero,

aparte de esto, WebLogic sabe lo que acabamos de generar y trata de usarlo (si está

entrando en pánico sobre su dominio WebLogic, simplemente elimine la sec:sección dentro

del config.xmlarchivo).
Mirando dentro de la carpeta de destino, podemos observar una clase especial en

el weblogic.management.security paquete; en nuestra muestra se

nombrará CHAPTER4_AUTH_PROVIDER_1_0_SNAPSHOT1345106773809855000BeanInfoF

actory. Se denomina con el nombre del archivo MBean JAR junto con la hora actual en
milisegundos, que es diferente cada vez que hacemos la instalación (para eso siempre

recuerde hacer una limpieza antes de la instalación). Esta clase es una fábrica que, dada la

interfaz, hace referencia a la BeanInfoclase estándar de JavaBean de nuestra

implementación MBean.

Podemos continuar escribiendo nuestro MDF y agregando la configuración de

la ProviderClassName siguiente manera:

Dupdo

<MBeanAttribute
Name = "ProviderClassName"
Type = "java.lang.String"
Writeable = "false"
Default = "&quot;net.lucamasini.security.PacktAuthProviderImpl&quot;"
/>

Tenga en cuenta que necesitamos usar la &quot;entidad XML porque

el ProviderClassNameatributonecesita un valor entre comillas, pero ahora los usa el

archivo XML.

Si no, cuando relanzamos la instalación e iniciemos WebLogic, recibiremos un mensaje de

error completamente diferente- [Seguridad: 097534] Error al obtener una instancia de la

clase net.lucamasini.security.PacktAuthProviderImpl . Esto se debe a que ahora hemos

especificado qué clase será nuestra implementación de MBean y WebLogic intenta crear

una nueva instancia de una clase que aún no existe.

Los siguientes dos atributos que vamos a agregar son los que el administrador de WebLogic

verá cuando configure el proveedor; estos atributos son los siguientes:

Dupdo

<MBeanAttribute
Name = "Description"
Type = "java.lang.String"
Writeable = "false"
Default = "&quot;WebLogic Packt Authentication Provider&quot;"
/>

<MBeanAttribute
Name = "Version"
Type = "java.lang.String"
Writeable = "false"
Default = "&quot;1.0&quot;"
/>

En descriptiony version, podemos agregar lo que prefiramos; estas son dos cadenas

informativas y podemos verificar esto en la MBeanImplBeanInfoclase buscando estas dos

propiedades.

Finalmente, agregamos una propiedad de configuración real, la URL que usará nuestro

proveedor para interactuar con nuestro sistema SSO heredado, como se muestra en el

siguiente código:

Dupdo

<MBeanAttribute
Name = "URL"
Type = "java.lang.String"
Writeable = "true"
Default = "&quot;${authentication.services.url}&quot;"
/>

en un De manera diferente a los otros atributos, esto también se puede escribir usando la

consola (o directamente en el config.xmlarchivo) por nuestro administrador del

sistema. No estamos codificando el URL dentro del archivo MDF, sino usando el filtrado de

recursos de Maven para poder configurar este parámetro dentro de nuestro POM, tal vez

con diferentes valores entre nuestros entornos (desarrollo, escenario y producción).

Por supuesto, nuestro POM debe estar enriquecido con la siguiente propiedad nueva:

Dupdo

<authentication.services.url>
http://localhost:8080/sso.jsp
</authentication.services.url>
Nuestra configuración de archivos MDF está completa. Ahora podemos codificar la clase de

implementación de delegados de MBean.

Escribir la implementación de
MBean

Cada El proveedor de autenticación debe implementar

la weblogic.security.spi.AuthenticationProviderV2 interfaz, que es el contrato
real entre los servicios de seguridad de WebLogic y nuestra implementación,
como se muestra en el siguiente fragmento de código:

Dupdo

public class PacktAuthProviderImpl implements AuthenticationProviderV2

{
private static final Logger LOGGER =
Logger.getLogger(PacktAuthProviderImpl.class.getSimpleName());

@Override
public void initialize(ProviderMBean mbean, SecurityServices services) {
LOGGER.info("PacktAuthProviderImpl.initialize");
}

@Override
public String getDescription() {
return null;
}

@Override
public void shutdown() {
LOGGER.info("PacktAuthProviderImpl.shutdown");
}

@Override
public AppConfigurationEntry getLoginModuleConfiguration() {
return null;
}

@Override
public AppConfigurationEntry getAssertionModuleConfiguration() {
return null;
}
 @Override
public PrincipalValidator getPrincipalValidator() {
return null;
}

@Override
public IdentityAsserterV2 getIdentityAsserter() {
return null;
}
}

Y sí, ahora puede instalar y configurar el proveedor en su dominio; Verás la

siguiente línea de registro:

Dupdo

net.lucamasini.security.PacktAuthProviderImpl initialize
INFO: PacktAuthProviderImpl.initialize

No es mucho, pero significa que nuestra configuración e infraestructura está

funcionando bien. A partir de ahora, finalmente, realmente codificaremos allí,
dando un comportamiento a la PacktAuthProviderImpl clase que WebLogic
ahora sabe que es un proveedor personalizado.

Inicializando el proveedor

Cada marco tiene su propio ciclo de vida, y cada ciclo de vida tiene un comienzo y un

final. Para AuthenticationProviderV2 estos son los métodos de devolución de

llamada initializeyshutdown, donde no solo podemos crear instancias de nuestros

objetos personalizados sino también obtener la configuración del MBean que envuelve

nuestra clase y se comunica con la consola. En esta implementación simple, no

necesitamos hacer nada dentro shutdown, por lo que dejaremos el actual que registra una

línea cuando se llama.

En cambio, se debe hacer mucho dentro del initializemétodo, donde recibimos la

instancia de MBean y el Servicio de seguridad, que es nuestro contenedor real. Lo primero

que debemos hacer es enviar el genérico ProviderMBeana nuestro MBean personalizado

para que podamos usar nuestros atributos específicos, de la siguiente manera:

Dupdo

PacktSiteUsersAuthenticationMBean myMBean =
(PacktSiteUsersAuthenticationMBean) mbean;

Ahora que tenemos nuestra instancia específica, podemos guardar la configuración para su

uso posterior con el siguiente fragmento de código:

Dupdo

description = myMBean.getDescription() + "\n" + myMBean.getVersion();

url = myMBean.getURL();

Aquí descriptiony urlhay dos campos de cadena de instancia. También tenemos que

guardar una instancia de AppConfigurationEntry.LoginModuleControlFlag , que es

una versión de JAAS de un tipo de enumeración (estilo antiguo de Java) que nos dice si

nuestro proveedor de seguridad es obligatorio o no. Esto puede hacerse de la siguiente

manera:

Dupdo

String flag = myMBean.getControlFlag();

try {
controlFlag =(AppConfigurationEntry.LoginModuleControlFlag)
AppConfigurationEntry.LoginModuleControlFlag.class.getField(flag).get(null);
} catch (Exception e) {
throw new IllegalArgumentException("invalid flag value" + flag,e);
}

En esto primera etapa, podemos imprimir la salida de configuración en el registro del

servidor de WebLogic para que podamos estar seguros de que llamamos al parámetro

correcto y nuestro código de análisis simple funciona bien. Usa el siguiente código:

Dupdo

LOGGER.info("ControlFlag: "+controlFlag);
LOGGER.info("Description: "+description);
LOGGER.info("URL: "+url);

Deberíamos ver algo como lo siguiente:

Dupdo

INFO: ControlFlag: LoginModuleControlFlag: optional

INFO: Description: WebLogic Packt Authentication Provider
1.0
INFO: URL: http://external-user.intra.net/checkUserLogin

Implementación del proveedor

Nuestra la implementación está casi terminada; ahora necesitamos implementar el método

restante,getDescription . Esto es bastante sencillo, como se muestra en el siguiente

código:

Dupdo

@Override
public String getDescription() {
return description;
}

Mientras getIdentityAsserter continuará devolviendo nulo (ya que estamos codificando

un Proveedor de autenticación), aún necesitamos implementar el Validador principal, y para

eso podemos usar un validador integrado que viene con WebLogic, como se muestra en el

siguiente fragmento de código:

Dupdo

@Override
public PrincipalValidator getPrincipalValidator() {
return new
weblogic.security.provider.PrincipalValidatorImpl();
}

Finalmente, el configuración de JAAS LoginModule , que realmente hará la

autenticación. No usaremos ningún estándar LoginModule , sino que usaremos el nuestro:

Dupdo

@Override
public AppConfigurationEntry getLoginModuleConfiguration() {
return new AppConfigurationEntry(
"net.lucamasini.security.PacktLoginModuleImpl",
 controlFlag,
new HashMap<String, Object>() {{
put("url", url);
}}
);
}

@Override
public AppConfigurationEntry getAssertionModuleConfiguration() {
return getLoginModuleConfiguration();
}

Ahora podemos instalar e iniciar WebLogic. Extrañamente, no se quejará del hecho de que

la PacktLoginModuleImpl claseEstá perdido; simplemente ignorará este proveedor de

autenticación durante el proceso de inicio de sesión. Esto puede verse como un error, pero

es una práctica buena y conservadora, y en caso de que deseemos / necesitemos verificar

si nuestra configuración se ha leído correctamente, siempre podemos habilitar el indicador

de depuración atn yendo a weblogic.security.atn en la consola o el script de inicio y

busque PacktLoginModuleImpl .

Custom Login MODO de JAAS

Por suerte, LoginModule utiliza una API JAAS estándar y, como tal, está bien
documentada en muchos libros y en Internet. Aquí, vamos a escribir el más
simple LoginModuleque resuelve nuestro problema de validación de los
principales sobre un sistema SSO externo heredado que utiliza el protocolo
HTTP. Como ayuda didáctica, también escribiremos en el registro cuando el
contenedor de Servicios de seguridad llamará a nuestro método para que
podamos averiguar cuándo y cuántas veces se llaman.

Tenga en cuenta que LoginModulees un Bean con estado; debe retener los datos
de configuración cuando se inicializa, y desde el estado de devolución de
llamada al estado de confirmación (o abortar o lo que sea) debe mantener el
estado para responder de una manera correcta y esperada.
Comencemos con la definición; los campos de instancia se declararán como y
cuando los necesitemos. El código para nuestra costumbre LoginModule es como
sigue:

Dupdo

public class PacktLoginModuleImpl implements LoginModule {

private final static Logger LOGGER = Logger.
getLogger(PacktLoginModuleImpl.class.getSimpleName());

private Subject subject;

private CallbackHandler callbackHandler;
private String url;

public void
initialize( Subject subject, CallbackHandler callbackHandler, Map
sharedState, Map options )
{
LOGGER.info("PacktLoginModuleImpl.initialize");

this.subject = subject;
this.callbackHandler = callbackHandler;
this.url = options.get("url").toString();
}

Aquí simplemente imprimimos la información de registro que LoginModuleindica

que se ha creado una nueva instancia y guardamos la información necesaria
para el proceso de autenticación, que se explica de la siguiente manera:

 subject: Este es el tema actual que enriqueceremos con nuestros directores en

caso de un inicio de sesión exitoso

 callbackhandler : Este es nuestro proveedor oficial de credenciales para

autenticar al usuario (en este ejemplo, usaremos el par canónico, la combinación de

nombre de usuario y contraseña)

 url: Esta es nuestra propia configuración, la URL del sistema SSO heredado

El método de inicio de sesión ()

Después de haber inicializado correctamente el objeto, podemos esperar que el contenedor

llame al login()método para darnos la oportunidad de autenticación. Usa el siguiente

código:

Dupdo

public boolean login() throws LoginException {

LOGGER.fine("PacktLoginModuleImpl.login");

Como dijimos, decidimos registrar todas nuestras llamadas a este método LoginModule ,

pero lo primero que debemos hacer es definir qué Callbackmétodos nos darán la

información correcta para aceptar o rechazar la identidad del usuario, como se muestra en el

siguiente fragmento de código :

Dupdo

Callback[] callbacks = new Callback[]{

new NameCallback("username: "),
new PasswordCallback("password: ", false)
};

try {
callbackHandler.handle(callbacks);
} catch (Exception e) {
LOGGER.throwing("PacktLoginModuleImpl", "login", e);
throw new LoginException(e.getMessage());
}

Aquí definimos dos Callbackmétodos, uno que pedirá al sistema un nombre de usuario y

otro la contraseña, y luego usaremos la callbackHandlerinterfaz que guardamos durante

el estado de inicialización para completarlos, de modo que podamos extraer lo que

necesitamos, como se muestra en el siguiente código:

Dupdo

PasswordCallback passwordCallback = (PasswordCallback) callbacks[1];

char[] passwordChars = passwordCallback.getPassword();
passwordCallback.clearPassword();
final String password = new String(passwordChars);

Aquí, borramos el PasswordCallbackestado interno después de obtener la contraseña, ya

que siempre es una buena práctica no almacenar información confidencial en el montón

(todas nuestras variables son de generación joven y se guardarán después de la llamada al

método).

Habiendo recuperado el nombre de usuario y la contraseña, ahora podemos llamar al

sistema heredado como se muestra en el siguiente código:

Dupdo

if (userName != null && password != null && userName.length() > 0 &&

password.length() > 0)
{
checkUsernameAndPassword(userName, password);
} else {
throw new LoginException("username and/or password cannot be null");
}

Lanzamos LoginExceptionsi nuestras credenciales necesarias son nulas o si el sistema

SSO no puede validar a nuestro usuario. Si todo está bien, podemos declarar un inicio de

sesión exitoso y guardar nuestros principios para uso posterior, como se muestra en el

siguiente fragmento de código:

Dupdo

loginSucceeded = true;

principalsForSubject.add(new WLSUserImpl(userName));
principalsForSubject.add(new WLSGroupImpl("Packt"));

return loginSucceeded;
}

Aquí principalsForSubject y loginSucceeded hay dos campos declarados de la

siguiente manera:

Dupdo

private boolean loginSucceeded;

private List<Principal> principalsForSubject = new ArrayList<Principal>();

Métodos del ciclo de vida: commit (), abort () y

logout ()
Ahora, necesitamos implemente los métodos restantes commit, aborty logout, cuidando

el comportamiento esperado por el cliente de la LoginModule interfaz (puede leer más

sobre esto en http://docs.oracle.com/javase/6/docs/technotes/guides/security/ jaas /

JAASLMDevGuide.html # commit ).

El comportamiento externo esperado para el commit método es el siguiente:

login()/commit() Éxito Fracaso

Éxito regreso true arrojar excepción

Fracaso regreso false regreso false

Guardamos el resultado de la login()método en loginSucceeded . Siempre debemos

devolver falseen caso de un inicio de sesión fallido y devolver lo truecontrario (este

método simple no puede fallar en el caso de un inicio de sesión exitoso, por lo que

eliminamos throw LoginException la firma del método), como se muestra en el siguiente

fragmento de código:

Dupdo

@Override
public boolean commit() {
LOGGER.info("PacktLoginModuleImpl.commit");
if (loginSucceeded) {
subject.getPrincipals().addAll(principalsForSubject);
principalsInSubject = true;
return true;
} else {
return false;
}
}

Necesitamos guardar el hecho de que el commitmétodo fue exitoso en

el principalsInSubject campo local para que podamos reaccionar adecuadamente en

caso de abort().

Por el abort()método debemos distinguir cuándo se llama después de un inicio de sesión

exitoso, como se muestra en la siguiente tabla:

 commit()/abort() Éxito Fracaso

Éxito regreso true arrojar excepción

Fracaso regreso true arrojar excepción

O después de un inicio de sesión fallido, de la siguiente manera:

commit()/abort() Éxito Fracaso

Éxito regreso false regreso false

Fracaso regreso false regreso false

El siguiente código muestra una implementación simple ya que abort()no puede fallar:

Dupdo

@Override
public boolean abort() {
LOGGER.info("PacktLoginModuleImpl.abort");
if( !loginSucceeded ) {
return false;
}
if (principalsInSubject) {
subject.getPrincipals().
 removeAll(principalsForSubject);
principalsInSubject = false;
}
return true;
}

Finalmente, necesitamos implementar logout() como se muestra en el siguiente fragmento

de código:

Dupdo

@Override
public boolean logout() throws LoginException {
LOGGER.info("PacktLoginModuleImpl.logout");
if( principalsInSubject ) {
if( !subject.isReadOnly() ) {
subject.getPrincipals().removeAll(principalsForSubject);
} else {
for(Principal principal: principalsForSubject ) {
if( principal instanceof Destroyable ) {
try {
((Destroyable)principal).destroy();
 } catch (DestroyFailedException e) {
LOGGER. throwing("PacktLoginModuleImpl", "logout", e);
throw new LoginException("cannot destroy principal " +
principal.getName());
}
} else {
throw new LoginException("cannot destroy principal
"+principal.getName());
}
}
}
}
return true;
}

Como podemos ver en el código anterior, la implementación debe eliminar o destruir los

principales dentro de los Subjectobjetos asociados que fueron creados por

este LoginModule, teniendo cuidado de no tocar los principales agregados por otros

módulos, y finalmente señalar su falla de borrarlos con una LoginException excepción .

Podemos hacer una instalación limpia nuevamente de vez en cuando, nuestro proveedor de

autenticación está listo para usar.

Un SSO simple JSP

Antes de que podamos ejecutar nuestro Proveedor, tenemos que emular el sistema de SSO

heredado. Hacemos esto ahora con un JSP simple, como se muestra en el siguiente

fragmento de código:

Dupdo

<%@ page contentType="text/plain;charset=UTF-8" language="java" %><%

if( "testuser".equals(request.getParameter("username")) &&
"testpassword".equals(request.getParameter("password"))) {
response.setStatus(200);
} else {
response.setStatus(401);
}
%>

Para este ejemplo, podemos implementarlo dentro de la webapps/ROOTcarpeta de cualquier

servidor Tomcat que se ejecute en el puerto 8080 . En caso de que use otro puerto (o para
agregar una ruta de contexto), la authentication.services.urlpropiedad debe ser

actualizado

Ejecutando el proveedor

Ahora podemos ejecute el proveedor llamando al servlet que escribimos en la chapter3-

webcarpeta usando http://localhost:7001/chapter3-web/myprotectedresource .

Se nos pedirá el nombre de usuario y la contraseña, y después de

ingresar testusery, testpassword respectivamente, recibiremos un error que nos indicará

que el usuario actual no tiene suficientes privilegios para ejecutar el método EJB. Se

mostrará el siguiente mensaje de error:

Dupdo

[EJB:010160]Security violation: User testuser has insufficient permission to

access EJB type=<ejb>, application=chapter3-ear, module=/chapter3-web,
ejb=NoInterfaceBeanInWarModule, method=echo, methodInterface=Local,
signature={java.lang.String}.

Esto no es un error sino un efecto deseado; es solo que nuestro testuserno tiene derecho

a llamar al método EJB. En caso de que desee ver que una ejecución funciona bien,

simplemente puede comentar la ejecución del EJB en el servlet, como se muestra en el

siguiente código:

Dupdo

//resp.getWriter().println("echo:"+service.echo("echo"));

Alternativamente, modifique el EJB para que este usuario sea lo suficientemente potente

como para ejecutarlo. Es un buen ejercicio mapear un nuevo rol para el grupo que está

asociado con este usuario.

Si ahora miramos el registro de WebLogic, podemos ver que nuestros métodos de ciclo de

vida han sido correctamente llamados en el orden que esperábamos:

Dupdo
INFO: PacktLoginModuleImpl.initialize
INFO: PacktLoginModuleImpl.login
INFO: PacktLoginModuleImpl.commit

Resumen

En este capítulo aprendimos cómo codificar un proveedor de autenticación

utilizando la tecnología Maven y JAAS, desde cero, desde la creación del
proyecto, hasta la comprensión del archivo MDF, hasta la escritura del código
necesario. Con este conocimiento, también puede escribir un Asertivo de
Identidad o un Proveedor de Mapeo de Credenciales; solo necesita cambiar el
archivo MDF y la interfaz implementada por la clase Provider.

Capítulo 5. Integración con

Kerberos SPNEGO Identity
Assertion

Este capítulo cubre las configuraciones y los requisitos necesarios para

implementar el inicio de sesión único ( SSO)proceso de autenticación con
SPNEGO en su infraestructura. Este capitulo cubre los siguientes topicos:

 Uso de Identity Assertion SSO Kerberos en un dominio de Microsoft

 Configuración de Aserción de Identidad SPNEGO

Uso de Identity Assertion SSO
Kerberos en un dominio de
Microsoft

Asertividad de identidad es un mecanismo de proveedor que permite a los

usuarios confiar en su identidad utilizando un token almacenado en su máquina,
por el Mecanismo de Negociación Simple y Protegida ( SPNEGO ). Aquí, su
identidad se intercambia con el servidor por transacción HTTP en modo
silencioso (Single Sign-On) sin ingresar el nombre de usuario y la contraseña.

Puedes usar estas páginas para implemente su seguridad en un contexto

preexistente utilizando una arquitectura estructurada predefinida con usuarios y
grupos.

En nuestro caso, analizaremos una configuración de inicio de sesión único de

SPNEGO en un contexto de dominio de Microsoft utilizando el token nativo de
Kerberos y JVM JRockit de Oracle incrustado con el servidor de WebLogic.

El servidor WebLogic admite tokens de Kerberos incluso si lo instala en un

servidor que no está basado en Microsoft OS, por ejemplo, el sistema operativo
Linux. Esto se debe a que la relación de confianza será hecha por Oracle Capa
de seguridad del servidor WebLogic y no por el sistema operativo.

El cliente de Windows necesita estar en el

dominio de Active Directory

Antes de continuar, necesitamos verificar si su máquina es parte de un dominio de Active

Directory y verificar la configuración correcta en las propiedades de su computadora. Si

puede ver su nombre de dominio de Windows en la sección Dominio , usted es un

miembro. De lo contrario, el administrador debe sincronizar su computadora con el dominio

de configuración de destino.

La sesión del cliente de Windows debe

registrarse en el dominio de Active Directory

En el Windows de su cliente máquina, la fase de inicio de sesión en el dominio genera un

token Kerberos válido en caché con sus credenciales; puede verificar si el token se genera

correctamente con algunas herramientas potentes, que son muy útiles durante las sesiones

de diagnóstico.

Puede encontrar estas utilidades en el paquete de Herramientas del kit de recursos de

Windows Server 2003 y puede descargarlas desde el sitio de Microsoft

en http://www.microsoft.com/en-us/download/details.aspx?id=17657 .

Kerbtray es una herramienta de Microsoft gráfica y fácil de usar que mostrará una lista

detallada de sus tokens de Kerberos almacenados en la memoria caché con información

clave:

 Nombre del servicio: su nombre principal de servicio configurado

 Horario válido del boleto: fecha y hora de caducidad

 Tipo de cifrado: tipo de cifrado compatible

También puede usar esta herramienta para limpiar su caché de tokens local haciendo clic

derecho en el icono de la bandeja y seleccionando Opción Purgar tickets .

Klist es unlínea de comandos que le permitirá ver y limpiar sus cachés de tokens

locales; con este comando puede escribir fácilmente un comando por lotes para pilotar o

monitorear su token caché por un largo tiempo.

El siguiente comando redirige la salida a un archivo, para guardar el estado de su token:

Dupdo
klist > c:\token.list.txt

Autenticación de Windows integrada

Es muy importante verificar si esta configuración del navegador del cliente está

habilitada; sin esto, el proceso de inicio de sesión único no funcionará.

Para verificar su configuración, haga clic con el botón derecho en el ícono de Internet

Explorer en su escritorio y seleccione Propiedades . Vaya a la pestaña Avanzado y

desplácese hacia abajo a la sección Seguridad y marque Habilitar autenticación

integrada de Windows, si aún no está seleccionado.

Propina
Reiniciar el navegador de Internet Explorer

Si está utilizando un servidor proxy, asegúrese de que sus nombres de dominio locales
estén en el campo de excepciones; esto permite una conexión directa de cliente a servidor
sin pasar por un servidor proxy y preserva el token enviado.

Configuración de entrada de DNS DNS y

definición de SPN

Es esencial registrar un Registro DNS que se utilizará para acceder a la aplicación de inicio

de sesión único instalada en la instancia del servidor WebLogic.

Es aconsejable registrar todos los nombres de host en su escenario: nodos WebLogic (por

ejemplo, un dispositivo equilibrador de carga de red), nodos de servidor web y cualquier otra

IP virtual existente y asociada. Esta información nos permitirá registrar todos los nombres

principales del servicio ( SPN s), que están habilitados para marcar un acceso de inicio de
sesión único de confianza en su aplicación en cualquier nivel. Esto es poderoso cuando

necesita solucionar un problema.

La entrada de DNS puede proporcionarse con el servicio DNS interno de Active Directory, o

externamente con algún servidor DNS de dispositivo o algún servidor DNS compatible con el

estándar. El funcionamiento de todo el proceso se muestra en el siguiente diagrama:

Usuario de Active Directory

En el Active Directory lado, necesitamos crear un usuario técnico para asociar el nombre

principal del servicio; este usuario técnico es fundamental en la fase de verificación de

tokens.

Agregue un usuario de muestra al marcar las casillas de verificación El usuario no puede

cambiar la contraseña y La contraseña nunca caduca (deje cualquier otra configuración a

los valores predeterminados). Marque la casilla Usar tipos de cifrado DES de Kerberos

para esta cuenta en la pestaña Cuenta .

Propina
Marque esta opción solo si está usando Active Directory ejecutándose en Windows Server
2003.

Si está utilizando JVM 6 (o una versión posterior) y Windows Server 2008, no marque esta

opción; al hacerlo, podemos configurar el método de encriptación como RC4 HMAC. Este

tipo de cifrado no necesita ninguna otra configuración de usuario técnico de Active Directory.

Además, considere que Oracle certifica que los clientes de Internet Explorer 8.0 y FireFox

7.0.1, que acceden a las cuentas de usuario definidas en Active Directory y están cifrados

con los tipos AES-128, AES-256 o RC4, se ejecutarán en una plataforma Windows 7

Enterprise.

Cambiar el usuariocontraseña y recordarlo. Si cambia el tipo de encriptación, restablezca la

contraseña de usuario nuevamente.

Ahora necesitamos agregar nuestro nombre principal de servicio en este usuario; para

acceder a él debemos utilizar un usuario con privilegios de Active Directory, ya que pueden

editar servicios para nuestro usuario técnico.

Por ejemplo, considere la URL http://wls1.dom.int , que apunta a la IP configurada en

su instancia de servidor de WebLogic. Abra un comando de DOS con un usuario con

privilegios en una máquina de Windows en el dominio e ingrese el siguiente comando:

Dupdo

setspn -A HTTP/wls1 technicaluser

El comando anterior asocia la URL del servidor de WebLogic a nuestro usuario.

Dupdo
setspn -A HTTP/wls1.dom.int technicaluser

El comando anterior asocia la URL del Servidor WebLogic con el dominio completo

especificado para nuestro usuario.

De esta forma, ha habilitado la http://wls1.dom.intURL (y solo eso) para aceptar una

sesión de Kerberos y registrar cualquier otra URL.

Para verificar su entrada de usuario del Nombre principal de servicio registrado, use el

siguiente comando:

Dupdo

setspn -L technicaluser

Algunas reglas importantes al crear un usuario técnico con Active Directory son las

siguientes:

 Cree la entrada de DNS antes de configurar su nombre principal de servicio

 No asocie el mismo registro de Nombre de servicio principal a más de un usuario

técnico

 No defina ningún puerto TCP en el Nombre principal del servicio; un solo registro

puede cubrir cualquier puerto

 Cualquier cambio en el Nombre principal del servicio debe seguir la fase de

generación Keytab nuevamente (se explica en la siguiente sección)

Generación Keytab y archivo de configuración

krb5

Antes de continuar necesita tener un archivo de configuración de Kerberos local de acuerdo

con su configuración de Active Directory y Kerberos.

Verifique debajo ${java.home}/lib/security/krb5.conf o %windir%\krb5.ini.

Este archivo contiene una lista de parámetros importantes; el siguiente fragmento de código

muestra una sección de muestra de ese archivo:

Dupdo

[libdefaults]
default_realm = DOM.INT
ticket_lifetime=600
default_tkt_enctypes = rc4-hmac aes128-cts des3-cbc-sha1 des-cbc-md5 des-
cbc-crc
default_tgs_enctypes = rc4-hmac aes128-cts des3-cbc-sha1 des-cbc-md5 des-
cbc-crc
permitted_enctypes = rc4-hmac aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-
crc
[realms]
LOCAL.DOM.INT = {
kdc = dc0.local.dom.int:88
default_domain= DOM.INT
}
[domain_realm]
.dom.int = DOM.INT
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true

En una máquina Windows en el dominio con una instalación JDK (es mejor usar la misma

versión JDK que está instalada en el lado del servidor), use el siguiente comando en una

ventana DOS para generar un archivo Keytab:

Dupdo

c:\Programs\jdk1.6.0_02\bin\Ktab.exe –a technicaluser pwduser –k

keytabname.keytab

Con esto, se muestra el siguiente resultado:

Dupdo

Done!
Service key for technicaluser is saved in
c:\Programs\jdk1.6.0_02\bin\jdk1.6.0_02\bin\keytabname.keytab

Para verificar su archivo Keytab use el siguiente comando:

Dupdo
c:\Programs\jdk1.6.0_02\bin\klist.exe -e -f -t -K –k
c:\Programs\jdk1.6.0_02\bin\jdk1.6.0_02\bin\keytabname.keytab

La siguiente salida se mostrará en la ventana de la línea de comandos:

Dupdo

Key tab: c:\test.keytab, 5 entries found.

[1] Service principal: [email protected]
KVNO: 1
Key type: 17
Key: 0x8818f354b7c348bf234b95caffa9cdd
Time stamp: May 11, 2012 11:57
[2] Service principal: [email protected]
KVNO: 1
Key type: 16
Key: 0xec4f8cd12342223a2423425d7fa4e9fd
Time stamp: May 11, 2012 11:57
[3] Service principal: [email protected]
KVNO: 1
Key type: 23
Key: 0xd18a478dfcc5a1d2342311ac23165fa
Time stamp: May 11, 2012 11:57
[4] Service principal: [email protected]
KVNO: 1
Key type: 3
Key: 0x31d3b33132412222cfghb3e
Time stamp: May 11, 2012 11:57
[5] Service principal: [email protected]
KVNO: 1
Key type: 1
Key: 0x31d3b123412tffgb0cb3e
Time stamp: May 11, 2012 11:57

Mueva el archivo Keytab generado y copie el krb5.iniarchivo, ahora renombrado

a krb5.confen el servidor WebLogic, a la carpeta de dominio de inicio de WebLogic.

Propina
krb5.conf keytabname.keytab

Este archivo, en el lado del servidor, debe ser legible y accesible para el usuario que inicia el
servidor de WebLogic.

Cuando en su servidor utiliza una JVM con una versión superior a la 1.6 actualización 21,

tenga en cuenta que ahora se ha introducido un nuevo control de seguridad.

En pocas palabras, se verifica el número de KVNO y esto se incrementa cada vez que

cambia su contraseña en el KRDC. Cuando este número no coincide con el que tenemos en

la tabla de claves, se genera una excepción.

Tenemos las siguientes dos soluciones para resolver este problema:

1. Desactive esta comprobación configurando el número de KVNO en cero (usando

el ktpasscomando).

2. Recupere el número correcto de KVNO con la utilidad "kvno" y luego ejecute keytab

el número exacto de veces para permitir que el número aumente al mismo nivel.

Creación de archivos JAAS

Este es otro archivo importante que le dice al servidor de WebLogic que use el módulo de

inicio de sesión de Kerberos, donde se encuentran los archivos keytab, y también la ruta del

usuario técnico, con el nombre principal del servicio asociado.

Edite un archivo llamado krb5Login.conf y cópielo en el servidor de WebLogic en la

carpeta de inicio del dominio de WebLogic.

A continuación, una muestra la configuración en la que su servidor WebLogic utiliza Oracle

JVM versión 6 o superior se muestra en el siguiente fragmento de código:

Dupdo

com.sun.security.jgss.krb5.initiate {
com.sun.security.auth.module.Krb5LoginModule required
principal="[email protected]" useKeyTab="true"
keyTab="keytabname.keytab" storeKey="true" debug="false";
};
com.sun.security.jgss.krb5.accept {
com.sun.security.auth.module.Krb5LoginModule required
principal="[email protected]" useKeyTab="true"
keyTab="keytabname.keytab" storeKey="true" debug="false";
};
Propina
krb5Login.conf

Este archivo del lado del servidor debe ser legible y accesible para el usuario que inicia el
servidor WebLogic.

Configuración de argumentos de inicio WLS

init

Para activar nuestro Kerberos configuración, necesitamos especificar algunos argumentos

de inicio específicos; abra la consola de administración de WebLogic y vaya

al servidor | Comience Argumentos . Luego agrega lo siguiente:

Dupdo

-Djava.security.auth.login.config=krb5Login.conf
-Djavax.security.auth.useSubjectCredsOnly=false
-Dsun.security.krb5.debug=false
-Dweblogic.security.enableNegotiate=true
-Djava.security.krb5.conf=krb5.conf
-Dweblogic.wsee.component.exception=false
-DDebugSecurityAdjudicator=false

Después de esta modificación, debe reiniciar su nodo de servidor WebLogic; si tiene

múltiples nodos en su clúster, debe aplicar estos parámetros para cada uno de ellos.

Configuración de asertor de
identidad SPNEGO

Para encontrar SPNEGO Identity Assertion, vaya a la Consola de administración

y seleccione Security Realms | myrealm | Proveedores .

Haga clic en el botón Bloquear y Editar para bloquear y editar su dominio, pasar
al botón Nuevo (nombrar a su proveedor con una referencia personal) y
seleccionar el proveedor Negociar Aserción de Identidad de la lista y hacer clic
en Aceptar . Vuelva a ordenar la secuencia del proveedor en la parte superior
después de configurar LDAP (consulte el Capítulo 2 , Reino de seguridad de
WebLogic ). Después de todas estas modificaciones, reinicie todos los nodos de
su servidor WebLogic, junto con la consola de administración, para que sus
cambios sean efectivos.

Ahora su servidor WebLogic puede aceptar tokens Kerberos en una conexión

HTTP, y puede establecer una relación de confianza con su cliente cuando se
llama un nombre principal de servicio y la seguridad está habilitada en su
aplicación Java (consulte el Capítulo 3 , Seguridad Java EE Con WebLogic , de
este libro para asegurar su camino).

En el siguiente diagrama, puede ver una hoja de datos de esquemas de

autenticación sobre los actores de interacción:

Problemas de depuración

Si recibe un mensaje de error en el registro de WebLogic o si acaba de recibir un formulario

de autenticación básica cuando intenta acceder a un recurso protegido de la aplicación, es

probable que tenga un problema de configuración.

En primer lugar, puede conservar su configuración de producción sin tocarla e intentar hacer

un análisis del lado del cliente con un rastreador de red, por ejemplo, Wireshark. Deberá

verificar si se envía su token de Kerberos. Filtre su tráfico de red para los protocolos KRB5 y

utilizando el puerto TCP 88( puerto TCP predeterminado para comunicarse con el

controlador de dominio Kerberos), buscará algunos Operaciones de concesión de

tickets ( TGS ). Si no puede encontrar ningún rastro de estos tipos de paquetes, debe

mover su depuración en el servidor o seguir nuestra configuración previa de nuevo, paso a

paso.

Para depurar la configuración de su servidor, necesita aumentar su verbosidad de registro

utilizando algunos modificadores de depuración en el parámetro del nodo de su Servidor

WebLogic utilizando la ruta de la consola. Podemos hacer esto yendo primero a

la opción Servidores (su nombre de servidor) y luego

seleccionando Depurar | WebLogic | Seguridad y luego elegir las opciones

atn (autenticación) y atz (autorización).

Marque estas opciones, haga clic Enabley luego aplique sus cambios.

Ahora necesitamos cambie algunos parámetros para activar la máxima verbosidad para la

capa de seguridad, como se explica en los siguientes pasos:

1. Edita tu krb5Login.conf archivoy cambie el siguiente parámetro a true:

Dupdo

debug=true

2. Debajo de la consola de administración de WebLogic, en cada nodo de servidor que

desea depurar, en los argumentos de inicio debe cambiar sus debugparámetros de

la truesiguiente manera:

Dupdo

-Dsun.security.krb5.debug=true
-DDebugSecurityAdjudicator=true
 3. Después de esta reconfiguración, debe reiniciar los nodos del servidor WebLogic y

analizar los registros del servidor.

Nota
Esta configuración de depuración crea archivos de registro muy grandes; así que tenga
cuidado, el uso del espacio puede aumentar rápidamente.

Resumen

Este capítulo es una guía de configuración para comprender cómo funciona el

proceso de inicio de sesión de autenticación transparente (Single Sign-On) y qué
configuraciones se necesitan en su servidor WebLogic para integrarse con una
infraestructura Kerberos de Microsoft Active Directory.

Nos hemos centrado en los pasos clave a seguir para activar el acceso de
seguridad en los recursos de su aplicación web de una manera rápida y fácil.

Índice
UN
 Método abort () / Métodos del ciclo de vida: commit (), abort () y logout ()
 Contexto de Active Directory
o Opción de bloqueo de usuario / bloqueo de usuario en un contexto de Active
Directory
 Proveedor de Active Directory
o configuración / configuración específica del proveedor de Active Directory
 archivo application.xml
o sobre / Split deploy y beabuild-maven-plugin
 autenticación
o sobre / Autenticación bajo WebLogic
o LDAP externo, configurando / configurando un LDAP externo para
Autenticación / Autorización
 Propiedad authentication.services.url / A simple SSO JSP
 Proveedor de autenticación
o Acerca de / Proveedores de autenticación
o autenticación, bajo WebLogic / Autenticación bajo WebLogic
o JAAS / MBean y JAAS
o MBean / MBean y JAAS
o Proveedor de autenticación multiparte / Proveedor de autenticación
multiparte
o Autenticación Perimetral / Autenticación Perimetral
o configurar / configurar un nuevo proveedor
o inicializando / Inicializando el proveedor
o Implementación / Implementación del proveedor
o corriendo / ejecutando el proveedor
 autorización
o LDAP externo, configurando / configurando un LDAP externo para
Autenticación / Autorización

segundo
 Máquina virtual Java de 64 bits / Instalación del servidor WebLogic y el plugin Maven
de WebLogic
 Etiqueta <build> / Reconfiguración de complementos estándar
 opciones básicas, condición del rol de seguridad / Básico
 BasicPassword / Credential Mapper
 beabuild-maven-plugin
o sobre / Split deploy y beabuild-maven-plugin

do
 Método de compromiso / Métodos de ciclo de vida: commit (), abort () y logout ()
 archivo config.xml / Definición del MBean con un archivo MDF
 configuración, proveedor de Active Directory
o sobre / configuración específica del proveedor de Active Directory
o parámetros de conexión / conexión
o parámetros de usuario / usuarios
o Grupos parámetros / Grupos
o parámetros de grupos estáticos / Grupos estáticos
o sección de parámetros generales / General
 configurando
o Proveedor de autenticación / Configuración de un nuevo proveedor
o wls-maven-plugin, en EAR POM / Configurando wls-maven-plugin en EAR
POM
 parámetros de conexión
o sobre / Conexión
 Interfaz ConnectionSpec
o sobre / Credential Mapper
 ContextHandler object / Context element
  Parámetro de control de bandera
o sobre / Control Flag
 archivo create-roles.py / Bean empaquetado en el módulo WAR
 Credential Mapper
o sobre / Credential Mapper
 Asignación de roles personalizados
o sobre / asignación de roles personalizados

re
 Objeto DataSource
o sobre / los recursos de WebLogic
 dependencias, proyecto Maven / Dependencias
 DisplayName attribute / Definición del MBean con un archivo MDF
 Nombre distinguido (DN) / Conexión
 Dynamic Code Evolution VM (DCEVM) / Split deploy y beabuild-maven-plugin

mi
 OREJA POM
o wls-maven-plugin, configurando / configurando wls-maven-plugin en el EAR
POM
 EJB
o sobre / los recursos de WebLogic
o embalaje, en el módulo WAR / Bean empaquetado en el módulo WAR
 Componente EJB
o about / Un componente EJB RESTful y seguro
 Módulo EJB
o Asegurar / Asegurar el módulo EJB
 Clase EJBResource
o sobre / los recursos de WebLogic
 Recursos de Enterprise Information System (EIS) / WebLogic , Credential Mapper
 Proyecto Enterprise Maven
o configurar / configurar un proyecto de Enterprise Maven
 Método execute () / Credential Mapper
 Lenguaje de marcado de control de acceso extensible (XACML)
o sobre / Seguridad programática con el proveedor WebLogic XACML
 LDAP externo
o configurar, para autorización / Configurar un LDAP externo para
Autenticación / Autorización
o configurar, para autenticación / Configurar un LDAP externo para
Autenticación / Autorización
o problemas de solución de problemas / problemas de resolución de problemas
GRAMO
 Método getDescription
o sobre / Implementación del proveedor
 Método getIdentityAsserter
o sobre / Implementación del proveedor
 grupo
o sobre / Usuarios y grupos
 parámetros de grupo
o sobre / Grupos
 Sección de grupos
o sobre / sección de grupos

H
 Aplicación Hello Maven
o Lanzamiento / Lanzamiento de nuestra aplicación mundial Hello Maven y
WebLogic
 Opción de caché de jerarquía
o sobre / opciones de rendimiento
 HotSpot JVM / Instalación del servidor WebLogic y el plugin Maven de WebLogic

yo
 Asertividad de identidad
o sobre / Asertividad de identidad , uso de aserción de identidad Kerberos SSO
en un dominio de Microsoft
o usar / usar la aserción de identidad
 Identity Assertion SSO Kerberos
o usando, en Dominio de Microsoft / Usando Identity Assertion SSO Kerberos
en un dominio de Microsoft
 Identity Assertion SSO Kerberos, utilizando en el dominio de Microsoft
o sobre / Uso de Identity Assertion SSO Kerberos en un dominio de Microsoft
o El cliente de Windows, en el dominio de Active Directory / cliente de Windows
debe estar en el dominio de Active Directory
o sesión de cliente, sesión de sesión de dominio de Active Directory / cliente de
Windows debe registrarse en el dominio de Active Directory
o Autenticación de Windows integrada / Autenticación de Windows integrada
o Configuración de entrada SPN / DNS URL y definición de SPN
o Configuración de entrada de URL DNS / configuración de entrada de
URL DNS y definición de SPN
o usuario técnico de Active Directory / usuario de Active Directory técnico
o Archivo de configuración krb5 / generación Keytab y el archivo de
configuración krb5
o generación de keytab / generación Keytab y el archivo de configuración krb5
 o Creación de archivo JAAS / creación de archivo JAAS
o Configuración de argumentos de inicio WLS init / configuración de
argumentos de inicio WLS init
 Método de inicialización / Inicialización del proveedor
 instalando
o Servidor WebLogic / Instalación del Servidor WebLogic y el plugin Maven de
WebLogic
o Complemento WebLogic Maven / Instalación del servidor WebLogic y el
plugin Maven de WebLogic

J
 JAAS
o y MBean / MBean y JAAS
o LoginModule / Custom JAAS LoginModule
 Archivo JAAS
o creación / creación de archivo JAAS
 JACC
o sobre / JACC
 Embalaje JAR
o sobre / Creando el proyecto Maven
 JASPIC
o y Java EE / JASPIC y Java EE
 compilador javac
o sobre / Reconfigurar plugins estándar
 Java EE
o conceptos de seguridad / concepto general de seguridad en Java EE
o y JASPIC / JASPIC y Java EE
 Java EE 6
o sobre / JASPIC y Java EE
 Solicitudes de especificación de Java (JSR)
o sobre / Resumen
 JConsole
o sobre / Escribir proveedores personalizados - MBeans
 JDBC
o sobre / Concepto general de seguridad en Java EE
 Objeto JDBCResource
o sobre / los recursos de WebLogic
 JMX
o sobre / Escribir proveedores personalizados - MBeans
 JRebel
o sobre / Split deploy y beabuild-maven-plugin
 JSP
o utilizado, para emular el sistema SSO / A simple SSO JSP
K
 Boleto Kerberos
o sobre / Identificar: sujetos, directores y credenciales
 Kerbtray
o about / La sesión del cliente de Windows debe registrarse en el dominio de
Active Directory
 Klist
o about / La sesión del cliente de Windows debe registrarse en el dominio de
Active Directory
 Archivo krb5Login.conf / Problemas de depuración

L
 Protocolo ligero de acceso a directorios (LDAP)
o sobre / Identificar: sujetos, directores y credenciales
 servidor LDAP local
o configurar / Configuración del servidor LDAP local: usuario / roles / lockout
 Elemento localRepository / Instalación del servidor WebLogic y el plugin Maven de
WebLogic
 método de inicio de sesión () / Identificación: sujetos, principales y
credenciales , métodos del ciclo de vida: commit (), abort () y logout ()
o sobre / El método de inicio de sesión ()
 Clase LoginContext
o sobre / Identificar: sujetos, directores y credenciales
 LoginModule
o sobre / Identificar - Sujetos, Principales y Credenciales , Agregar WebLogic
MBeanMaker al POM , Custom Login JAASModule
o code / Custom Login JAASModule
o método login () / El método login ()
o método de cierre de sesión / Métodos del ciclo de vida - commit (), abort () y
logout ()
o método de aborto / métodos del ciclo de vida - commit (), abort () y logout ()
o Método de compromiso / Métodos de ciclo de vida: commit (), abort () y
logout ()
o métodos del ciclo de vida / métodos del ciclo de vida - commit (), abort () y
logout ()
 Interfaz LoginModule
o sobre / Autenticación bajo WebLogic
 Método logout () / Métodos del ciclo de vida: commit (), abort () y logout ()

METRO
 mave-antrun-plugin / Agregar WebLogic MBeanMaker al POM
 Maven
 o URL / Configuración de un proyecto de Enterprise Maven
o complementos, reconfiguración / Reconfiguración de complementos estándar
 maven-antrun-plugin
o sobre / El proyecto Maven
 maven-archetype-plugin
o utilizado, para crear módulos / Crear los módulos con maven-archetype-
plugin
 maven-install-plugin
o sobre / El proyecto Maven
 plugin maven-install-plugin
o sobre / Reconfigurar plugins estándar
 maven-jar-plugin
o sobre / El proyecto Maven , reconfiguración de plugins estándar
 maven-resources-plugin / Agregar WebLogic MBeanMaker al POM
 Complementos Maven
o reconfigurando / reconfigurando plugins estándar
 Proyecto Maven
o sobre / El proyecto Maven
o creando / creando el proyecto Maven
o dependencias / Dependencias
 MBean
o sobre / MBean y JAAS
o y JAAS / MBean y JAAS
o definir, con archivo MDF / Definir el MBean con un archivo MDF
 Archivo de definición MBean (MDF)
o sobre / Escribir proveedores personalizados - MBeans
 Clase MBeanImplBeanInfo / Definición del MBean con un archivo MDF
 Implementación MBean
o escribir / escribir la implementación de MBean
o proveedor de autenticación, inicializando / inicializando el proveedor
o proveedor de autenticación, implementación / implementación del proveedor
 Herramienta MBeanMaker
o sobre / Escribir proveedores personalizados - MBeans , MBean y JAAS , el
proyecto Maven
 MBeans
o sobre / Escribir proveedores personalizados - MBeans
 Interfaz MBeanServer
o sobre / Escribir proveedores personalizados - MBeans
 MBean tipo
o sobre / El proyecto Maven
 Archivo MDF
o MBean, definiendo con / definiendo el MBean con un archivo MDF
 Dominio de Microsoft
o Identity Assertion SSO Kerberos, usando en / Usando Identity Assertion SSO
Kerberos en un dominio de Microsoft
 módulos
o creando, con maven-archetype-plugin / Creando los módulos con maven-
archetype-plugin
 Proveedor de autenticación multiparte
o sobre / Proveedor de autenticación multiparte
 Interfaz MXBean
o sobre / Escribir proveedores personalizados - MBeans
 Clase MyProtectedServlet / Bean empaquetado en el módulo WAR
PAG
 Clase PacktAuthProviderImpl / Escribiendo la implementación de MBean
 Clase PacktLoginModuleImpl / Implementación del proveedor
 PasswordCredential interface / Credential Mapper
 Opciones de desempeño
o sobre / opciones de rendimiento
 Autenticación Perimetral
o sobre / Autenticación Perimetral
 POM
o WebLogic MBeanMaker, agregando / agregando WebLogic MBeanMaker al
POM
 Archivo pom.xml / Configuración de wls-maven-plugin en EAR POM
 Opción de caché de validador principal / Caché de validador principal
 seguridad programática
o sobre / Seguridad programática
o con WebLogic XACML Provider / Seguridad programática con el proveedor
WebLogic XACML
 Modelo de objetos del proyecto (POM)
o about / Creando los módulos con maven-archetype-plugin
 Atributo ProviderClassName / Definición del MBean con un archivo MDF
 Opción Purgar tickets / La sesión del cliente de Windows debe registrarse en el
dominio de Active Directory

R
 reconfigurando
o Plugins Maven / Reconfiguración de plugins estándar
 recursos, recursos de WebLogic / WebLogic
 Anotación RunAs
o utilizado, para modificar la identidad de seguridad / cambiar la identidad de
seguridad con RunAs
o sobre / Cambiar la identidad de seguridad con RunAs

S
 Anotación @ServletSecurity
o sobre / Concepto general de seguridad en Java EE
 conceptos de seguridad, Java EE / concepto general de seguridad en Java EE
 Interfaz de SecurityContext
o sobre / Credential Mapper
 identidad de seguridad
o modificación, anotación RunAs utilizada / Cambio de identidad de seguridad
con RunAs
 condición de rol de seguridad
 o sobre / condición de rol de seguridad
o opciones básicas / Básico
o basado en fecha y hora / basado en fecha y hora
o elemento de contexto / elemento de contexto
o Opción de bloqueo de usuario / bloqueo de usuario
o usuarios, desbloqueando / desbloqueando usuario
 Nombres de servicios principales (SPN) / configuración de entrada de DNS DNS y
definición de SPN
 Archivo settings.xml / Instalar el servidor WebLogic y el plugin Maven de WebLogic
 método de apagado / inicialización del proveedor
 Inicio de sesión único (SSO)
o sobre / Configuración de un LDAP externo para Autenticación / Autorización
 SPNEGO
o sobre / Uso de Identity Assertion SSO Kerberos en un dominio de Microsoft
 SPNEGO Identity Assertion
o configuración / configuración del asertador de identidad SPNEGO
o problemas de configuración, problemas de depuración / depuración
 Sistema SSO
o emulando, JSP utilizó / A SSO simple JSP
 mapeo DD estándar
o sobre / asignación estándar de DD
 parámetros de grupos estáticos
o sobre / Grupos estáticos
 objeto estructurado
o sobre / los recursos de WebLogic
 Objeto Sujeto / Identificación - Sujetos, Principales y Credenciales

T
 Servidor de otorgamiento de boletos (TGS)
o sobre / problemas de depuración

U
 usuario
o sobre / Usuarios y grupos
o desbloqueo / desbloqueo del usuario
 Opción de bloqueo de usuario / bloqueo de usuario
o en contexto de Active Directory / bloqueo de usuario en un contexto de Active
Directory
 parámetros de usuario
o sobre / Usuarios
 Sección de usuarios
o sobre / sección de usuarios
 UTF-8
o sobre / Reconfigurar plugins estándar
V
 VisualVM
o sobre / Escribir proveedores personalizados - MBeans

W
 Módulo WAR
o EJB, empaque en / Bean empaquetado en el módulo WAR
 WebLogic
o arquitectura de seguridad / arquitectura de
seguridad WebLogic , identificación: temas, directores y credenciales
o recursos / recursos de WebLogic
 archivo weblogic-ejb-jar.xml
o Asegurar / Asegurar el módulo EJB
 paquete weblogic.security. *
o sobre / arquitectura de seguridad WebLogic
 Plugin Maven de WebLogic
o instalar / instalar el servidor WebLogic y el plugin Maven de WebLogic
 WebLogic MBeanMaker
o añadiendo, a POM / Añadiendo WebLogic MBeanMaker al POM
 WebLogic Scripting Tool (WLST)
o sobre / Configuración de un LDAP externo para Autenticación / Autorización
 Seguridad WebLogic
o servidor LDAP local, configurando / Configuración del servidor LDAP local:
usuario / roles / lockout
 Arquitectura de seguridad de WebLogic
o sobre / Arquitectura de seguridad WebLogic , Identificando - Sujetos,
Principales y Credenciales
 Weblogic Security Framework (WSF)
o sobre / arquitectura de seguridad WebLogic
 Servidor WebLogic
o instalar / instalar el servidor WebLogic y el plugin Maven de WebLogic
o Argumentos de inicio, configurando / Configuración de argumentos de inicio
WLS init
 Aplicación mundial WebLogic
o Lanzamiento / Lanzamiento de nuestra aplicación mundial Hello Maven y
WebLogic
 Módulo web
o Asegurar / Asegurar el módulo web
 Módulo web, asegurando
o sobre / Asegurar el módulo web
o mapeo estándar de DD / mapeo estándar de DD
o asignación personalizada de roles / asignación de roles personalizados
o seguridad programática / seguridad programática
o seguridad programática, con WebLogic XACML Provider / seguridad
programática con el proveedor WebLogic XACML
 wls-maven-plugin
o configurando, en EAR POM / Configurando wls-maven-plugin en EAR POM