このアイデアは、サーバー側のIMAPクライアントを、IMAP認証を認証用のWeb API(おそらくOAuth?)に変換するラッパーでラップすることです。バックエンドアプリケーションは、資格情報を受信すると、資格情報を保存せずにIMAPに渡し、認証が成功したかどうかを確認し、成功した場合はユーザーのセッションキーとID情報を返します。
これにより、Active Directoryのような堅牢で正式なID管理が欠如している組織でユーザーを認証するための簡単な形式のSSOが提供される可能性があります。
これはすでに存在していますか?資格情報の転送にSSL/TLSが使用されている場合、この設定に関する深刻なセキュリティ上の懸念はありますか?
編集:私はこのメソッドの実装が1つあることを明確にしたいと思います。それは、OAuthとしてWebアプリケーションにそれ自体を表示するので、独自仕様/置き換え不可であることを避けます。私が求めているのは、「IMAPをラップして、OAuthとしてアプリケーションに提示できるようにするため、他の人がいない人のための認証のための有効で斬新で安全なアプローチですOAuthプロバイダー、または電子メールの資格情報が最も重要な資格者は誰ですか? "私は、小規模ビジネスがこのラッパーを認証プロバイダーとして使用できるように、ラッパーをオープンソースプロジェクトに変えるアイデアを試しています。膨大なIDソリューションにお金を払うのではなく、トラフィックの少ないWebアプリのために。
これはすでに存在していますか?
別のサービスを認証するために1つのサービスでログインをチェックするのは一種のハックですが、実際にはそれほど珍しいことではありません。 Postfixメールサーバーは、独自の認証を持つ代わりに、SASLを介して説明するのと同じ方法でIMAPサーバーにチェックするように設定できます http://www.postfix.org/SASL_README.html 。また、悪名高い POP before SMTP もあります。これは、あるサービスに対して正常に認証されてから、別のサービスを使用できるようにすることにも依存しています。
また、IMAPサーバーと連携するRoundcubeのようなユニバーサルウェブメーラーは、ユーザーのログイン時に基本的に同じ方法を使用します。つまり、認証にIMAPサーバーを使用します。
資格情報の転送にSSL/TLSが使用される場合、このセットアップで深刻なセキュリティ上の懸念はありますか?
私が目にする主な点は、単純な実装では、Webを介してメールサーバーに対してサービス拒否が発生する可能性があるということです。 IMAPサーバーは通常、短時間で多数の短時間の接続を処理するのではなく、複数の長時間の接続を並行して処理するように設計されています。したがって、いくつかのレート制限が適切な場合があります。このような制限と、IMAPを使用する場合の比較的遅い認証も、Webアプリケーションのスケーラビリティの問題を引き起こす可能性があります。
技術的には可能です。 IMAPはよく知られ、よく説明されているプロトコルなので、認証を簡単にコーディングできます手動。 telnet mailserver 143
デバッグ用で、私が正しく覚えていれば、それほど難しくはありませんでした...
しかし、私見それは非常に悪い方法です。 Webアプリケーションとフレームワークは、OAuthまたはCAS)のようないくつかのよく知られているSSOプロトコルを一般的にサポートします。これらを使用する際の良い点は次のとおりです。
セキュリティに関しては、一般的にはコーナーケースで欠陥が発生し、一般的によく知られているツールが集中的にテストされるため、自分でロールすることは避けてください。独自の実装をテストするよりもはるかに...