12

ユーザーの Exchange Server アカウント (バージョン 2007 ～ 2013 をサポート) とアプリケーションの間でデータを同期するアプリケーションを構築しています。

ユーザーは任意の数のドメインと Exchange サーバーに存在する可能性があるため、アプリケーションは偽装を使用できません (少なくとも一般的なケースではそうではありません)。

最初にユーザー名/メールアドレスとパスワードを尋ねなければならないことはわかっています。ただし、必要がない場合は、これらの資格情報を保存する責任を負いたくありません (暗号化されていても、したくありません)。

何を質問すればいいのかわからないので、次の質問に答えます。

Exchange Server はどのように認証しますか? ユーザーの資格情報はそのままサーバーに直接送信されますか、それともネットワーク経由で送信される前に一緒にハッシュされますか? それらがハッシュされている場合、連続する認証で再利用するためにこのハッシュを取得/生成するにはどうすればよいですか?

Exchange Server は、後で再利用できる何らかの認証トークンを送信しますか (パスワードの変更または無効化まで永久に)?

問題の解決策を知っていて、これらの質問への回答が対処できない場合は、代わりに提供してください。

4

5 に答える 5

5

Active Directory フェデレーション サービスはまさにそのようなタスクに適しています。あなたはそれについて読むことができます。

于 2013-02-04T20:50:24.623 に答える
1

Kirill が述べたように、ADFS 2.0 はあなたのタスクに最適なソリューションの 1 つです。他の SSO 実装も調べることができます。SSO 実装の主な目標は、複数のアプリケーションに対して単一のログイン状態を維持すること (それにより、アプリケーションごとに複数のログイン プロンプトを減らすこと) ですが、アプリケーションの目標のいくつかは関連しているようです。実装には多少の複雑さが伴うため、sso の実装に向かう前に、すべてのトレードオフについて十分な調査を行ってください。SSO は、将来的に複数のアプリケーションを Exchange サーバーに統合することを検討している場合に最適です。

いくつかの質問に答えるには (同じ順序で - ADFS 2.0 を使用した SSO シナリオを考慮して):

  1. Exchange サーバーへの認証は、ADFS 2.0 を介して行われます (セキュリティ トークン (STS サービス) を提供します - AD/メイン ディレクトリ サービスで認証した後、アプリケーションに)。すべての通信は暗号化され、完全性と機密性のためにトークン署名証明書が使用されます。
  2. ADFS 2.0 によって送信されるセキュリティ トークンの有効期間は、必要に応じて構成および再利用できます。詳細については、このブログ投稿を参照してください。

また、関連する要求値 (ユーザー名や電子メール アドレスなど) のみをアプリケーションに送信するように ADFS 2.0 (フェデレーション サービス) を構成して、データ セキュリティを向上させることもできます。

于 2013-02-11T03:06:01.750 に答える
0

結論

サーバー上で何も構成できない場合、使用する自動生成トークンはありません。残念ながら、Webブラウザと同じ一般的な問題に直面しています。パスワードを保存することです。httpsサードパーティが認証をリッスンするのを防ぐために、認証はSSL（接続）を介して行う必要があることに注意してください。

パスワードストレージの考え：

私の提案は、パスワードを保存するときにいくらか創造的であることです。キー付き暗号化アルゴリズムを使用してから、ハッシュを使用してキーを生成し、キーに何を入れるかを任意に選択できます。これには、デバイスに固有の情報、アプリに固有の情報、Exchangeサーバーに固有の情報の少なくとも3つの情報が必要です。

例えば：

  • デバイスによって指定された一意のID（この値がアプリ固有であるかどうかは関係ありません。単に一貫しているだけです）
  • アプリにコンパイルされた（長い）一連の情報。おそらくインストール固有の値に合わせて入力されます。たとえば、アプリが最初に使用された時刻などです。
  • DNS名や、おそらくより具体的なサーバー情報など、宛先に固有の何か

ユーザーにオプションを提供する場合は、データに追加される何らかの認証PINを使用できます。

このすべてのデータは1バイト配列にまとめられ、ハッシュされます。ハッシュ（またはその一部、またはハッシュサイズとキーの長さに応じて2回）は、パスワードの暗号化のキーとして使用されます。

また、パスワードと一緒にいくつかのチェック情報を含めて、パスワードが正しく復号化されたかどうかをクライアント側でチェックできるようにすることもできます。（間違ったデータがハッシュされた場合、間違ったキーが生成され、間違った結果が復号化から生じます）。

ハッシュに入れるために使用されるすべての情報をデバイスに保存する必要があることに注意してください。そのため、アカウントの使用を承認するためのPINを提案します。

于 2013-02-11T15:34:25.617 に答える
0

ニーズに合わせて機能するSystem.Net.CredentialCacheはずです。はのWebCredentialsラッパーですSystem.Net.NetworkCredential。接続タイプ/ドメインのectに応じて、利用できるSystem.Net.CredentialCache.DefaultNetworkCredentialsか、System.Net.CredentialCache.DefaultCredentials

于 2013-02-04T20:44:34.773 に答える
0

おそらく、このリンクEWS マネージ API を使用して EWSに接続する、Exchange に接続する - 入門チュートリアルをご覧になる必要がありますか? 問題を解決する新しいアイデアが得られることを願っています:)

私が情報を正しく理解していれば、問題を考えすぎるかもしれませんが、私は経験がないので、絶対に間違っている可能性もあります

于 2013-02-11T13:40:51.000 に答える