Módulo IV.-Seguridad Aplicativa Agenda

1

Módulo IV.- Seguridad Aplicativa

Seguridad en Java


Agenda

• Objetivo.

• Cómputo Distribuido.

• Arquitectura J2EE.

• Introducción a la seguridad con Java.

• Recursos, Directores y Recursos.

2


Objetivo

• Conocer la arquitectura general de una

aplicación desarrollada con Java con J2EE.

• Introducir los conceptos de seguridad que se

manejan en una aplicación basada en J2EE.


Cómputo distribuido

3



• Se basa en el principio de dividir una tarea

en tareas más pequeñas.

• Cada tarea se puede asignar a diferentes

equipos “más pequeños” que funcionan en

conjunto.

• El cómputo distribuido permite reutilizar

componentes, ya que estos tienen bien

definidas sus interfaces.



• Soporte a la interoperabilidad y portabilidad.

• Seguridad en el acceso a las aplicaciones.

• Los sistemas distribuidos ofrecen transparencia.

• Se programa de manera modular. Permite separar cada capa del sistema.

4


Guías de diseño• Las aplicaciones deben ser modulares, dividiendo:

– Interfaz de usuario.

– Reglas de negocio.

– Datos.

• Esto brinda flexibilidad al mantenimiento del sistema.

• El diseño se recomienda sea realizado basado en componentes.

• La funcionalidad final se alcanza a través de diferentes tareas internas que son implementadas por los componentes.

• Los componentes pueden ser comprados o desarrollados de manera interna.


Guías de diseño• El crear un componente demasiado extenso, puede

provocar un gran esfuerzo para modificar su funcionamiento.

• Se recomienda que las capas que componen una aplicación sean independientes unas de otras.– Procedimientos almacenados hacen dependiente la capa de

lógica de negocio de la de datos.

• Los componentes deben se reutilizables. Se deben separar de acuerdo a los servicios que ofrecen.

• Se debe soportar la escalabilidad. – Usar pool de conexiones.

– Uso de cache.

– “Granjas” de servidores.

5


Arquitectura J2EE


Introducción

• Plataforma que permite el desarrollo de aplicaciones basadas en componentes, multicapa y distribuidas, para ofrecer el soporte al cliente y al servidor.

• Beneficios.– Diseño y desarrollo sencillo.

– Se puede seleccionar, servidores, herramientas y componentes.

– Escalable.

– Modelo de seguridad.

– Recursos para Integrar aplicaciones empresariales. (EIS)

6


Introducción

• La arquitectura J2EE esta basada en Java y utiliza

los estándares del mercado, lo que le permite

interactuar con el servidor de aplicaciones.


Ventajas del modelo de desarrollo

• El modelo de desarrollo es estandarizado lo que permite seleccionar:

– Servidores.

– Herramientas.

– Componentes.

• Modelo escalable.

– Contenedores diseñados

Para proveer escalabilidad

7


Ventajas del modelo de desarrollo

• Modelo de seguridad incluido.

– Los parámetros de seguridad se configuran durante el proceso de instalación de la aplicación.

– Permite la configuración de la aplicación de manera independiente del código.

• El modelo permite la integración con los sistemas de información existentes a través del J2EE Connector Architecture JCA.


Roles de la plataforma

• Proveedor del J2EE.

– Crea los contenedores de los componentes de acuerdo a la especificación.

– Provee un ambiente estandarizado al momento de ejecución para los componentes.

– Provee el conjunto de servicios definidos por J2EE (API).

– Ofrece las herramientas necesarias para instalar, configurar y poner a punto la aplicación, así como para la administración del ambiente operativo.

8



• Proveedor de componentes.– Es el encargado de entregar los componentes utilizados

en una aplicación J2EE, el cual entrega la funcionalidad requerida.

– Define la forma en la que se puede ejecutar el componente.

• Ensamblador de Aplicaciones.– Encargado de unificar el funcionamiento de un grupo

de componentes para crear una aplicación.• Crea la descripción de la aplicación.

• Identifica los recursos externos necesarios.

• Genera el EAR.



• Instalador.

– Después de que se tiene la aplicación, esta se instala en un ambiente operacional específico.

• Administrador del sistema.

– Es responsable por el monitoreo de la aplicación instalada, así como de configurar los contenedores J2EE.

• Proveedor de herramientas.

– Responsable de entregar las herramientas necesarias para instalar, crear y empaquetar una aplicación.

9


Componentes tecnológicos

• La plataforma soporta diferentes componentes.– Applets.

– Clientes.

– EJB.

– Web.

• Se ensamblan en los módulos J2EE y se instalan en los contenedores.

• Los contenedores ofrecen la siguiente funcionalidad:– Administración del ciclo de vida.

– Seguridad.

– Administración de transacciones.

– “Threading components”


Componentes tecnológicos

– Los componentes corren en varias capas del

modelo.

– El modelo de la aplicación J2EE define:

• La capa cliente.

• La capa media (middle)

– Capa Web.

– Capa EJB.

• La capa EIS.

10


Servicios Tecnológicos

• La plataforma permite

que las aplicaciones

J2EE hagan uso de

diferentes servicios:

– De directorio.

– Correo electrónico.

– Soporte de

transacciones.


Servicios tecnológicos

• JNDI– Con el API JNDI se puede acceder a los servicios de nombres y

directorios, utilizando librerías estándar de Java.

• LDAP.

• DNS.

• NIS

– También se puede utilizar para obtener una referencia a un EJB a través de una aplicación empresarial.

• JDBC– Es un API que permite a una aplicación el acceso a una base de datos

relacional.

– Permite al desarrollador crear código independiente de la base de datos.

– Permite utilizar diferentes bases de datos en un ambiente heterogéneo.

11



• JTA y JTS.– Son API’s que facilitan las transacciones entre aplicaciones J2EE.

– JTA:

• interactúa con el código de la aplicación y ofrece una interfaz que la aplicación ocupa para controlar las transacciones.

• Habilita el uso de transacciones distribuidas.

• Habilita el control del inicio y fin de una transacción.

– JTS:

• Especifica la implementación del administrador de la transacción.

• El cual soporta JTA para ofrecer el soporte de transacciones a las entidades involucradas en la misma.

– Servidor de transacciones.

– Administrador de recursos.

– Entre los dos ofrecen el soporte a transacciones confiables a los componentes de una aplicación.



• Conector de Arquitecturas.

– Es el API estándar de los vendedores de J2EE que

permite soportar conexiones hacia los EIS.

• ERP’s.

• Manejo de transacciones mainframe.

• Sistemas de bases de datos.

– Se implementan a través del desarrollo de

adaptadores que permiten la iteración entres las

aplicaciones J2EE y los EIS.

12



• JAXP:

– Permite que la aplicación valide y transforme

un documento XML.

– es flexible y trabaja de manera independiente

de una implementación particular XML.


Introducción a la seguridad

con Java

13


Definir los requerimientos

• El primer paso en la implementación de seguridad con Java es la definición de los requerimientos de seguridad.

• El desarrollador debe especificar las necesidades de seguridad.

• Esto se establece en una lista de verificación que se implementa por el encargado de “subir” la aplicación en el servidor de aplicaciones y que se encarga de configurarla.

• Existen dos formas asegurar una aplicación utilizando Java.– Seguridad declarativa.

– Seguridad programada.


Seguridad declarativa

• Este mecanismo de seguridad se expresa en sintaxis de XML.

• Se deja en un documento llamado “deployment descriptor”.

• Describe la estructura de la seguridad.

– Roles.

– Control de acceso.

– Requerimientos de autenticación de la aplicación.

• El desarrollador describe los requerimientos de seguridad.

• El encargado de “subir” la aplicación utiliza las herramientas

necesarias.

– Para “mapear” el “deployment descriptor” a un mecanismo de

seguridad implementado por los contenedores J2EE.

14


Seguridad Programada

• Se encuentra en la aplicación misma.

• Se refiere a las acciones de seguridad programadas en la aplicación.

• Se utiliza cuando la seguridad declarativa no es suficiente.

• Ejemplo.– Se puede programar que las autorizaciones :

• Sucedan en cierto horario del día.

• Estén basadas en los parámetros de la llamada.

• Dependan del estado de un EJB.

• Dependiendo de la información del usuario en la base de datos.


Modelo de seguridad J2EE

• Las aplicaciones Java pueden ser colocadas en diferentes

contenedores.

• Permite crear aplicaciones multicapa.

• El objetivo del modelo de seguridad J2EE es tener

seguridad punto a punto asegurando cada capa de la

aplicación.

15



• Las capas contienen recursos seguros y no seguros.

• En tiempo de ejecución los contenedores utilizan el modelo de seguridad para forzar la autorización.

• Para asegurar que sólo los usuarios autorizados pueden acceder a un recurso se utiliza:

– La identificación.

– La Autenticación.

– La autorización.


Identificación.

• Proceso que permite reconocer a una

entidad por el sistema..

16


Autenticación

• Proceso que verifica la identidad de un

usuario, dispositivo o cualquier otra entidad

en el sistema.

• Prerrequisito para permitir el acceso a un

recurso en el sistema.


Autorización

• Permite el acceso controlado a los recursos

protegidos y se basa en la identificación y

autenticación.

17



• El modelo de programación de la aplicación J2EE hace que

esta sea independiente de los mecanismos específicos de

implementación de la seguridad por parte del servidor de

aplicaciones, lo que permite su portabilidad


Recursos, Directores y

Roles

18


Políticas de Seguridad

• En Java se manejan dos dominios de políticas de seguridad.

– Dominio empresarial.

– Dominio de la aplicación o componente de la aplicación.

• Los recursos que son “desplegados” en el dominio de políticas de

seguridad de la empresa son diferentes de los “desplegados” en el

dominio de las políticas de seguridad de la aplicación.


Requerimientos de Autenticación de

los Recursos

• En una aplicación J2EE se utilizan diferentes

mecanismos que permiten proveer de los

requerimientos de autenticación a los recursos..

– Configuración de la identidad.

– Autenticación programada.

– Mapeo de “directores”.

– Llamada no personalizada.

– Mapeo de credenciales.

19


Configuración de la identidad

• El contenedor J2EE asegura el acceso a un recurso

a través de la autenticación.

– Director, se refiere a un usuario final o alguna otra

entidad que requiere acceso a la aplicación.

– Información de autenticación, se provee durante el

proceso de “despliegue” de la aplicación en el servidor

de aplicaciones.


Autenticación programada

• Un producto J2EE debe proveer de los datos de los directores y la

autenticación para un recurso en tiempo de ejecución.

• La aplicación los recibe de diferentes maneras:

– Cómo parámetros.

– De los parámetros del ambiente del componente.

• A esta técnica se le conoce como autenticación programada.

20


Mapeo de directores

• Es un requerimiento de seguridad adicional.

• El recurso obtiene la información de los directores y los atributos de seguridad a través del mapeo de la identidad y los atributos de seguridad del director que realiza la llamada.

• El mapeo del director es recomendada pero no es obligatoria.


Llamada no personalizada

• Una director del recurso actúa entre el director que realiza

la llamada y el recurso.

• Asigna la identidad y las credenciales del “llamador” al

administrador de recursos.

• Esta técnica se utiliza para verificar una llamada no

personalizada.

21


Mapeo de credenciales

• Esta técnica se utiliza cuando el servidor de

aplicaciones y un sistema de información

empresarial manejan diferentes dominios de

autenticación.


El director• Un director representa a un usuario que requiere acceso a un

recurso.

• Es decir una entidad que puede ser autenticada por un protocolo

de autenticación en un servicio de seguridad implementado en

la empresa.

• Se puede identificar a un director por su nombre principal y

autenticarlo utilizando los datos de autenticación.

22


Tipos de directores

• Dominio de la política de seguridad.– Determina el alcance que define el administrador de seguridad para la

política.

• Dominio de la tecnología de seguridad.– Es el alcance sobre el que actúa la tecnología de seguridad para

garantizar una política de seguridad.

– Por ejemplo si se utiliza Kerberos para mantener la seguridad en diferentes sistemas, estos sistemas se encuentran bajo el mismo dominio tecnológico, aunque puede afectar diferentes dominios de políticas de seguridad.

• Atributos y credenciales.– Cada director se asocia con un conjunto de atributos de seguridad, que

tienen acceso a los recursos protegidos.

– Una credencial contiene los atributos de un director, y se utiliza para autenticarlo.


Rol

• Un rol es un grupo lógico de usuarios.

• Se realiza un mapeo entre estos y las identidades de

seguridad (directores y grupos) por el responsable del

“despliegue” de las aplicaciones.

• Se utilizan en la seguridad declarativa y programada.

23


Rol

• La autorización declarativa se utiliza para controlar el acceso a un

método de un EJB.

• Este método se asocia a los elementos de permisos de los métodos que

se implementan en el descriptor.

• Un director puede ejecutar el método si este tiene acceso al método en

el rol.


Rol

• Cada director se asocia a un rol que le permite acceder a un recurso.

• La aplicación de las reglas de seguridad en los recursos WEB o en los EJ B depende de que exista la asociación del director y la llamada al recurso en el rol.

• El contenedor puede determinar esto basado en los atributos de seguridad del director.

24


Rol

• Los roles son definidos en un archivo XML llamado “deployment descriptor”.

• Contiene elementos XMl que permiten la implementación de la seguridad.

• El creador de la aplicación asigna los métodos principal y de componentes de un EJB a los roles de seguridad.

• Esté también define cada rol utilizando un elemento “rol-seguridad”.

• Cada elemento se encuentra a nivel del archivo ejb-jary aplica a todos los EJBs que están en este nivel.


Rol

• Un usuario puede tener asignados varios roles.

25


Acceso a los recursos

• Al acceder a un recurso el usuario puede:

– Utilizarlo como el que llama.

– Utilizar una identidad alterna.


Acceso a los recursos

Documents

Módulo IV.-Seguridad Aplicativa Agenda