序文
シングルサイン広範囲の現在のシステムアーキテクチャでは、彼は複数のサブシステムを開きます認証システムは、複数のエントリの使用を実装し、シングルサインオンアーキテクチャでは、いくつかのマイナーな問題が発生しますが、異なるアプリケーション環境は、需要を満たすためにさまざまなシングルサインオンの実装を使用することができます。
共有セッション
セッションを共有することで、シングルサイン最も直接的かつ簡単な方法を達成するために言うことができます。セッションに格納されたユーザ認証情報、すなわち、ユーザクレデンシャル、セッション内に格納された値は、ユーザ認証に、容易に単一のサイト内で実施することができる使用することが通常であり、ユーザのサービスアプリケーション情報管理シナリオを分離しますその経験の問題シングルサインオン、シンプルなアプリケーションシステムの下で、まれなケースをサブシステムは、この問題に対処するためにセッションを共有する方法が考えられます。
フレームワークは、私はRedisのに基づいてセッション共有スキームを使用しています。セッションはRedisの上に格納され、その後、Cookieドメインの全体のグローバルシステムはトップレベルのドメイン上に配置され、そのようなセッションIDは、様々なサブシステム間で共有することができます。分散セッション共有ソリューションは、私はこれを見てお勧めします。
プログラムのすべての最初の深刻なスケーラビリティの問題、そこにある、ストレージのASP.NETのセッションがSessionStateItemCollectionオブジェクトである必要があり、構造が暗号化されたストレージのシーケンスの後に保存されています。
ユーザーがアプリケーションにアクセスするときや、彼が最初に行うの容器のすべての内容がすべて出ている、とSessionStateItemCollectionオブジェクトをデシリアライズ格納することです。
これは、彼は次の制約があることを判断します。
1.Sessionが関与して入力し、共同のサブシステムに所有されている必要があり、多くの制限があるため、使用対象のセッションをリードしている、（すなわちアセンブリを、タイプに一貫性が必要です）。
2.に対処する完全にできないクロスのTLD。
第二に、OpenIDのベースのシングルサインオン
そのようなシングルサインオンするときのOpenIDは複数のC / SとBのためのユーザ設定のOpenIDによれば、サーバにサーバ認証情報を転送サブシステムにログオンユーザのID情報は、クライアントのOpenIDに格納されて簡素化します次のように合成処理/ Sシステムです。
図からわかるように、この送信は、ベースOpenIDの記憶および伝送することが確認シングルサインOpenIDを、に依存しています。
1.ユーザーがログインする最初の時間は、ユーザー名とパスワードは、認証サービスに送信されます。
2.サービスの利用者識別のOpenIDは、クライアントに返すことを確認します。
3.クライアントが保存されています。
4.アクセスサブシステム、OpenIDのを送信するためのサブシステムと、
5.サブシステムのOpenID認証サービスに転送しました。
6.ユーザ認証サービスは、サブシステムに認証情報を返します。
ユーザーの認証情報の内容を確認7.サブシステムは、クライアントに返されます。
このシングルサインオン認証メカニズムは、彼の下のC / Sの構造にある主な問題は、ユーザーのOpenIDクライアントに格納され、これを行うには、サブシステム間、およびB / SモードではOpenIDを送信することに基づいて、より困難になります。この問題に対処するために、我々は、B / Sモード、配信の問題の下に格納されているのOpenIDを解決するため、このように、道をリードします。
第三に、クッキーベースのストレージ・ソリューションのOpenID
当社は、クッキーの役割は、一般的なa.xxx.comやクッキーのb.xxx.comお互いにアクセスすることができないとして、セグメンテーションに基づいてサーバーブラウザの終了と終了、およびCookieのドメイン名の情報を情報伝達のキャリアとして機能することであることを知っていますしかし、サブドメインは、アクセス可能なクッキーより高いレベルのドメイン名です。そのa.xxx.comとb.xxx.comクッキーxxx.com下でアクセス可能であるので、OpenIDのキャリアとしてクッキーのトップレベルドメインにできるようになります。
そして、この方法の第2の検証ステップは非常に似ています。
1.で認証サービスサイトを提供するために、ログオンします。
2、で記述されたトップレベルドメインクッキーのOpenID。
3、アクセスサブシステム（OpenIDのとでクッキー）
4、撮影したOpenIDのサービスサブシステムは、検証のOpenIDを通じて送信します
図5に示すように、ユーザ認証情報を返します
6、返品承認コンテンツの後
両方の方法では、型のデカップリングOpenIDのセッション共有方式を介して見ることができるように、ユーザ認証情報のより柔軟な構成は、サブシステム間の認証は、互いに独立しているが、第3の実施形態における、我々はすべてのサブシステムは、実際の生産環境、複数のドメイン名は正常なことですが、その後、あなたはクロスドメインの問題を解決する方法を正確に検討する必要があり、トップレベルドメインと同じ仮定に基づいています。
四、B / S単一点登録処理、マルチドメイン環境下
複数のトップレベルドメインの場合は、我々は、各サブシステムのOpenIDのシェアを許可しません。最初にすべての私たちはJSONPプログラムを考える必要があり、B / Sの環境下でクロスドメインの問題に対処。
次の手順を確認します。
1、サブシステムをロギングすることで、ユーザーにログインするユーザ名。
2、ユーザのログイン・サブシステムは、ユーザーのログイン状態を記録し、その他の情報のOpenID。
3、利用者は、サービス・サブシステムを使用しています。
4、ユーザーがビジネスユーザーは、ユーザーログオンサブシステムにジャンプしますサブシステムをログに記録されていない場合。
図5に示すように、ユーザインターフェースサブシステムJSONPパスOpenIDのユーザ・サービス・サブシステム。
6、OpenID認証サービスを呼び出すことによって、ビジネス・サブシステム。
図7は、認証サービスは、認証情報サービスサブシステム・コンフィギュレーション・ユーザ・ログイン資格証明を返し、（ユーザがクライアント情報サービスサブシステムを確認する必要がある1に対応されています）
8は、その結果、ユーザーがログオンが成功したユーザログインがサービス・サブシステムに戻ってジャンプした場合、サブシステムをログに記録するユーザーに返さ。
9、クライアントへ戻る承認の内容。
第五に、セキュリティ上の問題
上記の手順の後、クロスドメインのログインの問題の場合は、単一の点が解決されている可能性があります。初期の頃開発プロセス全体では、我々はユーザーのOpenIDのOpenIDを保存するために、ユーザテーブルレコードのフィールドを使用しますが、このメカニズムは明らかである、いくつかのセキュリティ、スケーラビリティの問題があります。主に1点でこのスケーラビリティの問題：OpenIDでの矛盾のセキュリティとユーザー体験。
メカニズム全体のシングルサインはOpenIDのは、期限切れのメカニズムを持っているユーザーの端末のログインがたびにユーザー・ログまたはたびに終了を選択できる場合場合OpenIDの時間をリフレッシュし、マルチ端末にログインする必要がありので、OpenIDのは、クライアントに表示されます決定します場合の矛盾が存在します：端末はOpenIDを他の端末が正常に許可されていない。リフレッシュとき。
そして最後に、私はシングルユーザーマルチのOpenIDのソリューションを使用していました。ユーザー名/パスワードを介して各時間ユーザにRedisの中に格納され、有効期限を設定するのOpenIDを生成する、複数のOpenIDに対応する端末ログが複数となるように、もはや端末認証が存在しているすべての障害のOpenID障害が発生した場合。
遂に
私は、データのコンパイルが内側になり、記事が更新される中でみんなの注目公共の群れ番号[プログラマ]を、お待ちしております。