Introducción
Las aplicaciones web a veces necesitan tener acceso a cierta información del usuario en otro servicio web. En tal caso, ¿cómo se consigue la aplicación autorizada, en nombre del usuario, contra el que el servicio web? Hace años, este problema fue resuelto por el usuario dando sus credenciales a la aplicación web y luego la aplicación Web las utiliza para autenticarse contra el servicio web. Sin embargo, en la perspectiva del usuario, revelar sus credenciales a otra aplicación web para iniciar sesión como a sí mismo, no es una buena historia, ya que con las credenciales de usuario, aplicación web obtiene el control total de la cuenta de usuario hasta que el usuario cambie su contraseña. La gente necesitaba una solución para esto, y que llevaron a cabo una variedad de soluciones como Google AuthSub, AOL OpenAuth, Yahoo BBAuth, próximos API, API de Flickr, Amazon Web Services API [1], etc. Sin embargo, había una gran cantidad de diferencias entre cada uno de ellos, por lo que la gente necesitaba un estándar para esto. Aquí es donde entra en juego OAuth.
¿Cuál es OAuth? OAuth es un protocolo abierto que permite una aplicación para acceder a cierta información de usuario o recursos de otro servicio web, sin dar credenciales de usuario para el servicio web para la aplicación web. Por ejemplo, un usuario necesita para permitir que una aplicación de terceros para cambiar su foto de perfil de Twitter. Cuando se utiliza OAuth de autorización, que permite la aplicación de 3 ª parte para cambiar imagen de perfil de usuario después de que el usuario autorice a hacerlo sin dar credenciales directamente a la aplicación web. ¿Cómo funciona? Hay varios tipos de subvenciones en OAuth 2. Algunos tipos de subvenciones son ampliamente utilizados código de autorización, implícito, credenciales del cliente, contraseña, etc. Actualizar simbólico Dependiendo del tipo de subvención, hay diferentes maneras, en las que podemos usar OAuth para aplicaciones. Vamos a discutir acerca de cada uno de estos tipos posteriores sobre esta entrada. Pero en el ejemplo siguiente, vamos a utilizar el código de autorización de Grant Tipo. Antes de la etapa 1, la aplicación del consumidor se ha registrado en el proveedor de identidad (IDP) yIDP emite un ID de cliente y un secreto de cliente para el cliente. En el paso 1, App Consumidor envía la solicitud de autorización para IDP. Esa solicitud contiene ID de cliente, el alcance de la autorización y la URL de devolución de llamada. En este caso, el ámbito de aplicación se utiliza para especificar las cuales el grado de la aplicación del consumidor necesita autorización. Si volvemos al ejemplo anterior, la aplicación de 3 ª parte sólo se necesita autorización para cambiar imagen de perfil de usuario. Así que no debemos permitir que nada más que eso, para la aplicación del Consumidor. Esto es lo que está representado por "alcance" de la autorización. URL de respuesta es lo que usa IDP ponerse en contacto con la App Consumidor espalda. Una vez que se concede la solicitud de autorización (en el paso 4) contactos desplazados la aplicación de los consumidores a través de esta URL. En el paso 2, IDP pregunta al usuario para autenticar y autorizar a sí mismo la App Consumidor para el ámbito especificado. En el paso 3, el usuario, después de la autenticación a sí mismo en primer lugar, examina el alcance de la solicitud de autorización y la acepta. En el paso 4, los contactos de desplazados la aplicación de los consumidores a través de su URL de respuesta y la envíaCódigo de Autorización. Este código de autorización, con secreta de cliente, se puede utilizar para obtener un token de acceso para acceder al recurso en particular. Eso es lo que ocurre en el paso 5. En el paso 6, IDP envía un token de acceso a la App Consumidor. En el paso 7, Aplicación del Consumidor utiliza ese token de acceso para solicitar el acceso al recurso en particular desde el servidor de recursos. En el paso 8, los contactos del servidor de recursos IDP para obtener el testigo de acceso se verifica, y en el paso 9, IDP envía la respuesta de verificación de vuelta al servidor de recursos. Entonces, servidor de recursos Permite que la aplicación de los consumidores para acceder a los recursos situados bajo el alcance determinado. OAuth para su servicio web / aplicación En el ejemplo hemos comentado anteriormente, un proveedor de identidad se integra con Twitter para que la aplicación externa puede acceder a ella en nombre de sus usuarios. Ahora, si usted quiere asegurar su servicio web mediante OAuth, ¿cómo eso? Es necesario un proveedor de identidad para eso. WSO2 Identity Server es un proveedor de dicha identidad que proporciona una manera simple y fácil de hacer esto conpocos pasos. Vamos a discutir los pasos usando un ejemplo. En este ejemplo, vamos a asegurar un servicio REST mediante OAuth. El resto servicio que va a utilizar es el servicio de búsqueda de YouTube. Aquí, WSO2 ESB actúa como el servidor de recursos. Configuración del entorno En este ejemplo, direcciones IP de los equipos host de cada servidor es tan follows.WSO2 ESB 4.8.1: 10.100.0.64WSO2 ES 4.6.0 y Tomcat: 10.100.0.65 Vamos a utilizar como la App Consumidor. Se trata de utilizar el cliente Apache ámbar OAuth2 para comunicarse con WSO2 ES, pero se puede utilizar cualquier cliente de OAuth para su aplicación. Puede descargar su proyecto Maven completa. Después de descargar el archivo de la guerra, alojarlo en el servidor Tomcat. Entonces seremos capaces de acceder a él a través de Ahora vamos a configurar WSO2 ESB. Aquí vamos a utilizar un elemento API para configurar punto final de servicio REST. Tenemos que crear un controlador personalizado para el elemento de API para lograr lo que hemos discutido en el paso 8 y 9. Este controlador se comunicará con WSO2 ES y obtener el token de acceso verificado, una vez que la aplicación envía el Consumidorsolicitud de acceso a los recursos, con el token de acceso, a ESB. clase de controlador es el siguiente. Proyecto completo experto puede ser descargado desde. Este controlador lee OAuth2TokenValidationService URL de WSO2 IS y credenciales de administrador para acceder a ese servicio, desde axis.xml de ESB. A continuación, se llama a este servicio de administración y pasar el alcance de la autorización de acceso de emergencia. Entonces WSO2IS verificará ellos e informar a la ESB información sobre el estado de verificación. A continuación, genere el proyecto manejador ($ mvn instalación limpia) y obtener el creado. A continuación, poner en $ ESB_HOME / repositorio / componentes / lib.
Añadir siguientes configuraciones de $ ESB_HOME / repositorio / conf / axis2 / axis2.xml
Reiniciar ESB y vaya a Administrar> Service Bus> Fuente Ver Añadir API siguiente elemento de configuración.
En este elemento API configuramos servicio REST back-end que necesita ser asegurado con OAuth, y la clase de controlador implementamos. En este ejemplo, tenemos que quitar la cabecera del mensaje entrante, que se utiliza para autenticar para el servicio expuesto por ESB, del mensaje antes de enviarlo al servicio de back-end "Autorización", porque a menos que YouTube intenta validar esta muestra y da una mensaje de error diciendo 'no válida simbólico'. Ahora vamos a configurar WSO2 Identity Server. En primer lugar, vamos a registrar esta aplicación al Consumidor en WSO2 Identity Server. Descargar e iniciar WSO2IS. Después de iniciar sesión, vaya a Main> Administrar> OAuth y haga clic en Registro de aplicaciones nuevo. Para este ejemplo, estamos utilizando OAuth versión 2. Dar un nombre para la aplicación. La URL de respuesta de nuestra aplicación es. Hay varios tipos de subvenciones con el apoyo de WSO2 se muestran. Vamos a discutir de forma individual, más adelante en este post. Una vez que se añade la aplicación, su aparecerán en la lista de la siguiente manera. Ahora haga clic en el nombre de la aplicación y la siguiente páginase van a plantear. Cuando se añadió la aplicación, un ID de cliente y un secreto de cliente se generan para la aplicación. Aplicación para el consumidor debe tener con él. ID de cliente es público donde cliente secreto es un secreto que no debe ser expuesto al público. aplicación de los consumidores también deben saber de autenticación y acceso Token puntos finales de desplazados internos (es decir WSO2 ES en este caso). Ir a y haga clic en la búsqueda de imagen. En este ejemplo, vamos a utilizar 'código de autorización' Tipo Grant. Ahora podemos dar ID de cliente y el punto final de la autorización de desplazados internos a la App Consumidor. Aquí estamos enviando nuestra solicitud inicial (paso 1) al punto final de la autorización del IDP. Entonces IDP (WSO2 ES) muestra siguiente página al usuario. Una vez que haga clic en Continuar, se le pedirá para autenticar al usuario. (Paso 2)
Después de iniciada la sesión, se nos pedirá que revisar y autorizar la solicitud de autorización de la aplicación del Consumidor. A continuación, aprobamos la solicitud. (Paso 3) Una vez que hemos aprobado la solicitud, la aplicación del consumidor es conseguir el código de autorización. (Etapa 4)
Ahora App consumidor puede solicitar para el testigo de acceso. En esta solicitud se tiene que especificar el código de autorización y secreta de cliente. Esta solicitud se envía al punto final del token de acceso del PDI. (Paso 5) A continuación, el IDP enviará una señal de acceso. (Paso 6) Ahora aplicación del consumidor puede enviar la solicitud a ESB con el token de acceso. (Paso 7) En este ejemplo, se llama servicio de ESB 'YouTubeSearch', que hemos creado anteriormente. Que el servicio finalmente llama YouTube servicio de búsqueda. Correspondiente comando curl de esto es así.
rizo -v -X GET -H "Autorización: Portador <señal_acceso>" Una vez que esta petición acierta en la ESB, el manejador desplegamos llamará IDP (es decir WSO2 ES) y obtener el token de acceso verificada. (Paso 8 y 9) Entonces ESB llamarán servicio REST backend y obtener respuesta de vuelta a la App Consumidor. (Paso 10, 11 y 12) Tipos de subvención el apoyo de WSO2 Identity Server Identity Server compatible con los siguientes tipos de subvenciones. Código de autorización Este es el tipo que discutimos lo largo del poste, donde IDP emite un código de autorización una vez que la solicitud de autorización de la aplicación del Consumidor se aprobó por parte del usuario. Implícito en este tipo, el secreto de cliente no está involucrado. Esto se utiliza sobre todo para aplicaciones móviles y aplicaciones basadas en navegador web (javascript aplicaciones, etc.), donde el secreto de cliente no se pueden mantener en secreto. En este método, una vez que el usuario autoriza solicitud de autorización de la aplicación del consumidor, aplicación obtiene directamente el token de acceso. En este tipo de contraseña, las credenciales del usuario son enviados con la petición inicial. Esto parece contradecir con la finalidad de tenerOAuth, que está evitando regalar su contraseña a una aplicación de 3 ª parte. Pero en realidad no es así, porque se supone que este método sea utilizado por las aplicaciones de los cuales pertenecen al servidor de recursos en sí, pero no cualquier otro de 3 ª parte. Credenciales del cliente propietario del recurso (es decir, el usuario) no está involucrado en este método. En este caso, la aplicación del consumidor utiliza su ID de cliente y el cliente secreto para obtener un token de acceso. Se supone que este método a utilizar cuando la aplicación necesita acceder a sus propios datos en lugar de los datos protegidos de los usuarios. Volver a cargar simbólico En este método, IDP proporciona una actualización de emergencia (con acceso de emergencia), la aplicación que consumidor puede utilizar para obtener un nuevo token de acceso una vez que el actual acceso de emergencia ha caducado. Así el usuario no tiene por qué implicar que autorice cada vez que el testigo de acceso expira. SAML En este tipo de subvención, la aplicación del consumidor puede presentar una aserción SAML para IDP, y obtener un token de acceso, sin necesidad de usuario para autenticar de nuevo. Esto es algo similar para actualizar el tipo de emergencia. Conclusión Es posible que desee para permitir3 ª Parte aplicaciones para acceder a su servicio de web para hacer tareas particulares en nombre de los usuarios. Por lo tanto, las aplicaciones necesitan una manera de autenticar a sí mismos en contra de su servicio web. Pidiendo a los usuarios que se limitan a dar sus contraseñas para aplicaciones 3 ª parte no es una solución, ya que permite a esas aplicaciones que se pueden hacer cualquier cosa que el usuario puede hacer, independientemente de lo que el usuario realmente quiere hacer la aplicación nombre de ellos mismos. En tal situación, OAuth es una muy buena solución que no ponga en peligro la seguridad de la cuenta del usuario, ya que en OAuth usuario no tiene que regalar sus credenciales para aplicaciones 3 ª parte. Para asegurar su servicio web con OAuth, que no tiene que aplicar por sí mismo desde el principio. WSO2 Identity Server (WSO2 ES) es un proveedor de identidad, que lo hace por usted con unos sencillos pasos. Una vez que ha configurado el servicio web con WSO2 ESB, 3 ª Parte aplicaciones sólo tienen que registrarse en WSO2 ES. Y ya está listo para comercializar. descargas
