Consejo sobre IBM SmartCloud Enterprise: Integre su política de autentificación mediante un proxy
28/12/2012
La gestión de las normas comerciales para la autorización y la autentificación de aplicaciones de creación personalizada en la nube en el entorno de IBM® SmartCloud Enterprise no debe ser una tarea difícil. El autor utiliza la estructura de las API de la nube de IBM para mostrar cómo se desarrollan las normas comerciales en un proxy que conecta la línea de comandos, Java™ y RESTful API. La utilización de un proxy evita que los usuarios omitan sus normas comerciales cuando acceden al portal de la nube de IBM.

Fuente:  www.ibm.com

Gestión de la autorización y la autentificación para aplicaciones de etiqueta blanca — Las aplicaciones que desarrolla y que le permiten ubicar su propia marca de forma personalizada — en IBM SmartCloud Enterprise representan una posibilidad importante para la mayoría de las empresas. Algunas veces, algunos de estos tipos de aplicaciones no poseen normas comerciales que controlen aspectos como:

  • Limitar al usuario a un determinado nivel de servicio (en la nube de IBM, por ejemplo, al mantener a un usuario en el nivel Bronce).
  • Limitar al usuario a un nivel determinado de gastos.
  • Limitar al usuario a ciertos gastos dentro de un periodo de tiempo determinado.

Estos tipos de normas no pueden implementarse directamente en el portal de la nube de IBM. Por lo tanto, es necesario implementar estas normas en su propio portal.

Este artículo describe un método que centraliza todas estas normas en un proxy que recibe todas las solicitudes desde diferentes aplicaciones caseras y aplica las normas comerciales a dicho proxy. Posteriormente, envía la solicitud a la plataforma en la nube de IBM o la rechaza.

Cómo se implementan las API de la nube de IBM

La plataforma de la nube de IBM proporciona tres tipos de API:

  • RESTful API
  • Java API
  • API de línea de comandos

La API base es la RESTful API; las demás API se desarrollan sobre esta.

La Java API es un derivador entorno a la RESTful API lo que significa que la Java API proporciona beans y clases para llamar métodos; cada método llama a la RESTful API.

La API de línea de comandos llama a los métodos de API Java que desencadena las solicitudes de la RESTful API.

Por definición, las RESTful API se basan en URL y métodos; por ejemplo, un método GET recupera información de la plataforma y un método POST crea recursos en la plataforma. Las RESTful API de la nube de IBM se implementan en un servidor de aplicaciones en la plataforma de la nube de IBM y, de esa forma, se proporciona una dirección URL base para especificar ese servidor.

Entonces, la idea es crear un proxy entre las aplicaciones caseras y la plataforma en la nube de IBM. Este proxy recibe las solicitudes, aplica las normas comerciales y reenvía la solicitud a la plataforma en la nube de IBM.

Para garantizar que todas las aplicaciones caseras pasen a través del proxy:

  • Es posible adaptar la RESTful API simplemente al llamar a la URL del proxy como la URL base en lugar de utilizar la URL de la plataforma en la nube de IBM.
  • Para el paquete de Java API, es posible modificar la URL base predeterminada ubicada en el archivo environment.properties.
  • Y, finalmente, para la API de línea de comandos, dado que utiliza la Java API, es posible modificar el archivo environment.properties para cambiar la URL base predeterminada.

Otro problema a evitar es que los usuarios omitan las normas comerciales y que inicien sesión directamente en la plataforma en la nube de IBM. Para eso, simplemente debe crear una tabla correlacionada que relacione su ID de usuario con el ID de usuario/contraseña de la plataforma en la nube de IBM. El ID de usuario y la contraseña de la plataforma en la nube de IBM no se muestran al usuario de la empresa.

La ventaja de esta solución radica en que todas las aplicaciones caseras que utilizan el proxy como un servidor de solicitud aplican automáticamente las normas comerciales de autentificación y autorización vigentes; esto significa que la autentificación o autorización puede administrarse de forma central y puede implementarse en varias versiones en todas las aplicaciones caseras. Un usuario de la empresa no puede conectarse directamente en la plataforma en la nube de IBM mediante el portal o la API dado que no tendrá las credenciales para hacerlo.


Un diseño de alto nivel en los componentes

Los componentes que abarca este artículo incluyen los siguientes:

  • La plataforma en la nube de IBM
  • Un servidor proxy
  • Un componente LDAP
  • Un motor de reglas comerciales
  • Un motor de correlación del usuario
  • La RESTful API
  • La Java API
  • La API de línea de comandos


Ilustración 1 Los componentes que abarca este artículo
The components in this article
 

Ahora analicemos en detalle cada uno de ellos.

Plataforma en la nube de IBM

La plataforma en la nube de IBM proporciona servicios para gestionar los recursos en la nube y se encuentra en una instalación de IBM en algún lugar del mundo.

Servidor proxy

El rol del servidor proxy consiste en recibir las solicitudes de diferentes API, verifique estas solicitudes con respecto a las normas comerciales proporcionadas por el componente de normas comerciales y reenviar las solicitudes a la plataforma en la nube de IBM.

El servidor proxy utiliza una URL base para todas las operaciones; la URL de operación se reenvía al servidor en la nube de IBM. Por ejemplo, si el servidor proxy se instala en un host local, la API envía una solicitud como http://localhost:9080/cloudproxy/offering/storage. Después de verificar las normas comerciales, el servidor proxy llama a la plataforma en la nube de IBM mediante https://www-147.ibm.com/computecloud/enterprise/api/rest/20100321/offering/storage y retorna los resultados a la API.

El servidor proxy se configura para utilizar un directorio LDAP para la autentificación. El proxy utiliza el componente de correlación del usuario para correlacionar el ID de usuario de la empresa con las credencias en la nube de IBM para iniciar sesión y ejecutar la solicitud.

Un ejemplo de un servidor proxy puede implementarse por el siguiente método doGet() de un servlet: