XML-RPC仕様に正確に準拠しているわけではありませんが、概念はほぼ同じです。クライアントは、XMLペイロードを使用してHTTP/HTTPS経由で着信します。リクエストに応答するXMLペイロードで応答します。これは主にマシン間で行われるため、ユーザー名/パスワードを入力する人は誰もいません。私たちのコンストラクトはapachetomcat内で実行されます。リクエストを認証したいと思います。すべてのクライアントがすべてのサービスを利用できるわけではないため、リクエストも承認する必要があります。サブスクリプションと使用ごとの課金モデルの両方があるため、すべてをログに記録する必要があります。
サーバーとクライアントの両方に何をお勧めしますか？
HTTP BASIC/DIGEST は、ほとんどのマシン ツー マシン タスクで正常に機能し、サーバーによって処理されるため、API は影響を受けません。
ブラウザを閉じずにユーザーを「ログアウト」するのは難しいため、インタラクティブな使用には適していません。
それ以外の場合は、ほとんどの場合、API を変更して認証情報を含め、メソッドでコード内でそれを認証する必要があります。
または、従来の「ログイン」を使用して、Cookie を設定し、セッションを維持することもできます。
しかし、率直に言って、マシン間の作業では、HTTP BASIC が最も簡単です。
編集、コメントについて。
HTTP BASIC は、認証に必要なアーティファクトを提示するために使用される単なるプロトコルであり、マシン ツー マシンの Web サービスに適しています。
どのように実装されるかは、あなたとあなたのアプリケーションに依存します。Java を使用すると、コンテナ認証を使用でき、認証とロール マッピングが提供されます。ユーザー -> ロール マッピングは、データ ファイルまたはデータベースのいずれかで処理されます。保護される URL と、各 URL で有効なロールは、web.xml によって管理されます。
異なる URL に異なるロールを追加し続ける場合は、そのアプリケーションを再デプロイする必要があります。
ただし、新しいユーザーを追加するだけの場合は、ファイルまたはデータベースを更新するだけです。新しいロジックとこの新しい URL を追加する場合は、再デプロイする必要があります。十分に細かい粒度の ROLE 構造がある場合は、実際に新しいメソッドを追加するまで、web.xml をいじる必要はありません。たとえば、極端な場合、メソッドごとにロールを作成し、それらを個別にユーザーに割り当てることができます。ほとんどの場合、そこまでする必要はありません。
コンテナー認証を使用したくない場合は、サーブレット フィルターを記述して、ユーザーとロールを URL にマッピングするというビジョンを実装します。独自の機能を実装した場合でも、クライアントに HTTP BASIC プロトコルを使用できます。
全体的な汎用 Java セキュリティ フレームワークを探している場合は、Google に任せます。いくつかありますが、私はそれらのいずれも使用していません。私はコンテナー認証と独自の作成に成功しました。
@意思
私は HTTP Basic の提案を支持し、それが独自の DB ベースの認証/承認ロジックを展開するレガシー アプリケーションの上に実装したSpring Securityとかなりうまく統合されていることを証明できます。