web-dev-qa-db-ja.com

同じWebアプリケーションコンテキスト内の複数のシステム/プラットフォーム間の認証

次のシナリオを検討してください： Webアプリケーションは2つの別々のシステムを使用しています（DBを介してデータ/状態を共有できます）。 1つ目は、HTTPリクエスト/レスポンス、HTMLコンテンツ、フォームなど、関連するすべての標準的なWeb処理に使用されます。 2番目は、メッセージや通知の送信などのリアルタイム通信に使用されます（ロングポーリングまたはWebSocketサーバー）。

ユーザーは最初のシステム/プラットフォームを介して認証され、資格情報が有効な場合、一部のWebページがクライアントに返送されます。このページが読み込まれると、クライアントはバックグラウンドで透過的に2番目のシステム/プラットフォームに接続されます。

質問は：バックエンドの複数のシステム/プラットフォームで構成されるWebページ/アプリケーションでユーザーを認証する方法？

私はそれをこのように想像することができます：

  1. ユーザーが最初のシステム/プラットフォームを介して認証されると、GUIDトークンが生成され、一部のユーザーにバインドされたデータベースに格納されます。このトークンとユーザーIDは、応答でクライアントに送信され、たとえば、非表示フィールドのページにレンダリングされます。
  2. ページが読み込まれ、2番目のシステム/プラットフォームとの接続が行われると、非表示フィールドからトークンとユーザーIDが取得され、接続リクエストのパラメーターとして送信されます。バックエンドはユーザーを見つけ、データベースでトークンを比較し、一致する場合はリアルタイム接続を開始できます。

このアプローチは、たとえば盗聴に対して脆弱であることを理解していますが、私は特に、2つの別個のシステム/プラットフォーム間の認証手順に興味があります。

web-applicationauthenticationjavascript
14
yojimbo87
  • ログイン時にセッショントークンを生成します。
  • そのセッショントークンをデータベースに保存します。
  • 認証時に有効なセッショントークンを確認します。

あなたが持っているもののほとんど。一度に複数の有効なセッションが必要かどうか、およびセッションの期限切れをどうするかを検討してください。

以下のクレイジーなコメントスレッドの編集

1番目のサーバーと通信せずに2番目のサーバーによって検証されるトークンをクライアントに提供することはできますが、醜く、多くの作業を伴います。このようなシナリオでは、クライアントが処理しない限り、セッションを無効にすることはできません。トークンが渡されるとき、トークンのタイムスタンプ、2番目のシステムによるトークンの追跡、トークンの通過における署名またはHMACなどの特定の時間枠も必要です。これら2つのシステムがインターネット上でお互いを認識できない場合を除き、それは完全に混乱しています。

私は両方のシステムが同じデータベースにアクセスできることを収集しますが、何らかの理由でアクセスできなかった場合、リモートで検証できる2番目のシステムにAPIを公開することも適切です（secret.page?checkUser=token ...またはそのような）。

SSLなしでは、Firesheep/MITM攻撃によるセッションハイジャックを防ぐ方法はありません。

10
Jeff Ferland

私の推奨は、プライマリユーザー認証に使用される単一のWebアプリです。

注：Cookieの性質上、この方法はWebアプリケーションが共通のドメインを共有している場合にのみ機能します。 （つまり、appone.example.comとapptwo.example.com）
openidは同様のことを行いますが、Cookieの問題を回避します。

これがどのように機能するか

  1. ユーザーはブラウザをアプリAに向けます。アプリAは有効なCookie /セッション/何でも確認します。
    1. まず、自身のセッション/ Cookie情報を確認します。
    2. 自分のCookieが見つからない場合は、Authアプリの「転送」Cookieを探します。
      1. 見つかった場合は、このアプリの新しいセッションを作成します。ユーザーがログインしました。
  2. これが無効または欠落していることが判明した場合は、ページを認証アプリに転送します。
  3. 認証アプリは、終了時に有効なセッションをチェックします。
    1. この欠落を検出すると、ログイン画面などが表示されます。
  4. 有効なセッションが確立されると、認証アプリはそのアプリに特定の「転送」Cookieを設定し、ユーザーをアプリAにリダイレクトします。

-などの追加情報をこの転送Cookieに入れる必要があります

  1. username
  2. AuthTime
  3. IPアドレス。
  4. 乱数。

例については、以下を参照してください。 https://www.login.mtu.edu/docs/public/mtuiso/howitworks2.html

これは、ユーザーの観点からはほとんど見た目が悪くなります。たとえば。

  1. ユーザーがブラウザをアプリAに向けます。
  2. App Aは、Auth Appで認証ダンスを行います。 （ユーザーにログインを要求するなど）
  3. ユーザーがアプリBに転送するリンクをクリックします。
  4. App Bは、Auth Appで認証ダンスを行います。 （今回は、Authアプリはすでにそれ自体にCookieを持っています。）
    1. アプリBは認証アプリに転送します。
    2. AuthアプリはCookieを見つけ、すぐに転送Cookieを作成してApp Bに転送します。
    3. ユーザーはこれに気付かず、すぐにApp Bに移動します。
0
user606723

4つのオプション、1つ目は最大コスト（お金とパフォーマンスの両方）、3つ目は最も安い

  1. Siteminder、Novell、Tivoliなどのソリューションを導入

  2. DBでのセッション状態の維持。これを行うため。このアプローチの問題は、ログアウト、セッションの有効期限を追跡し、2つのアプリケーション間でこの情報を伝達することが難しいことです。各リクエストの前にDBをクエリすると、非常にコストがかかるため

  3. セッション状態を管理するためだけにサードアプリケーションを使用する。このアプリケーションは、2つのアプリケーションにのみアクセスできるネットワーク内でのみ制限されているエンドユーザーに公開されません。すべてのユーザーの状態をアプリケーションコンテキストに保存し、2つのアプリケーションがこのアプリケーションにリクエストを送信します

    ログインイベント時ログアウトイベント時セッションの有効性を確認する要求を処理する前のセッション期限切れイベント時

  4. Cookieの使用（両方のアプリケーションが同じ親ドメインを共有することを前提としています）

    ユーザー名+ソルト/エクレットキーを含むCookieを作成し、この暗号化された秘密キーと暗号化キーは両方のアプリケーションで使用されますユーザーは他のアプリケーションにログインしています

0
Sachin Kumar