Product-apim: Admite autenticación básica para suscriptores

APIM 3.0.0, recientemente lanzado, es compatible con la autenticación básica. Actualmente lo usamos en nuestro entorno.

Sí para endpoints de backend. Para Api no pude encontrar la opción.

Editor de API -> Configuraciones en tiempo de ejecución -> Seguridad a nivel de aplicación

@ Tomas-Mrazek correcto, ahora también admitimos la autenticación básica para clientes de API. Puede habilitar la opción Basic en el nivel de seguridad de la aplicación como se muestra arriba. Esto permitirá a los consumidores de API invocar esta API utilizando la combinación de su nombre de usuario y contraseña.

Ok, parece que estaba buscando en el mismo lugar. Solo lo probé y funciona.

Esto trae más preguntas.

¿Cómo funcionan las suscripciones con autenticación básica? ¿Parece que cualquier usuario puede invocar cualquier API, independientemente de las suscripciones? ¿Hay alguna forma de "asignar" usuarios a aplicaciones específicas para que puedan invocar solo la API a la que está suscrito?

Si tanto Prod como Sandbox comparten la misma puerta de enlace, ¿cómo se determina cuál se invoca al realizar la autenticación básica?

Estas dos preguntas no necesitarían una respuesta si usáramos la clave de la aplicación y el secreto de la aplicación en lugar del nombre de usuario y la contraseña en la autenticación básica.

Tal vez me esté perdiendo algo, por lo que sería bueno si pudiera indicarme la documentación.

¿Cómo funcionan las suscripciones con autenticación básica? ¿Parece que cualquier usuario puede invocar cualquier API, independientemente de las suscripciones? ¿Hay alguna forma de "asignar" usuarios a aplicaciones específicas para que puedan invocar solo la API a la que está suscrito?

No, debería funcionar igual que con el token oauth2. Solo el usuario suscrito puede invocar la API, no importa si a través de token o autenticación básica.

No puede asignar usuarios a aplicaciones, porque funciona de manera opuesta: las aplicaciones pertenecen al usuario. Si desea un control más detallado, cree roles en / carbon console y asígnelos a los usuarios. En el editor de API, vaya a la configuración de API, cambie la visibilidad en devportal a un rol específico. Luego, cree ámbitos con una función específica para cada recurso, asigne este ámbito al recurso y habilite la seguridad. Los usuarios suscritos que pueden usar la API, pero sin que usted asigne un rol al usuario, no pueden llamar a ningún recurso protegido.

Si tanto Prod como Sandbox comparten la misma puerta de enlace, ¿cómo se determina cuál se invoca al realizar la autenticación básica?

Buena pregunta. No conozco la respuesta.

Por cierto, esto no funcionaría con la clave y el secreto del consumidor. El punto final se especifica durante la generación de / token AFAIK.

Hola @ Tomas-Mrazek y @tmkasun , este es exactamente mi problema con la autenticación básica ahora. Permítanme intentar resumir mis pensamientos sobre la autenticación:

OAuth2 : suscribimos la aplicación a una API. Según la clave y el secreto, conocemos la aplicación y el entorno. Entonces, para permitir que la aplicación use Api, todo lo que tenemos que hacer es suscribirla. Entonces, cualquier usuario puede llamar a esa Api dado que conoce la clave y el secreto.

Claves de API estáticas : aquí conocemos la clave, y eso brinda suficiente información para saber qué aplicación llama a la API y qué entorno utiliza. El concepto de aplicación que se suscribe a la API para poder usarla todavía se aplica. Solo necesitamos suscribir la aplicación a una API.

Autenticación básica como está ahora : la llamaré "autenticación básica basada en el usuario". Abandona por completo el concepto de aplicación y suscripción, y requiere el uso de un concepto diferente (permisos basados ​​en el usuario) y diferentes herramientas como el uso de Carbon admin en lugar de Publisher o Store / DevPortal. Y no puede distinguir entre el entorno de producción y el entorno de pruebas cuando se utiliza una única puerta de enlace para ambos. También brinda un nivel adicional de complejidad para configurar y administrar. Ahora no es suficiente mirar la lista de aplicaciones suscritas, también hay que ir al administrador de carbono y ver los usuarios y los permisos. Y si quiero limitar la calificación de una aplicación específica para una API, o tener diferentes niveles de suscripción, no puedo hacerlo por el usuario.

Lo que yo vería como una forma "correcta" de admitir la autenticación básica sería lo siguiente:

Autenticación básica a nivel de aplicación : eliminamos al usuario del concepto (como con las claves estáticas) y usamos la autenticación de la aplicación en su lugar. La aplicación aún debe suscribirse a la API. La clave del consumidor y el secreto del consumidor se utilizan como credenciales de autenticación básicas. De esa manera mantenemos el concepto de Suscripción App / Api, podemos continuar usando las mismas herramientas que para todo lo demás (editor / devPortal, sin necesidad de Carbon Admin), y sabemos qué aplicación usa qué Api y qué entorno en función de las claves.

¿Cómo llegar allá?

Hay dos opciones. Cambie la implementación básica actual a la propuesta anteriormente o implemente una nueva llamada "autenticación básica de la aplicación".
También hay una tercera opción, para admitir tanto el usuario / contraseña como la clave / secreto en la autenticación básica existente, pero esa es la más sucia.

La implementación de autenticación básica no es suficiente. Por ejemplo, puede limitar la visibilidad de la API en devportal según los roles, que deben crearse y asociarse con el usuario a través de la consola Carbon.

Hola @ Tomas-Mrazek y @markokocic
Gracias por sus sugerencias, busque mis respuestas en línea.

¿Cómo funcionan las suscripciones con autenticación básica? ¿Parece que cualquier usuario puede invocar cualquier API, independientemente de las suscripciones? ¿Hay alguna forma de "asignar" usuarios a aplicaciones específicas para que puedan invocar solo la API a la que está suscrito?

El soporte de autenticación básica para las solicitudes de los clientes no requiere la presencia de suscripciones. Si un creador de API ha habilitado el soporte de autenticación básica para una API en particular, esa API se puede invocar sin suscribirse a esa API (por aplicación).
y @markokocic sí, el funcionamiento de la suscripción es An Application subscribed to an API .

Además con la autenticación de Baisc:
todavía obtienes:

• Limitación de nivel de recursos o nivel de API
• Validación del alcance del recurso

no obtendrás:

• Limitación del nivel de suscripción
• Diferenciación del entorno de producción y Sandbox

Si tanto Prod como Sandbox comparten la misma puerta de enlace, ¿cómo se determina cuál se invoca al realizar la autenticación básica?

Sí, no pudimos diferenciar el entorno por nombre de usuario y contraseña, por lo tanto, cuando use la autenticación básica, no tendrá la opción de seleccionar el entorno, se usará el punto final de producción.

@ Tomas-Mrazek

El punto final se especifica durante la generación de / token AFAIK.

No, los puntos finales (Prod & Sandbox) los define el creador de la API al crear la API, los consumidores de la API pueden proporcionar una URL de devolución de llamada para una aplicación si desean utilizar tipos de concesión basados ​​en redireccionamiento (es decir, implícito)

@markokocic respecto a

Autenticación básica a nivel de la aplicación

Esto también es posible con la implementación actual. Puede utilizar el tipo de concesión de credenciales de cliente para obtener un par de tokens en nombre del propietario de la aplicación.

Autenticación básica a nivel de la aplicación

Esto también es posible con la implementación actual. Puede utilizar el tipo de concesión de credenciales de cliente para obtener un par de tokens en nombre del propietario de la aplicación.

@tmkasun
Sí, es posible usar la autenticación básica para generar token usando las credenciales del cliente. Usas algo como esto:

curl -k -X POST https://localhost:8243/token -d "grant_type=client_credentials" -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

Sin embargo, para usar la API, su consumidor aún debe poder:

• generar el token usando el método anterior
• configúrelo como un encabezado http "Autorización" con Bearer y Token para la solicitud de API real
• eventualmente se encarga de la caducidad del token y la actualización

Está bien si un programador programa a su consumidor o si tiene un proveedor que puede hacerlo. Como se describió, el problema es con muchos clientes empresariales heredados que no se pueden personalizar. Por ejemplo, en SAP, si desea consumir un servicio externo, lo único que puede configurar es la URL y, opcionalmente, el nombre de usuario y la contraseña para la autenticación básica. Allí no tiene la capacidad de obtener tokens o establecer encabezados personalizados.

Lo que describí anteriormente como autenticación básica a nivel de aplicación es en realidad la capacidad de omitir el paso de generación de tokens y usar directamente la autenticación básica basada en la credencial del cliente para invocar la API.

Algo como:

curl -k -X POST https://localhost:8243/my/nice/Api/doSomething -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

Esto me permitiría seguir usando el mismo modelo de suscripción de aplicación a API de manera uniforme, sin la necesidad de crear, configurar y administrar usuarios.

Como otro beneficio, dado que el estándar de autenticación básica proporciona la capacidad de incluir un encabezado de autorización como parte de la URL, incluso podríamos admitir consumidores heredados con algo como esto:

curl -k -X POST https://consumer-key:consumer-secret<strong i="25">@localhost</strong>:8243/my/nice/Api/doSomething

EDITAR: Ahora que lo pienso, tal vez el nombre más claro sería Autenticación básica basada en credenciales de cliente para API.