Seguridad de Java 2

La funcionalidad de Seguridad de Java™ 2 está soportada 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. La Seguridad de Java 2 protege el acceso a recursos del sistema como, por ejemplo, la entrada y salida de archivos, los sockets y las propiedades; mientras que la seguridad de Java Platform, Enterprise Edition protege el acceso a recursos web como, por ejemplo, los servlets y los 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, a las aplicaciones se les otorgan los permisos según la especificación 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 conocer los permisos que se otorgan en la política de WebSphere predeterminada y los requisitos de los permisos de las API de Java SDK. Debe saber si las API que invoca la aplicación requieren permisos adicionales o no. Para obtener más información sobre qué Java requieren permisos, consulte Permisos en 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.

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 ha introducido la especificación 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 gestor de seguridad JDK emite una excepción java.security.AccessControl de forma predeterminada cuando se produce una violación del 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, hay 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: Como esta propiedad no permite que el gestor de seguridad emita la excepción, el gestor de seguridad técnicamente 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

Términos y condiciones para centros de información | Comentarios


Icono de indicación de fecha y hora Última actualización: Tuesday, 7 June 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=cwlp_java2security
Nombre de archivo:cwlp_java2security.html