Product-apim: Suporte à autenticação básica para assinantes

O APIM 3.0.0 recém-lançado oferece suporte a autenticação básica. Atualmente, usamos em nosso ambiente.

Sim para endpoints de back-end. Para Api, não consegui encontrar a opção.

Publicador de API -> Configurações de tempo de execução -> Segurança de nível de aplicativo

@ Tomas-Mrazek correto, agora oferecemos suporte à autenticação básica para clientes API também. Você pode habilitar a opção Basic na segurança em nível de aplicativo, conforme mostrado acima. Isso permitirá que os consumidores da API invoquem esta API usando sua combinação de nome de usuário e senha.

Ok, parece que eu estava olhando para o mesmo lugar. Apenas testei e funciona.

Isso traz mais perguntas.

Como as assinaturas funcionam com autenticação básica? Parece que qualquer usuário pode invocar qualquer Api, independente de assinaturas? Existe uma maneira de "atribuir" usuários a aplicativos específicos para que eles possam invocar apenas a API para a qual o aplicativo está inscrito?

Se Prod e Sandbox compartilham o mesmo Gateway, como é determinado qual deles é chamado ao fazer autenticação básica?

Essas duas perguntas não precisariam de uma resposta se fôssemos usar a chave e o segredo do aplicativo em vez de nome de usuário e senha na autenticação básica.

Talvez eu esteja faltando alguma coisa, então seria bom se você pudesse me indicar a documentação.

Como as assinaturas funcionam com autenticação básica? Parece que qualquer usuário pode invocar qualquer Api, independente de assinaturas? Existe uma maneira de "atribuir" usuários a aplicativos específicos para que eles possam invocar apenas a API para a qual o aplicativo está inscrito?

Não, ele deve funcionar da mesma forma que o token oauth2. Apenas o usuário inscrito pode invocar a API, não importa se por meio de token ou autenticação básica.

Você não pode atribuir usuários a aplicativos, porque funciona da maneira oposta - os aplicativos pertencem ao usuário. Se você quiser um controle mais refinado, crie funções no console / carbon e atribua-as aos usuários. No editor da API, vá para as configurações da API, altere a visibilidade no devportal para uma função específica. Em seguida, crie escopos com função específica para cada recurso, atribua esse escopo ao recurso e ative a segurança. Os usuários inscritos podem chamar a API, mas sem você atribuir uma função ao usuário, eles não podem chamar nenhum recurso protegido.

Se Prod e Sandbox compartilham o mesmo Gateway, como é determinado qual deles é chamado ao fazer autenticação básica?

Boa pergunta. Eu não sei a resposta.

A propósito, isso não funcionaria com a chave e o segredo do consumidor. O endpoint é especificado durante / geração de token AFAIK.

Olá, @ Tomas-Mrazek e @tmkasun , este é exatamente o meu problema com a autenticação básica agora. Deixe-me tentar resumir minhas idéias sobre a autenticação:

OAuth2 - nós assinamos o App para um Api. Com base na chave e no segredo, conhecemos o App e o Meio Ambiente. Portanto, para permitir que o App use o Api, tudo o que precisamos fazer é assiná-lo. Então, qualquer usuário pode chamar aquela Api desde que conheça a chave e o segredo.

Chaves de API estáticas - aqui conhecemos a chave e isso fornece informações suficientes para saber qual aplicativo está chamando a API e qual ambiente ela usa. O conceito de inscrição do App na Api para usá-lo ainda se aplica. Precisamos apenas inscrever o App em um Api.

Autenticação básica como está agora - vou chamá-la de "autenticação básica baseada no usuário". Abandona completamente o conceito de aplicativo e assinatura e requer o uso de conceitos diferentes (permissões baseadas no usuário) e ferramentas diferentes, como o Carbon admin em vez de Publisher ou Store / DevPortal. E ele não consegue distinguir entre ambiente de produção e ambiente de área restrita quando um único gateway é usado para ambos. Ele também oferece um nível adicional de complexidade para configurar e administrar. Agora não é suficiente olhar para a lista de Apps assinados, é preciso ir ao carbon admin e olhar os usuários e permissões. E se eu quiser limitar a taxa de um aplicativo específico para uma API, ou ter diferentes níveis de assinatura, não posso fazer isso para o usuário.

O que eu veria como uma maneira "correta" de oferecer suporte à autenticação básica seria o seguinte:

Autenticação básica no nível do aplicativo - Tiramos o usuário do conceito (como com chaves estáticas) e usamos a autenticação do aplicativo em seu lugar. O aplicativo ainda precisa se inscrever no Api. A chave do consumidor e o segredo do consumidor são usados ​​como credenciais de autenticação básicas. Dessa forma, mantemos o conceito de App / Api Subscription, podemos continuar usando as mesmas ferramentas de todo o resto (publisher / devPortal, sem necessidade de Carbon Admin), e sabemos qual App usa qual Api e qual ambiente com base nas chaves.

Como chegar lá?

Existem duas opções. Altere a implementação básica atual para a proposta acima ou implemente uma nova chamada "Autenticação básica do aplicativo".
Há também uma terceira opção, para oferecer suporte a usuário / senha e chave / segredo na autenticação básica existente, mas essa é a mais suja.

A implementação do Basic Auth não é suficiente. Por exemplo, você pode limitar a visibilidade da API no devportal com base em funções -> que precisam ser criadas e associadas ao usuário por meio do console do Carbon.

Olá, @ Tomas-Mrazek e @markokocic
Obrigado por suas sugestões, por favor, encontre minhas respostas inline.

Como as assinaturas funcionam com autenticação básica? Parece que qualquer usuário pode invocar qualquer Api, independente de assinaturas? Existe uma maneira de "atribuir" usuários a aplicativos específicos para que eles possam invocar apenas a API para a qual o aplicativo está inscrito?

O suporte de autenticação básico para solicitações de cliente não exige a presença de assinaturas. Se um criador de API ativou o suporte de autenticação básica para uma API específica, essa API pode ser chamada sem se inscrever nessa API (por aplicativo).
e @markokocic sim, como funciona a assinatura, An Application subscribed to an API .

Além disso, com Baisc auth:
você ainda tem:

• Nível de recurso ou limitação de nível de API
• Validação de escopo de recurso

você não vai conseguir:

• Limitação do nível de assinatura
• Diferenciação de ambiente de produção e sandbox

Se Prod e Sandbox compartilham o mesmo Gateway, como é determinado qual deles é chamado ao fazer autenticação básica?

Sim, não foi possível diferenciar o ambiente por nome de usuário e senha, portanto, ao usar autenticação básica, você não terá a opção de selecionar o ambiente, será usado o endpoint de produção.

@ Tomas-Mrazek

O endpoint é especificado durante / geração de token AFAIK.

Não, os Endpoints (Prod e Sandbox) são definidos pelo criador da API ao criar a API, os consumidores da API podem fornecer um URL de retorno de chamada para um aplicativo se quiserem usar tipos de concessão baseados em redirecionamento (i: e implícito)

@markokocic sobre

Autenticação básica no nível do aplicativo

Isso também é possível com a implementação atual. Você pode usar o tipo de concessão de credenciais do cliente para obter o par de tokens em nome do proprietário do aplicativo.

Autenticação básica no nível do aplicativo

Isso também é possível com a implementação atual. Você pode usar o tipo de concessão de credenciais do cliente para obter o par de tokens em nome do proprietário do aplicativo.

@tmkasun
Sim, é possível usar a autenticação básica para gerar token usando credenciais de cliente. Você usa algo assim:

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

No entanto, para usar a API, seu consumidor ainda precisa ser capaz de:

• gere o token usando o método acima
• defina-o como um cabeçalho http "Authorization" com Bearer e Token para a solicitação de API real
• eventualmente, cuidar da expiração e atualização do token

Não há problema se um programador programar seu consumidor ou se você tiver um fornecedor que possa fazer isso. Conforme descrito, o problema é com muitos clientes corporativos legados que não são personalizáveis. Por exemplo, no SAP, se você deseja consumir serviço externo, a única coisa que pode definir é a URL e, opcionalmente, o nome de usuário e a senha para autenticação básica. Lá você não tem a capacidade de buscar token ou definir cabeçalhos personalizados.

O que descrevi como autenticação básica no nível do aplicativo acima é, na verdade, a capacidade de pular a etapa de geração de token e usar diretamente a autenticação básica com base na credencial do cliente para invocar a API.

Algo como:

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

Isso me permitiria ainda usar o mesmo modelo de assinatura de App para API de maneira uniforme, sem a necessidade de criar, configurar e gerenciar usuários.

Como outro benefício, uma vez que o padrão de autenticação básico fornece a capacidade de incluir cabeçalho de autorização como parte do URL, poderíamos até mesmo oferecer suporte a consumidores legados com algo assim:

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

EDIT: Agora que pensei sobre isso, talvez o nome mais claro seria Autenticação básica baseada em credenciais de cliente para API.