Autenticación y autorización a través de una redirección URL

Editar en línea

Puede utilizar un servicio alojado externamente desde IBM® API Connect para recopilar detalles de autenticación y autorización del usuario cuando una aplicación solicita acceso en nombre de ese usuario.

Antes de empezar

Para completar esta tarea, deberá crear o disponer de una definición de seguridad de OAuth que utilice el tipo de concesión «Implicit» o el tipo de concesión «Access Code» (código de autorización). Para obtener más información, consulte «Creación de una definición de seguridad de OAuth ».

Acerca de esta tarea

Si utiliza métodos de autenticación que no son compatibles con API Connect, puede redirigir a los usuarios a un sitio URL adecuado en el que puedan autenticarse. A continuación, el usuario vuelve al proceso « OAuth » una vez que se han confirmado la autenticación y la autorización.

La siguiente ilustración indica el flujo de transacción para la autenticación de terceros.
Figura 1. Flujo de transacciones de autenticación (AU) y autorización (AZ) de terceros

Ilustración del flujo de autenticación y autorización de terceros.
  1. La aplicación inicia una solicitud para acceder a una API protegida con una entidad de terceros. API Connect redirige la aplicación con una redirección de HTTP 302 basada en identity extraction -> redirect -> redirect-url, para la autenticación de usuario (y autorización opcional).
  2. La aplicación se comunica directamente con la entidad de terceros para recopilar la identidad de usuario. API Connect no está implicado en esta comunicación. Después de que la entidad de terceros termine de procesar la autenticación (y la autorización opcional), devuelve una redirección HTTP 302 que utiliza original-url de la solicitud, con el nombre de usuario y el código de confirmación añadidos.
  3. API Connect recibe la solicitud que incluye el nombre de usuario y el código de confirmación, y se comunica con la autenticación URL, basándose en authentication -> x-ibm-authentication-url, para confirmar la identidad del usuario antes de que se complete la solicitud.
  4. Una HTTP 200 respuesta de la entidad externa permite API Connect continuar el proceso de solicitud de OAuth 2.0 como si el propietario estuviera autenticado. A continuación, la solicitud se procesa de acuerdo con el tipo grants .
    • - accessCode devuelve un código temporal a la aplicación.
    • - implicit devuelve la señal de acceso a la aplicación.
    Para cualquier respuesta que no sea HTTP 200, la solicitud falla con una declaración añadida al registro de errores.

Procedimiento

Para crear un formulario externo e indicar la dirección URL a la que se redirigirá a los usuarios, siga estas instrucciones:
  1. Cree el servicio para la autenticación y autorización. Utilizará la dirección URL de la página de destino de este servicio como redirección URL.
    1. Para incluir en su formulario elementos proporcionados por API Connect, utilice los siguientes parámetros de consulta de URL a los que se redirige a su usuario.
      Draft comment:
      Per https://github.ibm.com/velox/docs/issues/3697, these parameters are not included in the URL due to a v5 parity issue, with the exception of original-url. Therefore, the following sentence has been removed and an appropriate note added. In due course, the v5 parity issue will be resolved, at which point the sentence cnan be restored and the note deleted. "When the user is redirected to your page, the URL they are sent to contains the following query parameters:"
      Nota: A excepción de original-url, ninguno de estos parámetros se incluye en URL automáticamente; debe añadirlos según sea necesario.
      app-name
      El nombre de la aplicación que solicita acceso, tal y como figura en el Catálogo de consumidores del Portal del desarrollador.
      appid
      El ID de la aplicación que solicita acceso.
      catálogo
      El nombre del catálogo donde la aplicación está utilizando el producto.
      CatalogId
      El ID del catálogo donde la aplicación está utilizando el producto.
      título de catálogo
      Nombre de visualización fácil de usar para el catálogo.
      org
      El nombre de la organización de consumidores que aloja la aplicación.
      orgID
      El ID de la organización de consumidores que aloja la aplicación.
      título de organización
      Nombre de visualización fácil de usar para la organización.
      url-original
      La URL original URL a la que la aplicación redirigió al usuario, incluyendo los parámetros de consulta de la URL original URL que son necesarios para las solicitudes estándar de OAuth 2.0. Puede incluir estos parámetros en el servicio para proporcionar información al usuario. Además, se añade state_nonce. El «state_nonce» es un código hash generado con fines de verificación. El archivo « URL » está codificado en formato « URL » y debe descodificarse antes de su uso; el contenido state_nonce debe permanecer sin cambios.
      proveedor
      El nombre de la organización de proveedores de API.
      ProviderId
      El ID de la organización de proveedores de API.
      título de proveedor
      Nombre de visualización fácil de usar para la organización de proveedores.
      ámbito solicitado
      [opcional] Si la comprobación del ámbito de la aplicación está activada y sustituye el scope valor de la solicitud inicial, este campo contiene el scope valor de la solicitud inicial, y el nuevo valor de ámbito de sustitución se introduce en original-url.
      TRANSID
      id de transacción utilizado en el GW para la transacción que desencadena esta llamada
      La dirección URL a la que se envía al usuario cuando es redirigido a su página tiene la siguiente forma:
      Redirect_URL?original-url=Original_URL&state_nonce=R_State&app-name=Application_Name
      donde todas las variables son como se ha descrito anteriormente. La redirección URL no tiene ningún límite de tamaño impuesto por .
    2. Cree las etapas de autenticación, autorización y cualquier etapa intermedia que necesite que tenga lugar antes de permitir el acceso a la aplicación. Una vez completadas estas etapas, redirija al usuario a la URL original y añada su nombre de usuario, su código de confirmación y el nombre de la aplicación que se va a evaluar para conceder o denegar el acceso mediante . El código de confirmación no tiene un límite de tamaño impuesto por .
      El original de URL requiere el siguiente formulario:
      Original_URL&username=User_Name&confirmation=Confirmation_Code

      donde todas las variables son como se ha descrito anteriormente.

      Por ejemplo:
      
https://your_gateway.com/your_org/your_catalog/your_api/oauth/authorize?response_type=code&redirect_uri=https://example.com/redirect&scope=/your_api&client_id=5af57a4a-6db9-4141-ad08-5709432af66e&state_nonce=HoIbRG+6bZtqlB7LDkq4gjlD3SHKglCbnYdHs/bMz2Y=&username=spoon&confirmation=12345678
    3. Para enviar sus propias respuestas de error después del servicio de autenticación y autorización, redirija al usuario a Original_URL y añada un código de error. También puede añadir un nombre de usuario. Utilice el formato siguiente:
      Original_URL&username=User_Name&error=Error_Response

      donde Error_Response es el mensaje que desea enviar y todas las demás variables se describen como anteriormente.

      Por ejemplo:
      https://your_gateway.com/your_org/your_catalog/your_api/oauth/authorize?response_type=code&redirect_uri=https://example.com/redirect&scope=/your_api&client_id=5af57a4a-6db9-4141-ad08-5709432af66e&state_nonce=HoIbRG+6bZtqlB7LDkq4gjlD3SHKglCbnYdHs/bMz2Y=&username=User&error=access_denied
  2. Cree un servicio para validar el código de confirmación y el nombre de usuario. realiza una llamada GET a tu URL de autenticación URL después de que el usuario sea redirigido de nuevo a la URL de autorización URL. Cuando se realiza la llamada, incluye en su cabecera de autorización el nombre de usuario y el código de confirmación que ha proporcionado anteriormente. Comprueba que sean correctos y responde con un código de éxito de HTTP, como por ejemplo:200 OKsi desea permitir el acceso, o no-200 HTTPcódigo de respuesta, como por ejemplo401 Unauthorizedpara denegar el acceso.
  3. En la configuración de su proveedor de OAuth, introduzca la URL de redireccionamiento URL que se utiliza en el paso 1 y la URL de autenticación URL que se utiliza en el paso 2.