Cumpliendo los requisitos de seguridad de las aplicaciones Software como un Servicio (SaaS)

Autenticación y autorización seguras con múltiples suscriptores

La seguridad es algo importante a considerar cuando se está haciendo la arquitectura de aplicaciones de Software como un Servicio (SaaS) porque los datos y los procesos pueden estar hospedados por fuera de las instalaciones de la empresa. En este artículo, aprenda sobre varios requisitos de seguridad para aplicaciones SaaS basadas en Java™ 2 Platform Enterprise Edition (J2EE), multi-suscriptor y eficientes, y explore mecanismos para resolver requisitos para lograr una autenticación y autorización seguras de los usuarios.

Chetan J. Kothari, Principal Architect, Infosys Technologies Limited

Author1 photoChetan Kothari trabaja como arquitecto principal en el Java™ 2 Platform, Enterprise Edition (J2EE) Center of Excellence en Infosys Technologies Limited, una empresa global líder en TI y servicios de consultoría de negocios. Chetan cuenta con más de nueve años de experiencia, con conocimientos en aplicaciones J2EE, desarrollo de infraestructuras, y en definición, arquitectura e implementación de soluciones de TI de gran escala y críticas de misión en un amplio rango de industrias. Chetan tiene un título profesional en Ingeniería Electrónica de la Universidad de Nagpur.



30-01-2012

Introducción

El modelo de negocios de Software como un Servicio (SaaS), orientado por un esfuerzo para reducir el costo y los esfuerzos de TI, está cosechando una gran cantidad de interés en la industria del software. En este modelo, la funcionalidad de las aplicaciones se entrega mediante un modelo de suscripción por Internet. El negocio no toma propiedad del software, sino que se suscribe a una solución total que se entrega de forma remota. Con el modelo SaaS usted puede reducir los costos de TI porque ya no necesitará soportar múltiples plataformas ni versiones. No obstante, como los datos y procesos están hospedados externamente, la seguridad es una prioridad principal en la arquitectura SaaS.

Como esto está cambiando la forma en que el software se crea, se consume y se entrega (en comparación son las prácticas de desarrollo de software tradicionales), el SaaS está probando que es una tendencia que agita a las TI. Una de las diferencias clave entre el desarrollo de una aplicación SaaS y el desarrollo de una aplicación corporativa es que las aplicaciones SaaS deben ser multi-suscriptor. Otros requisitos SaaS, como la seguridad, la personalización, la arquitectura orientada al servicio (SOA) y la integración, tienen impacto sobre la arquitectura de una aplicación SaaS.

En este artículo usted aprenderá varios requisitos de seguridad de nivel de aplicación de las aplicaciones SaaS multi-suscriptor y basadas en J2EE y mecanismos para responder a estos requisitos.

Requisitos de seguridad para aplicaciones SaaS

Una aplicación SaaS eficiente y multi-suscriptor tiene diversos requisitos de seguridad, incluyendo:

  • El sistema debe proporcionar seguridad y control de acceso para las funciones basadas en permisos.
  • Los datos de usuario pueden residir en un entorno dentro de las instalaciones de la empresa.

    El sistema debe proporcionar mecanismos para autenticar a los usuarios con datos de usuarios que residen en el entorno dentro de las instalaciones, y autorizar con control de acceso los datos que residan en un entorno on-demand.

  • Debido a los estrictos requisitos sobre cumplimiento y aislamiento de datos del suscriptor, los datos de usuario pueden residir en una base de datos dedicada en un entorno on-demand para cada uno de los suscriptores.

    El sistema debe proporcionar un mecanismo para autenticar y autorizar a los usuarios contra un dominio de base de datos separado, configurado para el suscriptor al que pertenece el usuario.

  • Los datos de usuario pueden residir en una base de datos compartida:
    • En un entorno on-demand, pero el esquema de base de datos puede ser diferente.

      El sistema debe proporcionar un mecanismo para autenticar y autorizar contra una base de datos compartida, con diferentes esquemas de base de datos configurados para el suscriptor al que pertenece el usuario.

    • En un esquema compartido en un entorno on-demand.

      El sistema debe proporcionar un mecanismo para autenticar y autorizar a los usuarios contra una base de datos compartida y un esquema compartido usado para todos los suscriptores.

  • Los datos de usuario pueden residir en una base de datos compartida.
  • Proporcionar un mecanismo para permitir que el administrador de cada suscriptor cree, administre y elimine cuentas de usuario para ese suscriptor en el directorio de cuenta de usuario.

Respondiendo a los requerimientos

Para responder a los requerimientos de seguridad de nivel de aplicación del SaaS, su arquitectura debe responder a los requisitos de autenticación y autorización. Dos escenarios en este artículo ilustran:

  • Base de datos de cuenta de usuario en un entorno on-demand

    En este escenario, la arquitectura debe proporcionar servicios de seguridad creados a la medida, para autenticar y autorizar usuarios contra una base de datos centralizada de cuenta de cuenta de usuarios multi-suscriptor, así como una base de datos dedicada específica según suscriptor. La arquitectura también debe proporcionar una interfaz para permitir a los suscriptores crear, administrar y eliminar cuentas de usuario para ese suscriptor en el directorio de cuenta de usuario.

    Cuando para los clientes no es importante el inicio único de sesión, se recomienda este enfoque. Este enfoque puede dirigirse hacia usuarios consumidores.

  • Base de datos de cuentas de usuario en las instalaciones de la empresa

    En este escenario, el suscriptor implementa un servicio de federación que se interconecta con el servicio propio de directorio de usuarios del suscriptor. Cuando un usuario final intenta acceder a la aplicación, el servidor de federación del suscriptor autentica al usuario localmente y negocia con el servidor de federación SaaS proporcionar al usuario un token de seguridad firmado. El token de seguridad emitido por el servidor de federación del suscriptor será utilizado por el proveedor SaaS para autorización.

    Este enfoque es recomendado cuando el inicio único de sesión (SSO) es importante para los clientes. Este también puede dirigirse hacia usuarios consumidores.


Base de datos de cuenta de usuario en un entorno on-demand

¿Por qué debería usted crear una solución de seguridad personalizada? Un requisito técnico clave es que una aplicación SaaS puede hospedar a múltiples suscriptores dentro de una infraestructura. Para responder a este requisito, los proveedores SaaS deben contar con un mecanismo para ejecutar una sola instancia de aplicación SaaS para acomodar usuarios de todos los suscriptores soportados por la aplicación.

La Figura 1 muestra una instancia individual de una aplicación SaaS que soporta usuarios de múltiples suscriptores. El Servicio de Seguridad usa una Database 1 centralizada para todos los usuarios del Suscriptor 1 y el Suscriptor 2. De manera concurrente, para responder a los estrictos requisitos de cumplimiento y aislamiento de datos del Suscriptor 3 y el Suscriptor 4, El Servicio de Seguridad también debe proporcionar un mecanismo de seguridad para soportar Database 2 dedicada para todos los usuarios del Suscriptor 3 y Database 3 dedicada para todos los usuarios del Suscriptor 4.

Figura 1. Soportando usuarios de múltiples suscriptores
Soportando usuarios de múltiples suscriptores

Una infraestructura de seguridad necesita proporcionar un dominio separado para cada suscriptor y un mecanismo para autenticar usuarios usando el dominio configurado para el suscriptor al cual el cliente pertenece, con base en el contexto. En este caso, el contexto es una combinación de parámetros (como suscriptor, línea de negocios, ubicación geográfica, etc) que decide la operación de negocios y el entorno de uso de la aplicación.

Una infraestructura de seguridad basada en contenedor J2EE tiene la limitación de soportar múltiples dominios de seguridad activos a un mismo tiempo. Aunque todos los contenedores J2EE principales proporcionan un mecanismo para configurar múltiples dominios, solo uno puede estar activo a la vez. El modelo de seguridad J2EE está basado en permisos de método, por lo que no es práctico y es complicado para acceso de seguridad de granularidad fina.

Entonces, todo lo que usted necesita para crear un servicio de seguridad personalizado con base en Java Authentication and Authorization Service (JAAS) para responder a las limitaciones mencionadas arriba. JAAS es un conjunto de API que permiten a los servicios autenticar e imponer controles de acceso a los usuarios. JAAS simplifica el desarrollo de la seguridad Java al poner una capa de abstracción entre la aplicación y los mecanismos dispares subyacentes de autenticación y autorización.

Creación personalizada de un servicio de seguridad basado en JAAS

Un servicio de seguridad basado en JAAS debe proporcionar mecanismos para:

  • Establecer identidad de usuario antes de acceder a cualquier función de negocios.
  • Proporcionar autorización funcional y de datos, manteniendo listas de usuarios para control de acceso.
  • Soportar la creación y el mantenimiento de usuarios, grupos y ACL.
  • Responder a los requerimientos de multi-suscriptor de las aplicaciones SaaS.
  • Permitir a los administradores de cada suscriptor crear, administrar y eliminar cuentas de usuario para ese suscriptor en el directorio de cuenta de usuario.

Una diferencia clave en la creación de servicios de seguridad para aplicaciones SaaS en comparación con otras aplicaciones corporativas es el soporte para manejar requerimientos de multi-suscriptor. Para responder a este requerimiento, es servicio de seguridad debe responder a los siguientes elementos.

  • Un medio para capturar contexto de usuario

    De nuevo, el contexto es una combinación de parámetros (como suscriptor, línea de negocios, ubicación geográfica, etc) que decide la operación de negocios y el entorno de uso de la aplicación SaaS.

  • Proporcionar tres enfoques distintos para la creación de arquitectura de datos multi-suscriptor:

    Base de datos de suscriptor dedicada

    A cada suscriptor se le proporcionará una base de datos. Este enfoque es recomendado cuando hay requerimientos estrictos de aislamiento de datos para los clientes.

    Base de datos compartida, esquema separado

    Se usa una base de datos compartida para todos los suscriptores y cada suscriptor tiene su propio conjunto de tablas en un esquema separado credo por al suscriptor. Las tablas de base de datos de la Figura 2 pueden ser usadas por un servicio de seguridad para soportar esto y un enfoque de base de datos dedicada por suscriptor.

    Figura 2. Esquema de base de datos dedicada
    Esquema de base de datos dedicada

    Base de datos compartida, esquema compartido

    Se usará una base de datos compartida y un esquema compartido para todos los suscriptores. En este enfoque, en todas las tablas la columna de ID de Suscriptor asocia cada registro con el suscriptor apropiado. La Figura 3 muestra bases de datos que pueden ser usadas por un servicio de seguridad para soportar este enfoque.

    Figura 3. Esquema de base de datos compartida
    Esquema de base de datos compartida
  • Seleccione la estrategia de arquitectura de datos predeterminada con base en los requerimientos de la mayoría de los suscriptores.
  • Aproveche una infraestructura de persistencia que proporcione:
    • un mecanismo orientado por configuración que le permita usar una estrategia de base de datos múltiple para conectarse con una base de datos.
    • Un mecanismo para implementar la lógica de persistencia usando un patrón de diseño Data Access Object (DAO) basado en interfaz.
    • Un mecanismo orientado por configuración DAO Config XML para permitir la conexión con diferentes implementaciones DAO, con una correlación del nombre lógico del DAO hacia los detalles de implementación.
  • La necesidad de una configuración XML base para interactuar con la base de datos para una estrategia predeterminada de arquitectura de datos.
  • Proporcionar una configuración XML personalizada para interactuar con la base de datos para el suscriptor que desee trabajar con otras estrategias de arquitectura de datos.
  • Proporcionar una forma para recuperar información que describa configuraciones y extensiones que sean específicas para cada suscriptor y conectar estas configuraciones personalizadas al tiempo de ejecución con base en el contexto del suscriptor.

Base de datos de cuentas de usuario en las instalaciones de la empresa

Un proveedor de SaaS puede aprovechar un servidor federado comercial disponible para la venta (COTS) para propagar de forma segura el token de federación a lo largo de todas las aplicaciones ubicadas en diferentes dominios de seguridad. El proveedor de SaaS necesita usar un servidor federado, el cual es interoperable con otras soluciones SSO usadas por los clientes corporativos en entornos on-demand, para una solución SSO. Un servidor de federación que resida en un entorno dentro de las instalaciones de la empresa debe tener una relación de confianza con un servidor de federación correspondiente dentro de la rede del proveedor del SaaS.

Con la base de datos de cuentas de usuarios en las instalaciones usted también debe:

  • Desarrollar un filtro de servlet para recuperar nombres de usuario autenticados que hayan sido autenticados usando un servidor federado desde un encabezado HTP y crear un principal/sujeto válido.
  • Aprovechar un servicio de seguridad personalizado, basado en Java Authentication and Authorization Service (JAAS), que responda a los requerimientos de multi-suscriptor del SaaS para autorización.
  • Llamar a la interfaz de programa de aplicación (API) desde el filtro de servlet para autorizar al usuario.
  • Configurar el filtro de servlet con Controller Servlet of Presentation Framework, basado en el patrón de diseño model-view-controller (MVC), para asegurarse de que las solicitudes entrantes satisfagan los requerimientos de seguridad.

Resumen

En este artículo usted aprendió estrategias para responder a requisitos de seguridad de nivel de aplicación de las aplicaciones SaaS basadas en J2EE. Estas estrategias pueden ser usadas por un proveedor de SaaS para responder a requisitos de seguridad de aplicaciones SaaS eficientes y multi-suscriptor.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que se registra en developerWorks, se crea un perfil para usted. Información sobre su perfil (nombre, país/región y compañia) estará disponible al público y acompañará cualquiera de sus publicaciones. Puede actualizar su cuenta IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=788853
ArticleTitle=Cumpliendo los requisitos de seguridad de las aplicaciones Software como un Servicio (SaaS)
publish-date=01302012