シングルサインオンとは何ですか
簡単に言えば、それは会社がBシステムへのジャンプが再びBシステムのログを記録することなく、直接アクセスすることができた後、B 2つのシステムが、私はシステムを記録しています。
いくつかの一般的なシングルサインオンの実装
シングルサインオンを説明する前に、最初のいくつかの基本的な概念を説明します。
クッキー：
クッキーは4KBスモールテキストデータは、通常の形式で、ユーザーのローカルに保存されているよりも、これ以上の期間です。
プロパティの有効期限：設定されたCookieの存続
ドメイン属性：Webサイトを指定するか、ドメインにアクセスすることができますクッキーさん
例えば、図ドメイン：192.168.1.72これが唯一の要求の下でのみ1.72はこのクッキーを使用することができることを意味し、あなたがこのクッキーを使用することはできませんどのようなBaiduの
Path属性：ディレクトリを定義するには、クッキーのウェブサイトにアクセスすることができます
図のパスは、そのパス1.72 / webaiknを追加し、このクッキーは限り要求はこのクッキーを持ってデフォルトになりますよう、ルートによって所有されていることを意味/、で、その後のみhttp://192.168.1.72/webaikn/**要求私たちは、このクッキーをもたらすでしょうが、http://192.168.1.72/webadmin/**はこのクッキーを使用することはできません
その他：やや
セッション：
HTTPリクエストはステートレスですが、システムへの私たちの毎日のアクセスが、私は、システムがユーザーを覚えておきたいということであれば、セッションに依存しているために、この時間は達成するために、このようにセッション制御セッションになって、それでも単独のセッションのセッション制御を達成することはできません示すように、クッキーは、コンフィギュレーションを必要と：
キーはJESSIONIDセッションを維持することです、）それはセッションIDサーバでユーザに対応する値であるので、我々は直接HttpSessionのセッション=でrequest.getSession（コードを書き、データだけではない混乱。
シモンズ：セッションがあり、時間を失ったように複数のマシン展開seesionとして、我々の開発を促進するだけでなく、ある程度のトラブルが増加し、
リダイレクト
短い、転送サーバの動作では、クライアントの動作をリダイレクトします。
転送とリダイレクトは、次のような、Javaの背景で実現することができます。
要求を転送します。
request.getRequestDispatcher（ "/ユーザ"）フォワード（リクエスト、レスポンス）。
リダイレクト：
response.sendRedirect（request.getContextPath + "/ユーザ"）
一度転送を設定、要求は転送先アドレスに直接アクセスし、リダイレクトされ、その要求は、最初のクライアントに戻ります、私は、バックグラウンドで設定した場合、その後、ここに新しいアドレス要求に再立ち上げたクライアントは、知識のポイントを隠しますその後、クッキーと時間をリダイレクトするには、実際には、私は、要求が私にクッキーを持参するように設定されているリダイレクト
（1）A及びBは、2つのシステムがサーバ192.168.110.110にデプロイされているものとします
ユーザーがシステムにログインした後にコードビハインド設定、ユーザーのブラウザにクッキーやクッキードメインとして格納されているユーザー名とパスワードが192.168.110.110に設定され、パスは/に設定されています
BのシステムIP Bシステムがクッキーにシステム設定を得ることができますので、我々は、同じであるために訪問した後、それがあるときのみ、インターセプタがログオンしていない場合、ユーザーは、ログインしているかどうかを判断するためにインターセプタを設定する必要があります私たちは、ユーザがB-認識システムにログオンすることはできませんので、情報取得クッキーを要求し、その後、買収後にログオンするためのシミュレーションを復号化するために行ってきました。
コメント：これは、同じドメインのシングル・サインオン実装、非常に大きいの制限、両方のシステムが同一の同じサーバまたはセカンダリドメイン名のケースで達成されなければならない、一般に擬似シングルサインオンと呼ばれるのが典型的です
単一点（2）知識ベースシステムサインオン実装
プログラムの知識は1に基づいて（リバースプロキシは何フォワードプロキシが何であるかを自分で情報を探して、フォワードプロキシを持っているリバースプロキシ）リバースプロキシとしてnginxのを増大させ
webaiknと異なるサーバーに展開WebAdminのが、顧客がしてアクセスnginxのがそうであるように、気づいていない、そしてその後、nginxのでフォワーディング・エージェントを実行するため、ドメイン名が同じであるクッキーを共有することができ、そう、ポイントする必要があるさwebaiknは、マルチマシンの展開であってもよいし、注意してください、そうすることでnginxのは、ユーザー、またはサーバーにアクセスし、次回にサーバーへのアクセスを要求するようにすることです目的はip_hash転送戦略を、設定する必要があり、セッションの損失につながることはありません状況。
コメント：失敗のマルチマシンの展開シングルサインオンを解決するため、まだサーバの一方で、ユーザーのサーバー側のセッション状態を保存する必要がありますが、不均一な流れ、圧力一部のサーバーにip_hashリードを設定する必要があります。一方、メモリ圧を発生しますいくつかのセキュリティ上のリスクは、限り、結果は次の要求に切り捨てられて盗まれたアカウントがあるだろう、比較的大きい。クッキーにユーザー名とパスワード
（3）クロスドメインシングルサインオントークン
主な手順：
- その後、システム上のユーザーがログインなしトークンを使用してディスカバリ要求迎撃システム、シングルサインオン認証センター利用者の前にSSOシステム、アテンション要求URLベルトにリダイレクトされ、我々はoldUrlをコールバック
- SSOはoldUrlを続け、本システムのログインページにリダイレクトされ、その後、クッキーリクエストトークントークン成功したログインには見られない要求を受信します
- ユーザーは、ユーザー名とパスワードを入力し、提出します
- SSOは、ユーザー名には、以下の操作が正しい場合は、ログインページにリダイレクトされ続けるために、正しい正しくないことを確認します。
クッキーを生成し、トークンと呼ばれる名前、値は任意の一意の値、UUID行することができます（クッキーはブラウザやシステムのSSOの間にあることに注意してください）
Redisの中に格納されたユーザ情報は、キーがUUID生成され、値は、ユーザオブジェクトであります
ステッチパラメータトークンに注意を払う、oldUrlをアドレスにリダイレクト
- システムは、トークンがパラメータ、ここで必要なトークン検証のRedisの値に応じてポイントを議論システムを有していることを除いて、再度要求を受信します
見つかりません：操作の取り消しを開始した他のサブシステムの説明を、SSOは、ログインページにリダイレクトする必要があります
発見：あなたは、ユーザーオブジェクトはユーザー権限テーブルには、直接のリリースがあり、現在の要求かどうかを判断できたら、返すために許可のない不足はありません、要求後にリクエストヘッダの情報やURLにトークンを要求します
- ユーザーが周りに行く準備ができて閲覧システムA、システムBが終了したので、ブラウザは、システムBに要求を送信し、システムBがリダイレクトSSOを開始するために、無ディスカバリ要求トークンを使用して、要求インタセプタを受け取った後、この要求を取ることを忘れないでくださいoldUrl
- 実際には、原因以前のSSO署名のことを除いて、この時点では、と同様の上記第二のステップので、この要求は、クッキーのトークンで、それが唯一のライン上のSSO oldUrlの点に対処するためにリダイレクトする必要がありますが、クッキーを取ることを覚えていますURLにトークンのからスプライシング
- B-システムが再度要求を受信した後、ステップ5、および動作は同じです
コメント：独立したシングルサインオン認証センターは、操作を行うための統一された認証局、明快
サブシステムは、サーバ上の負担を軽減し、ユーザーのログイン状態を保存するためにセッションを使用する必要はありません。
各要求は、標準として、トークンを検証することである、要求が傍受された場合でも、ユーザー情報を開示することはありません
後者は、他のシステムへのユーザデータを公開します三者をログに記録する必要がない場合、他のシステムは、（三者が本当に確かにRedisの中で最もシンプルなユーザ情報の一部を保存ログに行う必要があります）のみのトークンを取得することができます
ドアが宝物であるかのように、次のチャートは、私は、何のアドレスを持っていない兄から取られます
