Seguridad de Java 2

Las funciones de Seguridad de Java™ 2 están soportadas en WebSphere Application Server Liberty. La Seguridad de Java 2 proporciona un mecanismo de control de acceso de alta precisión y basado en políticas que aumenta la integridad global del sistema mediante la comprobación de los permisos antes de permitir el acceso a determinados recursos del sistema protegidos.

Seguridad de Java 2 es independiente de la autorización basada en roles de Java Platform, Enterprise Edition. Seguridad de Java 2 protege el acceso a recursos del sistema como, por ejemplo, entrada y salida de archivo, sockets y propiedades; mientras que la seguridad de Java Platform, Enterprise Edition protege el acceso a recursos web, como servlets y archivos JSP.

Seguridad de Java 2 para desplegadores y administradores

Antes de habilitar la Seguridad de Java 2, asegúrese de que todas las aplicaciones tengan los permisos necesarios; de lo contrario, las aplicaciones podrían no ejecutarse. De forma predeterminada, se otorga a las aplicaciones los permisos por especificación de Java Platform, Enterprise Edition 7.0. Si una aplicación no está preparada para la Seguridad de Java 2 o si el proveedor de aplicaciones no proporciona un archivo permissions.xml como parte de la aplicación, la aplicación puede generar excepciones de control de acceso de Seguridad de Java 2 en el tiempo de ejecución cuando la Seguridad de Java 2 está habilitada. Aunque la aplicación se esté ejecutando, puede que no se ejecute correctamente.

Seguridad de Java 2 para desarrolladores de aplicaciones

Los desarrolladores de aplicaciones deben comprender los permisos que se han otorgado en la política WebSphere predeterminada y los requisitos de permiso de las API de Java SDK. Debe saber si las API que invoca la aplicación requieren permisos adicionales o no. Si desea más información sobre qué API de Java requieren permisos, consulte Permisos en el Java 2 SDK.
Los permisos se añaden a una aplicación utilizando el archivo permissions.xml, y el codebase que está asociado con los permisos listados se basa en la ubicación del archivo. Para una aplicación .war autónoma, el archivo permissions.xml está empaquetado en el directorio META-INF y todos los permisos especificados se aplican a todos los módulos incluidos en el archivo .war. Para una aplicación .ear, el archivo permissions.xml se empaqueta directamente en el directorio META-INF para el propio archivo .ear, y los permisos especificados se aplican a todos los módulos incluidos en el archivo .ear.
Nota: En el caso de una aplicación .ear, los archivos permissions.xml que están empaquetados en el directorio META-INF de cualquier módulo distinto de .ear se ignoran.

[17.0.0.2 and later]Cuando se trabaja con aplicaciones OSGi que contienen paquetes de aplicación web (WAB), se añaden permisos mediante el archivo permissions.perm. Si el WAB no tiene el archivo permissions.perm, la política toma como valor predeterminado java.security.AllPermission.

Habilitación de la Seguridad de Java 2

Las funciones de Seguridad de Java 2 forman parte de la extensión de kernel y se habilitan en tiempo de rutina de carga actualizando el archivo bootstrap.properties con la propiedad websphere.java.security.

Si se especifica la propiedad websphere.java.security en el archivo bootstrap.properties, se aplica la Seguridad de Java 2; de lo contrario, no se realiza ninguna comprobación de permisos.

Especificación de permisos restringidos

Liberty proporciona un mecanismo para especificar permisos restringidos cuando ejecuta un componente de aplicación EJB o web. Un permiso restringido garantiza que no se otorgue ninguna instancia de ese permiso a un paquete o una aplicación. Proporciona un mecanismo para que las aplicaciones no se otorguen más permisos de los permitidos, por ejemplo, el permiso de salir de VM.
Los permisos restringidos se especifican en los archivos server.xml y client.xml. El ejemplo siguiente muestra cómo se restringe el PropertyPermission que se utiliza para escribir la propiedad del sistema os.name. Esta sintaxis es idéntica en los archivos server.xml y client.xml:
<javaPermission className="java.security.PropertyPermission" name="os.name" actions="write" restriction="true" />

Otorgamiento de permisos

Los paquetes OSGi pueden autorregular los permisos que se otorgan a las bibliotecas/clases dentro del paquete utilizando el archivo permissions.perm.

Las aplicaciones también pueden autorregular los permisos que se otorgan mediante el archivo permissions.xml o especificando los otorgamientos de permiso en los archivos server.xml y client.xml.

Permisos de paquetes OSGi

La especificación OSGi proporciona un mecanismo para especificar los permisos de un paquete utilizando el archivo permissions.perm en el directorio OSGI-INF del paquete. El mecanismo permite un control de acceso preciso de los permisos de un paquete.
El archivo permissions.perm especifica los permisos máximos que requieren los paquetes.
Importante: Un archivo permissions.perm vacío no es equivalente a ningún archivo permissions.perm. Asegúrese de tener un archivo permissions.perm no vacío si desea permisos restringidos.

Declaración de permisos en server.xml y client.xml para las aplicaciones

Los permisos sin un codebase especificado, que se definen en los archivos server.xml y client.xml, se aplican a todas las aplicaciones en ese servidor de Liberty.
Puede especificar los permisos que se van a otorgar en los archivos server.xml y client.xml como se muestra en el ejemplo siguiente. En este ejemplo, se otorga el PropertyPermission que habilita la lectura de todas las propiedades del sistema:
<javaPermission className="java.util.PropertyPermission"  name="*" actions="read" />
Puede especificar los permisos que se restringirán en los archivos server.xml y client.xml. El ejemplo siguiente muestra cómo se restringe el PropertyPermission que se utiliza para escribir la propiedad del sistema os.name. Esta sintaxis es idéntica en los archivos server.xml y client.xml:
<javaPermission className="java.security.PropertyPermission" name="os.name" actions="write" restriction="true" />
Notas:
  • Un permiso restringido tiene restriction establecido en true.
  • Si una aplicación intenta otorgarse un permiso definido como restricted, el permiso restringido tiene prioridad sobre el otorgamiento y no lo permite.

Declaración de permisos en permissions.xml para las aplicaciones

El archivo permissions.xml es un archivo nuevo que se ha presentado mediante la especificación de Java EE7. Se empaqueta en el directorio META-INF de una aplicación.

Para las aplicaciones empaquetadas como un archivo .war autónomo, los permisos que se especifican en el nivel WAR de META-INF se aplican a todos los módulos y bibliotecas que están empaquetados dentro del archivo .war.

Para las aplicaciones que son paquetes en un archivo .ear, la declaración de permisos debe estar en el nivel del archivo .ear. Este conjunto de permisos se aplica a todos los módulos y bibliotecas que están empaquetados dentro del archivo .ear o dentro de sus módulos contenidos. Se ignora todo archivo permissions.xml dentro de estos módulos empaquetados, independientemente de si se proporciona un archivo permissions.xml para el propio archivo .ear.

Para las aplicaciones que están empaquetadas en un archivo .rar, la declaración de permisos debe estar en el nivel RAR de META-INF.

Opción no-rethrow

Cuando la seguridad de Java 2 está habilitada, el JDK Security Manager lanza una excepción java.security.AccessControl de forma predeterminada cuando se produce la infracción de un permiso. Si la excepción no se maneja, puede provocar un error de tiempo de ejecución. Para ayudar a los desarrolladores cuando están preparando sus aplicaciones para la seguridad de Java 2, está disponible una opción no-rethrow. La opción no-rethrow permite registrar la excepción AccessControl en console.log y messages.log, pero no hace que la aplicación falle. La opción no-rethrow se habilita especificando websphere.java.security.norethrow=true en el archivo bootstrap.properties. La opción no-rethrow no está habilitada de forma predeterminada, por lo que debe habilitar esta propiedad especificándola en el archivo bootstrap.properties.
Nota: Puesto que esta propiedad no permite al Security Manager lanzar la excepción, técnicamente, el Security Manager no aplica la seguridad de Java 2. La propiedad no-rethrow no debe utilizarse en un entorno de producción.

Actualizaciones dinámicas

Las actualizaciones dinámicas de los archivos de permisos como permissions.perm, permissions.xml, server.xml y client.xml no están soportadas. Las actualizaciones de permisos requieren un reinicio del servidor de Liberty.

Icono que indica el tipo de tema Tema de concepto

Nombre de archivo: cwlp_java2security.html