Product-apim: サブスクライバーの基本認証をサポートする

新しくリリースされたAPIM3.0.0は、基本認証をサポートします。 現在、私たちの環境で使用しています。

バックエンドエンドポイントの場合は「はい」。 Apiの場合、オプションが見つかりませんでした。

APIパブリッシャー->ランタイム構成->アプリケーションレベルのセキュリティ

@ Tomas-Mrazek正解です。APIクライアントの基本認証もサポートするようになりました。 上記のように、アプリケーションレベルのセキュリティでBasicオプションを有効にできます。 これにより、APIコンシューマーは、ユーザー名とパスワードの組み合わせを使用してこのAPIを呼び出すことができます。

わかりました、同じ場所を探していたようです。 テストしただけで動作します。

これはより多くの質問をもたらします。

サブスクリプションは基本認証でどのように機能しますか？ サブスクリプションに関係なく、どのユーザーも任意のApiを呼び出すことができるようですか？ ユーザーを特定のアプリケーションに「割り当て」て、アプリケーションがサブスクライブしているAPIのみを呼び出すことができるようにする方法はありますか？

ProdとSandboxの両方が同じゲートウェイを共有している場合、基本認証を実行するときにどちらが呼び出されるかはどのように決定されますか？

基本認証でユーザー名とパスワードの代わりにアプリケーションキーとアプリケーションシークレットを使用する場合、これら2つの質問に答える必要はありません。

何かが足りないので、ドキュメントを教えていただければ幸いです。

サブスクリプションは基本認証でどのように機能しますか？ サブスクリプションに関係なく、どのユーザーも任意のApiを呼び出すことができるようですか？ ユーザーを特定のアプリケーションに「割り当て」て、アプリケーションがサブスクライブしているAPIのみを呼び出すことができるようにする方法はありますか？

いいえ、oauth2トークンと同じように機能するはずです。 サブスクライブされたユーザーのみがAPIを呼び出すことができ、トークン経由か基本認証経由かは関係ありません。

アプリケーションはユーザーに属します。アプリケーションは逆の方法で機能するため、ユーザーをアプリケーションに割り当てることはできません。 よりきめ細かい制御が必要な場合は、/ carbon consoleでロールを作成し、それをユーザーに割り当てます。 APIパブリッシャーで、API設定に移動し、devportalの可視性を特定のロールに変更します。 次に、リソースごとに特定の役割を持つスコープを作成し、このスコープをリソースに割り当てて、セキュリティを有効にします。 サブスクライブされたユーザーはAPIを呼び出すことができますが、ユーザーにロールを割り当てないと、保護されたリソースを呼び出すことはできません。

ProdとSandboxの両方が同じゲートウェイを共有している場合、基本認証を実行するときにどちらが呼び出されるかはどのように決定されますか？

良い質問。 答えはわかりません。

ちなみに、これはコンシューマーキーとシークレットでは機能しません。 エンドポイントは、/ token生成AFAIK中に指定されます。

こんにちは@ Tomas-Mrazekと@tmkasun 、これはまさに今の基本認証に関する私の問題です。 認証についての私の考えを要約してみましょう。

OAuth2-アプリをApiにサブスクライブします。 キーと秘密に基づいて、私たちはアプリと環境を知っています。 したがって、アプリがApiを使用できるようにするには、サブスクライブするだけです。 次に、キーとシークレットを知っていれば、すべてのユーザーがそのApiを呼び出すことができます。

静的Apiキー-ここではキーがわかっているので、どのアプリケーションがApiを呼び出しているか、どの環境を使用しているかを知るのに十分な情報が得られます。 アプリを使用するためにApiにサブスクライブするという概念は引き続き適用されます。 アプリをApiにサブスクライブするだけです。

現在の基本認証-これを「ユーザーベースの基本認証」と呼びます。 アプリとサブスクリプションの概念を完全に放棄し、異なる概念（ユーザーベースのアクセス許可）と、PublisherまたはStore / DevPortalの代わりにCarbonadminを使用するなどの異なるツールを使用する必要があります。 また、単一のゲートウェイが両方に使用されている場合、本番環境とサンドボックス環境を区別することはできません。 また、セットアップと管理がさらに複雑になります。 サブスクライブされたアプリのリストを確認するだけでは不十分です。また、carbon adminにアクセスして、ユーザーと権限を確認する必要があります。 また、Apiの特定のアプリのレート制限をしたい場合、またはサブスクリプションレベルが異なる場合、ユーザーに対してそれを行うことはできません。

基本認証をサポートする「正しい」方法として私が見るものは次のとおりです。

アプリレベルの基本認証-（静的キーのように）ユーザーを概念から外し、代わりにアプリケーション認証を使用します。 アプリケーションはまだApiにサブスクライブする必要があります。 コンシューマーキーとコンシューマーシークレットは、基本認証の資格情報として使用されます。 そうすることで、App / Apiサブスクリプションの概念を維持し、他のすべてと同じツール（パブリッシャー/ devPortal、Carbon Adminは不要）を引き続き使用でき、キーに基づいてどのアプリがどのApiとどの環境を使用するかがわかります。

そこに着く方法？

2つのオプションがあります。 現在の基本実装を上記で提案されたものに変更するか、「アプリ基本認証」と呼ばれる新しい実装を実装します。
既存の基本認証でユーザー/パスとキー/シークレットの両方をサポートする3番目のオプションもありますが、これが最も汚いオプションです。

基本認証の実装だけでは不十分です。 たとえば、Carbonコンソールを介して作成してユーザーに関連付ける必要があるロール->に基づいて、devportalでのAPIの可視性を制限できます。

こんにちは@ Tomas-Mrazekと@markokocic
あなたの提案をありがとう、インラインで私の答えを見つけてください。

サブスクリプションは基本認証でどのように機能しますか？ サブスクリプションに関係なく、どのユーザーも任意のApiを呼び出すことができるようですか？ ユーザーを特定のアプリケーションに「割り当て」て、アプリケーションがサブスクライブしているAPIのみを呼び出すことができるようにする方法はありますか？

クライアント要求の基本認証サポートでは、サブスクリプションが存在する必要はありません。 API作成者が特定のAPIの基本認証サポートを有効にしている場合、そのAPIをサブスクライブせずに（アプリケーションごとに）呼び出すことができます。
@markokocicはい、サブスクリプションの仕組みは、 An Application subscribed to an APIです。

さらに、Baisc authを使用すると：
あなたはまだ得ます：

• リソースレベルまたはAPIレベルのスロットリング
• リソーススコープの検証

あなたは得られません：

• サブスクリプションレベルの調整
• 本番環境とサンドボックス環境の差別化

ProdとSandboxの両方が同じゲートウェイを共有している場合、基本認証を実行するときにどちらが呼び出されるかはどのように決定されますか？

はい、ユーザー名とパスワードで環境を区別できませんでした。したがって、基本認証を使用する場合、環境を選択するオプションはありません。本番エンドポイントが使用されます。

@ Tomas-Mrazek

エンドポイントは、/ token生成AFAIK中に指定されます。

いいえ、エンドポイント（Prod＆Sandbox）はAPIの作成時にAPI作成者によって定義されます。APIコンシューマーは、リダイレクトベースの付与タイプを使用する場合にアプリケーションのコールバックURLを提供できます（つまり、暗黙的）

@markokocicに関する

アプリレベルの基本認証

これは、現在の実装でも可能です。 クライアント資格情報付与タイプを使用して、アプリケーション所有者に代わってトークンペアを取得できます。

アプリレベルの基本認証

これは、現在の実装でも可能です。 クライアント資格情報付与タイプを使用して、アプリケーション所有者に代わってトークンペアを取得できます。

@tmkasun
はい、基本認証を使用して、クライアントの資格情報を使用してトークンを生成することは可能です。 次のようなものを使用します。

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

ただし、APIを使用するには、コンシューマーが次のことができる必要があります。

• 上記の方法を使用してトークンを生成します
• 実際のAPIリクエストのベアラーとトークンを含むhttp "Authorization"ヘッダーとして設定します
• 最終的にトークンの有効期限と更新を処理します

プログラマーが消費者をプログラムするか、それを実行できるベンダーがあれば問題ありません。 説明したように、問題はカスタマイズできない多くのレガシーエンタープライズクライアントにあります。 たとえば、SAPで外部サービスを利用する場合、設定できるのはURLと、オプションで基本認証用のユーザー名とパスワードだけです。 そこでは、トークンをフェッチしたり、カスタムヘッダーを設定したりすることはできません。

上記でアプリレベルの基本認証として説明したのは、実際にはトークン生成のステップをスキップし、クライアントの資格情報に基づいて基本認証を直接使用してAPIを呼び出す機能です。

何かのようなもの：

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

これにより、ユーザーを作成、設定、管理することなく、同じApp toAPIサブスクリプションモデルを統一された方法で使用できるようになります。

もう1つの利点として、基本認証標準ではURLの一部として承認ヘッダーを含めることができるため、次のようなレガシーコンシューマーをサポートすることもできます。

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

編集：私がそれについて考えると、おそらくより明確な名前は、APIのクライアントクレデンシャルベースの基本認証でしょう。