Mostrando entradas con la etiqueta integración. Mostrar todas las entradas
Mostrando entradas con la etiqueta integración. Mostrar todas las entradas

lunes, 11 de enero de 2016

WSO2 DAS: fallo de autenticación en admin-dashboard

image

He estado trabajando en un escenario de integración que incluye las siguientes herramientas:
  • WSO2 Identity Server 5.0.0 como key manager y gestión de usuarios.
  • WSO2 API Manager 1.9.1 para la gestión de las APIs.

La integración se hace bastante rápida y existe un manual bien detallado al respecto en la documentación oficial.

Para ver el uso de las APIs quise integrar además el WSO2 Dashboard Application Server 3.0.0 a esta fiesta de herramientas así que me fui al manual del WSO2 API Manager y seguí los pasos descritos.

Al intentar acceder al Admin Dashboard con las credenciales por defecto admin/admin me topo que no me permite autenticarme. Pruebo autenticarme en el WSO2 IS y funciona, en el DAS también funciona, en el Publisher y en el Store pues también funciona, así que ya es algo extraño.

Activo el modo debug y a bucear en los logs y esto es lo que me encuentro.

Invocación del WSO2 DAS al WSO2 IS para autenticar al usuario vía servicios web:
Request:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
               xmlns:aut="http://authentication.services.core.carbon.wso2.org">
    <soap:Header/>
    <soap:Body>
        <aut:login>
            <aut:username>admin</aut:username>
            <aut:password>admin</aut:password>
            <aut:remoteAddress>localhost</aut:remoteAddress>
        </aut:login>
    </soap:Body>
</soap:Envelope>
Response:
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
    <soapenv:Body>
        <ns:loginResponse xmlns:ns="http://authentication.services.core.carbon.wso2.org">
            <ns:return>true</ns:return>
        </ns:loginResponse>
    </soapenv:Body>
</soapenv:Envelope>


Invocación para obtener el listado de roles del usuario y validar si se le permite el acceso:
Request:
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
    <soapenv:Body>
        <ser:getRoleListOfUser xmlns:ser="http://service.ws.um.carbon.wso2.org">
            <ser:userName>admin</ser:userName>
        </ser:getRoleListOfUser>
    </soapenv:Body>
</soapenv:Envelope>
Response:
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
    <soapenv:Body>
        <ns:getRoleListOfUserResponse xmlns:ns="http://service.ws.um.carbon.wso2.org"
                >
            <ns:return>Internal/admin</ns:return>
            <ns:return>Internal/subscriber</ns:return>
            <ns:return>Internal/WSO2.ORG_admin_DefaultApplication_PRODUCTION</ns:return>
            <ns:return>Internal/WSO2.ORG_admin_DefaultApplication_SANDBOX</ns:return>
            <ns:return>Internal/everyone</ns:return>
        </ns:getRoleListOfUserResponse>
    </soapenv:Body>
</soapenv:Envelope>

Como pueden apreciar el listado de roles que se devuelve es el siguiente:
  • Internal/admin
  • Internal/subscriber
  • Internal/WSO2.ORG_admin_DefaultApplication_PRODUCTION
  • Internal/WSO2.ORG_admin_DefaultApplication_SANDBOX
  • Internal/everyone

Cuando  reviso el fichero donde se definen los roles con permito a admin-dashboard, el fichero site.json  aparece lo siguiente:
Roles permitidos:
  • admin
  • subscriber
{
    "theme" : {
        "base" : "default",
        "subtheme" : "modern"
    },
    "context" : "/admin-dashboard",
    "request_url":"READ_FROM_REQUEST",
    "tasksPerPage": 10,
    "allowedRole":"admin",
    "allowedRoles":"admin,subscriber",
    "workflows":{
     "applicationWorkFlowServerURL": "https://localhost:9446/services/",
     "subscriptionWorkFlowServerURL": "https://localhost:9446/services/",
     "signupWorkFlowServerURL": "https://localhost:9446/services/",
     "appRegistrationWorkFlowServerURL": "https://localhost:9446/services/"

    },
    "ssoConfiguration" : {
        "enabled" : "false",
        "issuer" : "API_WORKFLOW_ADMIN",
        "identityProviderURL" : "https://localhost:9448/samlsso",
        "keyStorePassword" : "",
        "identityAlias" : "",
        "responseSigningEnabled":"true",
        "keyStoreName" :""
    }
}
Tuve que adicionar el rol Internal/admin  al listado de allowedRoles para que mediera acceso a la aplicación.

De esa manera ya tuve acceso y pude terminar la integración con el DAS. En próximas entradas estaré posteando la integración entre estas 3 herramientas.

Espero les sea de utilidad.

viernes, 15 de noviembre de 2013

Escenarios de aplicación de SOA

Como muchos deben saber SOA es un concepto no es algo concreto, es una forma de pensar cuando tenemos que resolver determinados problemas. Y generalmente estos problemas se enmarcan en determinados escenarios donde podemos aplicar lo que SOA como paradigma y estilo arquitectónico nos da: guías, patrones, principios, buenas prácticas, etc.

Un resumen de estos escenarios se pueden ver en la siguiente imagen.



A groso modo estos escenarios exponen dos temas fundamentales: integración e interoperabilidad entre diversas soluciones.

Una breve descripción de los escenarios de la imagen.
  • Optimización de procesos de negocio: Se basa en un problema común de las empresas que definen sus procesos de negocio por un lado y compran aplicaciones por otro lado, existiendo un defasaje entre procesos y aplicaciones que generalmente termina en que las aplicaciones son las que dictan como se hacen las cosas dentro de la empresa, un ejemplo común es cuando una empresa compra SAP o algún otro ERP. Con la ayuda de SOA y BPM, se pueden exponer las funcionalidades principales de las aplicaciones legadas existentes como servicios, rediseñar e implementar los procesos usando BPMN y BPEL y vincular entonces las actividades de esos procesos con los servicios expuestos por las aplicaciones. Esto conlleva a la posible creación de nuevas aplicaciones e incluso a exponer procesos como servicios que puedan ser consumidos por clientes, socios y proveedores de la empresa.
  • Integración: Otro problema muy normal en las empresas que genera la compra sin mucho pensar de aplicaciones es que estás están desarrolladas para diferentes sistemas operativos, en variadas plataformas tecnológicias y lenguajes de programación, y no fueron diseñadas para comunicarse entre si. Por lo que a la hora de querer combinar dos o más es prácticamente imposible hacerlo. SOA y los patrones de integración permiten resolver este problema.
  • Racionalización del portafolio de aplicaciones: de conjunto con los dos escenarios anteriores, el uso de los principios de SOA permite definir cuales son las funcionalidades de TI que requiere una empresa, y donde estas residen, en qué aplicaciones, y entonces se pueden tomar decisiones sobre qué aplicaciones dejar, cuales eliminar, o cuales combinar en nuevas aplicaciones que oculten las viejas para los usuarios final. El resultado es un portafolio renovado de aplicaciones, muy ágil y dinámico que ahorra $$ y trabajo a los departamentos de TI.
  • Federación: Los escenarios anteriores generalmente van a lo interno de la empresa. Este escenario se basa en como la empresa se relaciona con otras empresas y negocios y como puede formar parte de la actual globalización luchando por un posicionamiento en el mercado. SOA permite esta integración global donde no solo se exponen funcionalidades, si no identidades y se externalizan determinados recursos de la empresa a ser desarrollados o brindados por otras empresas. Esto mejora el ROI y permite a empresas que no pueden darse el lujo de tener grandes departamentos de TI de poder usar recursos de otras empresas que se brindan como servicios.

En la siguiente imagen se pueden ver estos escenarios un poco más desglosados y con una representación en cuanto a tiempo de duración, su orientación en la empresa y su alcance.



En la imagen se muestran los distintos escenarios en función de su alcance, el tiempo de duración y quien es el que lo conduce, si es el Negocio o el departamento de TI de las organizaciones.

miércoles, 18 de septiembre de 2013

WSO2: Nuevo caso de éxito en escenarios de integración.







Suva, es una empresa suiza proveedora líder de seguros federales para las compañías y sus empleados, usan el ESB de WSO2 para que actúe como plataforma central de integración para habilitar servicios web entre diferentes plataformas involucradas en proveer una atención completa para los asegurados.

En el caso de estudio publicado recientemente, sobresale:

·         La decisión de Suva para adoptar una arquitectura orientada a servicios para desacoplar los proveedores y consumidores de servicios web, soportando el mapeo de protocolos, seguridad y datos.

·         El uso del ESB de WSO2 como hub central hacia el cual todas las plataformas realizan llamadas incluyendo:
1.       SAP business management software,
2.       Oracle Weblogic,
3.       Oracle Tuxedo,
4.       Microsoft .NET framework,
5.       Aplicaciones legadas escritas en COBOL.

·         Cómo Suva usa el Developer  Studio de WSO2 para crear la integración manejada por el ESB de WSO2.
      Nota: el Developer Studio de WSO2 es un plugin para el IDE Eclipse que permite el desarrollo de los diferentes componentes y mediadores que serán desplegados en el ESB, y para otras herramientas de la suite.


·         El rol del ESB de WSO2 en el soporte de las diferentes capas de seguridad dentro de la empresa.

Lo pueden ver con más detalles desde este enlace

jueves, 9 de mayo de 2013

Sobre la base de la suite de WSO2 he estado elaborando el diseño e implementación de un conjunto de productos orientados al desarrollo de soluciones de integración e interoperabilidad.

Son los siguientes:


Sub-Plataforma de Seguridad: encargada de proveer los servicios de seguridad necesarios para garantizar el acceso seguro a la información y la protección de la misma en todo momento.

Sub-Plataforma de Integración: encargada de establecer los mecanismos necesarios para ofrecer una comunicación transparente, estable y eficiente entre las diferentes soluciones a integrar.

Sub-Plataforma de Monitoreo: encargada de ofrecer capacidades de monitoreo de todos los componentes de la plataforma así como sistemas externos previa adaptación de los mismos. Brindar información para la toma de decisiones a partir del análisis de la información monitorizada.

Plataforma para Soluciones de Integración e Interoperabilidad.

No quiero adelantar mucho pero la  idea general detrás de este esfuerzo es disponer de varios productos que podamos ofertar a la medida a través de rápidas personalizaciones y despliegues empresariales de rápido desarrollo y configuración que le den soporte a los más diversos patrones de integración empresarial existentes.