Authentication のメソッド
| DevKit は、Studio 6 および Mule 3 とのみ互換性があります。Mule 4 Connector を作成するには、 「Mule SDK」ドキュメントを参照してください。 |
API が通常使用する一般的な認証プロトコルはいくつかあります。ほとんどの場合、Anypoint Connector に少なくとも 1 つの認証方法を実装できます。 これらの方法の違いをわかりやすくするため、このドキュメントでは最も一般的な方法のそれぞれについて簡単に説明します。
基本認証
この認証方法では、クライアントがユーザ名とパスワードを入力して認証を証明するように求められます。たとえば、ユーザの Facebook アカウントにアクセスしてユーザの友達が自分の投稿を「いいね!」と言っているかどうかを確認するようにアプリケーションが設計されているとします。これを機能させるには、アプリケーションがユーザのアカウントの個人情報にアクセスできる必要があり、エンドユーザにユーザ名とパスワードの入力を求めることでこれを実現できます。
この認証方法はアプリケーションのニーズを満たしますが、アプリケーションは単に「自分にいいね! と言った」投稿をチェックする以上のことも実行できてしまいます。これを考慮すると、ユーザ名とパスワードのログイン情報を入力することで潜在的に悪質な活動が可能になるため、この方法は許容できない場合があります。
DevKit では、基本認証は接続管理フレームワークを使用して有効化されます。
OAuth 1.0 および 2.0
ユーザ名/パスワード認証の代わりに幅広く使用されているのは、 OAuth (認証のオープン標準) です。OAuth プロトコルでは、サードパーティのアプリケーションで代替の制限付きトークンを使用してリソースへのアクセスを制限できます。たとえばユーザの実際のログイン情報を知らなくてもアプリケーションはユーザのアカウントにアクセスできるため、OAuth を使用して、選択された操作のみを実行するようにアプリケーションを制限します。
他のプロトコルとは異なり、OAuth は Cookie で状態 (接続済みなど) を保持するため、送信する要求ごとにトークン情報を送信する必要はありません。一般的に、API は OAuth の 2 つのバージョンである OAuth 1.0a と OAuth 2.0 のうち 1 つを使用します。それぞれへの接続は若干異なります。
DevKit では、OAuth クライアントログイン情報許可種別はサポートされていません。
詳細は、「OAuth V1」または「OAuth V2」を参照してください。
HTTP 基本認証
HTTP トランザクションのコンテキストでは、基本アクセス認証は HTTP ユーザエージェントが要求を行うときにユーザ名とパスワードを提供する方法です。
詳細は、「HTTP 基本認証」を参照してください。
SAML
SAML (Security Assertion Markup Language) は、サードパーティが ID 提供サービスを提供できる XML のオープン標準です。この手法では、ユーザのパスワードは ID プロバイダ (IdP) のサーバにあります。ユーザが Web サービスへのログインを要求するたびに、Web サービスは IdP に適切なログイン情報を要求します。このソリューションの利点として、セキュリティリスクの最小化 (フィッシングの機会の削減)、ユーザのログインプロセスの簡略化などがあります。
Kerberos
Kerberos は、MIT によって開発され、特に Active Directory によって使用されるオープンで複雑なプロトコルです。SAML と比較すると、適切にセットアップすることは少し難しくなりますが、ID 情報はすべてのフェーズで暗号化されているため、安全でないネットワークを介した通信には理想的です。IdP とサービスプロバイダは、このプロトコルで直接やりとりすることはほとんどありません。ユーザを介して暗号化された情報を互いに送信します。
クライアントは Id プロバイダに対して直接認証します。その後、クライアントにパスワードが付与されますが、Web サービスのみが解読できるキーで暗号化されています。クライアントはこの暗号化されたパスワードを Web サービスに送信します。このパスワードを解読できると、クライアントは IdP によって承認されていると信頼します。
NTLM
NTLM (NT LAN Manager) は、Windows ネットワーク用に Microsoft によって設計された一連のセキュリティプロトコルです。チャレンジ/レスポンス構造で 3 つのメッセージを使用し、NTLM サーバが認証を行います。クライアントは、その機能を公開するネゴシエーションの要求を送信します。NTLM サーバはチャレンジメッセージで応答し、クライアントは認証メッセージで応答します。認証は、2 つのハッシュされたパスワード値、NT ハッシュと LM ハッシュに基づきます。
NTLM は、最新の暗号方式を実装していない古いプロトコルであるため、マイクロソフトでは推奨されていません。Kerberos を実装できないクライアント、またはドメインコントローラを使用できないネットワークに使用されます。Active Directory では、NTLM はデフォルトの認証プロトコルとして Kerberos に置き換えられています。
LDAP
Lightweight Directory Access Protocol (LDAP) は、インターネットプロトコル (IP) 上の分散ディレクトリ情報 (ネットワークユーザ権限情報など) を促進するために公開されている標準です。LDAP 認証を使用する場合、ユーザ名とパスワードは LDAP サーバのデータベースに保存されます。アクセスを認証するエンティティ (サーバ、アプリケーション、Web サービスなど) は LDAP サーバに照会し、その応答に基づいて認証を許可または拒否します。これにより、ユーザ名とパスワードが LDAP サーバのデータベースに保存されるため、エンティティ自体に保存されることを回避できます。
厳密に言えば、認証は接続したエンティティと LDAP サーバの間で行われます。正確な認証方法は、エンティティと LDAP サーバの設定によって異なります。証明書の使用やトランスポート層セキュリティ (TLS) による暗号化など、使用可能な方法はいくつかあります。
ユーザ名とパスワードは、サービスプロバイダではなく LDAP サーバのデータベースに保存されます。正確な認証方法は異なります。証明書の使用やトランスポート層セキュリティ (TLS) による暗号化など、使用可能な方法はいくつかあります。