Consejo sobre IBM SmartCloud Enterprise: Integre su política de autentificación mediante un proxy

Construya un puente proxy entre sus aplicaciones caseras e IBM Cloud

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.

Dominique Vernier, IT Architect, IBM

Dominique Vernier photoEn años recientes, Dominique Vernier se enfocó en tecnologías de Java y en la arquitectura de la nube. También ha estado trabajando en tecnologías de la información durante bastante tiempo, donde adquirió un amplio conocimiento en tecnologías y productos tales como mensajería, bases de datos, SOA, EAI, cliente/servidor, C/C++ e infraestructuras existentes. Dominique también tiene un amplio conocimiento en áreas de industrias tales como telecomunicaciones, CRM, logística y seguros. Es el autor/co-autor de cuatro patentes relacionadas con motores y gestión de recursos. Actualmente, Dominique está a cargo de las soluciones de IBM SmartCloud Enterprise en el Equipo Global de IBM GTS.



24-12-2012

Desarrolle habilidades de este tema

Este contenido es parte de un knowledge path progresivo para avanzar en sus habilidades. Vea Computación en la nube: Desarrolle una política eficaz para la nube

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:

     /**
      * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse
      *      response)
      */
     protected void doGet(HttpServletRequest request,
               HttpServletResponse response) throws ServletException, IOException {
          String user = request.getUserPrincipal().getName();
          Security.setProperty("ssl.SocketFactory.provider",
                    "com.ibm.jsse2.SSLSocketFactoryImpl");
          Security.setProperty("ssl.ServerSocketFactory.provider",
                    "com.ibm.jsse2.SSLServerSocketFactoryImpl");
          String mappedUser = userMapping.getMapUser(user);
          String mappedPassword = userMapping.getMapPassword(user);
          boolean authorized = true;
          if (mappedUser != null && mappedPassword != null) {
               authorized = BusinessRules.getCheckRequest(request);
          } else {
               authorized = false;
          }

          if (authorized) {
               // Create an http client
               HttpClient httpclient = new HttpClient();
               Credentials defaultcreds = new UsernamePasswordCredentials(
                         mappedUser, mappedPassword);
               httpclient.getState().setCredentials(AuthScope.ANY, defaultcreds);

               HttpsURL httpsURL = new HttpsURL(basedURL + request.getPathInfo());
               HttpMethod method;
               String methodType = request.getMethod();
               if (methodType.equals("GET")) {
                    method = new GetMethod(httpsURL.getEscapedURI());
               } else if (methodType.equals("POST")) {
                    method = new PostMethod(httpsURL.getEscapedURI());
               } else if (methodType.equals("PUT")) {
                    method = new PutMethod(httpsURL.getEscapedURI());
               } else {
                    method = new DeleteMethod(httpsURL.getEscapedURI());
               }

               // Execute the request
               httpclient.executeMethod(method);

               // Get the result
               InputStream result = method.getResponseBodyAsStream();
               OutputStream pw = response.getOutputStream();
               int i;
               while ((i=result.read())!=-1) {
                    pw.write(i);
               }
               pw.close();
               response.setStatus(method.getStatusCode());
          } else {
               response.setStatus(HttpServletResponse.SC_FORBIDDEN);
               response.sendError(HttpServletResponse.SC_FORBIDDEN);
          }

     }

Es posible ver que este método utiliza la clase userMapping para llamar al componente de correlación de usuario y la clase de BusinessRules para llamar al componente comercial de correlación.

Componente LDAP

El componente comercial LDAP posee todos los usuarios de la empresa y también puede contener la tabla de correlación y algunas normas comerciales para la autorización. Puede utilizarse otros medios para cumplir con esta funcionalidad.

Componente de normas comerciales

El componente de normas comerciales verifica si una solicitud puede ejecutarse o no. Pueden implementarse todas las normas en este componente. En el ejemplo que se utiliza en este artículo, el componente de las normas comerciales solo acepta o rechaza las solicitudes, pero también es posible decidir tener normas comerciales que modifican una solicitud. Por ejemplo, el usuario solicita una instancia de Oro en la nube de IBM y solo está disponible el nivel de Bronce.

Componente de correlación del usuario

Nuevamente, es necesario evitar las situaciones en las que el usuario pueda acceder directamente al portal de la nube de IBM o utilizar la API; por lo tanto, gestione los recursos sin aplicar las normas de autorización que elaboró. Para hacerlo, para cada usuario de la empresa declarado en el LDAP y autorizado a utilizar la plataforma en la nube de IBM, cree un usuario en la plataforma en la nube de IBM — el ID de usuario debería ser diferente al ID de usuario de la empresa.

Establezca y mantenga una configuración de correlación entre el ID de usuario de la empresa y el ID de usuario en la nube de IBM y la contraseña utilizada para conectarse a la plataforma en la nube de IBM; un buen uso para el servidor LDAP. De esta forma, las credenciales de la plataforma en la nube de IBM permanecen ocultas de los usuarios de la empresa y no pueden conectarse directamente al portal en la nube de IBM o la API.

Otra opción consiste en tener solo un ID de usuario en la nube de IBM que correlacione todos sus usuarios de la empresa. Al hacerlo, pierde las capacidades de rastrear los usuarios de la nube de IBM y qué recursos utilizan. En vez de eso, debe rastrear esos datos desde el interior de sus propias aplicaciones. Puede agregarse un registro en el proxy para registrar todas las solicitudes, incluido el ID de recursos generado que le permite rastrear el consumo según la solicitud y el estado del recurso.

Componente de la RESTful API

Dado que el proxy simplemente reenvía la solicitud a la plataforma en la nube de IBM después de implementar las normas de autentificación o autorización, solo la URL base debe cambiarse para llamar a la RESTful API a través del servidor proxy. Por ejemplo, utilice:

http://localhost:9080/cloudproxy/

En lugar de:

https://www-147.ibm.com/computecloud/enterprise/api/rest/20100321/

Componente de la Java API

La Java API tiene una URL base por defecto almacenada en el archivo environment.properties ubicado en el archivo JAR de Java API. Es posible descomprimir este archivo JAR, modificar el archivo environment.properties, comprimirlo nuevamente como un archivo JAR y, luego, distribuir el JAR modificado entre sus desarrolladores:

api.host=www-147.ibm.com
api.port=443
api.scheme=https
api.context=/computecloud/enterprise/api/rest/
api.version=20100331
ram.url=https://www-147.ibm.com/cloud/enterprise/ram.ws
# Set the socket timeout in seconds for waiting for data
api.sotimeout=300

Es posible cambiarlo al establecer sus propios valores:

api.host=localhost
api.port=9080
api.scheme=http
api.context=/CloudProxy/
api.version=
ram.url=https://www-147.ibm.com/cloud/enterprise/ram.ws
# Set the socket timeout in seconds for waiting for data
api.sotimeout=300

Componente API de línea de comandos

Dado que la API de línea de comandos utiliza la Java API, se aplica la misma técnica que se describió en la sección anterior.

Sugerencias de seguridad adicionales

Algunos aspectos más para recordar:

  • Es posible añadir normas de firewall para garantizar que solo su proxy tiene autorización para alcanzar la plataforma en la nube de IBM.
  • Asegúrese que su aplicación casera solo está disponible desde la red de la compañía directamente o a través de la VPN.

Esto no evita que el usuario se dirija directamente al portal en la nube de IBM, pero como el usuario no conoce el ID de usuario en la nube de IBM, usted está a salvo.


Conclusión

Al aplicar esta técnica, que ajusta el conocimiento sobre la estructura de las API de IBM SmartCloud Enterprise y cómo funcionan, puede centralizar su lógica de negocio de autorización o autentificación en un servidor proxy y, al hacerlo, evitará tener normas comerciales distribuidas por todas sus aplicaciones caseras. Esto simplificará drásticamente el mantenimiento de su lógica de negocio.

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 inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de 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=Cloud computing, tecnologia Java
ArticleID=853200
ArticleTitle=Consejo sobre IBM SmartCloud Enterprise: Integre su política de autentificación mediante un proxy
publish-date=12242012