- セッションナレッジポイント
httpプロトコルはステートレスであるため、100回の連続訪問と1回の訪問に違いはなく、メモリもありません。そのため、ユーザーがWebサイトにアクセスするたびに一度ログインすることを許可することはできません。そのため、セッションスキームが提案されています。
Cookieとセッションを介してユーザーのセッションを確立し、ユーザーが正常に承認されたときにCookieをユーザーに提供します。これが唯一のセッションIDです。たとえば、PHPは、セッションを確立するユーザーにデフォルトでphpsessidという名前を設定します。phpsessidはCookieに保存され、クライアントに返されます。次にユーザーがこのCookieを要求すると、サーバーはその要求がリクエストされました。もう一度ログインしてください。
では、ユーザー情報を表示するにはどうすればよいのでしょうか。情報はどこにありますか。現時点では、メモリ、ファイル、またはデータベースを使用できます。データはユーザーのセッションIDで取得できる必要があります。たとえば、phpはセッションIDabcのユーザーセッションデータを/ tmp / phpsess_abcに保存します。デフォルト。1]ファイルでは、ファイルを読み取るたびに、プログラムが理解できるデータを逆シリアル化する必要があり、書き込み時に永続データ形式にシリアル化する必要があります。
セッション共有を実現する方法は？
Webサイトが1台のマシンに保存されている場合、セッションデータはこのマシンにあるため、この問題は発生しませんが、負荷分散を使用して別のマシンにリクエストを分散するとどうなりますか？現時点では、クライアント側のセッションIDに問題はありませんが、ユーザーが2台の異なるマシンに2つのリクエストを送信し、そのセッションデータが一方のマシンに存在する可能性がある場合、この時点ではセッションデータは利用可能です。したがって、セッション共有が問題になります。
実際、構成ファイルを介したSQLサーバーへのセッションのストレージメディアの変更をサポートするasp.NETなど、さまざまなWebフレームワークがこの問題をすでに考慮しています。すべてのマシンのセッションデータは同じデータベースから読み取られるため、不整合はありません。問題; phpはセッションデータのmemcacheサーバーへの保存をサポートしています。また、ファイルのマシン間共有を実現するために、セッションファイルが保存されるディレクトリをnfsネットワークファイルシステムに手動で変更することもできます。
セッション情報が頻繁に変更されない場合に使用できる簡単な方法もあります。マシンaがユーザーセッションをセットアップするときに、セッションデータをマシンbのcgiに送信し、マシンbのcgiがセッションデータを保存します。マシンaとbの両方がセッションデータの同じコピーを持つように
（SessionStorage、同じセッション内のページにのみアクセスでき、セッションが終了するとデータも破棄されるため、sessionStorageは永続的なローカルストレージではなく、セッションレベルのストレージのみです。同じウィンドウのみが
loacalStorageにアクセスできます。永続的なローカルストレージに使用されます。データがアクティブに削除されない限り、データが期限切れになることはありません。同じソースがlocalStorageデータを読み取って変更できます）
- トークン認証とセッションは2つの
方法で実装されます：
数日前にspringbootセキュリティプロジェクトを調査し、ソースコードを分析しました。トークンのログイン認証メカニズムが内部で使用されています。主な使用プロセスは上図のとおりです。ログイン後、セキュリティに応じてセキュリティアルゴリズムは（JWTに基づいて）一意のトークン値を生成し、それをredisに格納し、有効期限を設定してから、トークン値をフォアグラウンドに返し、localStorageに保存します。にアクセスして、検証としてトークンを送信する必要があります。検証後にインターフェイスにアクセスできます。
セッション方式：
1。サーバーセッションは、ユーザーが初めてアプリケーションにアクセスしたときにサーバーによって作成されるオブジェクトであり、ユーザーのセッションを表し、データの保存に使用できます。サーバーは、各セッションに一意のセッションIDを割り当てて、各ユーザーが異なるセッションオブジェクトを持つようにします。
2.サーバーがセッションを作成すると、Cookieを介してセッションIDがユーザーのブラウザーに返されるため、ユーザーが2回目以降にサーバーに要求を送信すると、セッションIDがサーバーに返送されます。サーバーのCookieを介してユーザーに対応するセッションオブジェクトは、セッションIDに従って見つけることができます。
3.セッションには通常、2時間などの有効期限設定があります。有効期限が切れると、サーバーは前のセッションを破棄し、新しいセッションを作成してユーザーに返します。ただし、ユーザーが有効期限内にサーバーに新しいリクエストを送信する限り、通常、サーバーは対応するセッションの有効期限を現在のリクエスト時間に基づいてさらに2時間延長します。
4.セッションは、最初はセッション管理の役割を果たしていません。これは、ユーザーが正常にログインして認証され、ユーザーのログイン資格情報をセッションオブジェクトに入力した後でのみ、セッションの管理に使用できます。セッション管理のロジックも非常に単純です。ユーザーのセッションオブジェクトを取得し、正常にログインするための資格情報があるかどうかを確認する限り、ユーザーがログインしたかどうかを判断できます。ユーザーがアクティブにログアウトすると、セッションオブジェクトのログイン資格情報がクリアされます。したがって、ユーザーがログインする前またはログアウトした後、またはセッションオブジェクトに障害が発生した場合、ユーザーは必要なログイン資格情報を取得してはなりません。
2つのログイン認証検証の長所と短所：
2つのログイン検証に違いはないように見えますが、実際にはまったく異なります。トークン検証メカニズムは、セッション検証メカニズムよりも柔軟で便利です。
セッション検証と比較したトークンの利点
-
クロスドメインアクセスのサポート：送信されたユーザー認証情報がHTTPヘッダーを介して送信される場合、Cookieはトークンメカニズムには存在しないクロスドメインアクセスを許可しません。
-
ステートレス（サーバー側の拡張可能回線とも呼ばれます）：トークン自体にはすべてのログインユーザーの情報が含まれており、状態情報をサーバー側に保存するだけでよいため、トークンメカニズムはサーバー側にセッション情報を保存する必要はありません。クライアントのCookieまたはローカルメディア。
-
CDNにより適しています：コンテンツ配信ネットワークを介してサーバーのすべての情報（javascript、HTML、画像など）を要求でき、サーバーはAPIを提供するだけで済みます。
-
デカップリング：特定の認証スキームにバインドする必要はありません。APIが呼び出されたときにトークン生成呼び出しを行うことができる限り、トークンはどこでも生成できます。
-
該当するインターフェースのクロスプラットフォーム：クライアントがネイティブプラットフォーム（iOS、Android、Windows 8など）の場合、Cookieはサポートされていません（Cookieコンテナーを介して処理する必要があります）。トークン認証を使用するのは簡単です。メカニズム多く。
-
CSRF：Cookieに依存しなくなったため、CSRF（クロスサイトリクエストフォージェリ）の防止を考慮する必要はありません。
-
パフォーマンス：ネットワークのラウンドトリップ時間（データベースを介したセッション情報のクエリ）は、HMACSHA256によって計算されたトークンの検証と分析よりも常にはるかに時間がかかります。
-
ログインページに特別な処理はありません：機能テストに分度器を使用する場合、ログインページに特別な処理を行う必要はありません。
-
標準化に基づく：APIは標準化されたJSON Web Token（JWT）を使用できます。この標準には、すでに複数のバックエンドライブラリ（.NET、Ruby、Java、Python、PHP）があり、多くの企業（Firebase、Googleなど）のサポートがあります。 、Microsoft）
トークンには多くの利点がありますが、プログラマーにとってより要求が厳しいという欠点があります。セッションは比較的簡単に記述できますが、トークンシステムは少し複雑です。既存のフレームワークを使用して構築することをお勧めします。
-
ssoシングルサインオン
企業開発の初期段階では、企業はごくわずかなシステム（通常は1つまたは2つ）を使用し、各システムには独自のログインモジュールがあります。オペレーターが毎日自分のアカウントでログインするのは非常に便利です。
しかし、企業の発展に伴い、使用するシステム数が増加しており、異なるシステムを運用する場合、オペレーターは複数回ログインする必要があり、各システムの口座番号が異なるため、オペレーターにとって非常に不便です。では、あるシステムにログインして、他のシステムにログインできないのではないかと考えました。これは、シングルサインオンによって解決される問題です。シングルサインオンの完全な英語名は、シングルサインオン（略してSSO）です。その説明は次のとおりです。複数のアプリケーションシステムでは、相互に信頼できる他のアプリケーションシステムにアクセスするために一度ログインするだけで済みます。
図に示すように、この図には、Application1、Application2、Application3、およびSSOの4つのシステムがあります。Application1、Application2、およびApplication3にはログインモジュールがありませんが、SSOにはログインモジュールのみがあり、他のビジネスモジュールはありません。Application1、Application2、およびApplication3がログインする必要がある場合、それらはSSOシステムにジャンプします。SSOシステムはログインを完了します。およびその他のアプリケーションシステムが続きます。サインインします。これは、シングルサインオン（SSO）の定義と完全に一致しています。
同じドメインでのシングルサインオン：
企業には通常、ドメイン名が1つしかなく、異なるシステムはセカンドレベルドメイン名によって区別されます。たとえば、a.comというドメイン名があり、app1.a.comとapp2.a.comの2つのビジネスシステムがあります。シングルサインオン（SSO）を実行するには、sso.a.comというログインシステムが必要です。
sso.a.comにログインしている限り、app1.a.comとapp2.a.comにもログインします。上記のログイン認証メカニズムにより、sso.a.comにログインすると、実際にはsso.a.comサーバーのセッションで、同時にブラウザ（ブラウザ）のssoでログインステータスが記録されていることがわかります。 ）クッキーはa.comの下に書かれています。では、どうすればapp1.a.comとapp2.a.comにログインできますか？ここには2つの問題があります。
Webシステムは、単一のシステムから複数のシステムで構成されるアプリケーショングループに発展しました。複雑さは、ユーザーではなくシステムが負担する必要があります。Webシステムがどのように複雑に関係なく、それはユーザーのために全体の統一である。すなわち、単一のシステムにアクセスしているかのように、ユーザがウェブシステムの全体のアプリケーション・グループにアクセスします。一つだけログイン/ログアウトが十分である。
が、単一システムログインソリューションは完璧ですが、マルチシステムアプリケーショングループには適用できなくなりました。なぜですか。
単一システムのログインソリューションの中核となるのはCookieです。これは、ブラウザとサーバー間のセッション状態を維持するためのセッションIDを保持します。ただし、Cookieには制限があります。この制限はCookieのドメインです（通常はWebサイトのドメイン名に対応します）。ブラウザがhttpリクエストを送信すると、すべてのCookieではなく、ドメインに一致するCookieが自動的に送信されます。
この場合、Webアプリケーショングループ内のすべてのサブシステムのドメイン名を「* .baidu.com」などの1つのトップレベルドメイン名に統合してから、Cookieドメインを「baidu.com」に設定してみませんか。理論的にはアプローチはい、初期の頃でさえ、多くのマルチシステムログインはドメイン名とCookieを共有するこの方法を使用していました。
ただし、実行可能ということは良いことを意味するわけではなく、Cookieの共有方法には多くの制限があります。まず、アプリケーショングループのドメイン名を統一する必要があります。次に、アプリケーショングループの各システムで使用されるテクノロジー（少なくともWebサーバー）が同じである必要があります。そうでない場合、Cookieのキー値（tomcatはJSESSIONID）が異なります。 、およびセッションを維持できません。java、php、.netシステム間などの言語テクノロジープラットフォームへのログオン。第3に、Cookie自体は安全ではありません。
したがって、マルチシステムアプリケーショングループのログインを実現するには、まったく新しいログイン方法が必要です。これはシングルサイン
オンです。3。シングルサインオンシングルサインオン
とは何ですか。シングルサインオンのフルネームはシングルサインオン（以下、SSO）です。これは、マルチシステムアプリケーショングループ内の1つのシステムにログインでき、ログインしなくても他のすべてのシステムで認証を取得できることを意味します。ここでも、シングルサインオンとシングルサインオフが含まれます。
1.ログイン
シングルシステムログインと比較して、ssoには独立した認証センターが必要です。ユーザーのユーザー名とパスワードおよびその他のセキュリティ情報を受け入れることができるのは認証センターのみです。他のシステムはログインエントリを提供せず、認証の間接認証のみを受け入れます。センター。間接認証はトークンを介して行われます。sso認証センターは、ユーザーのユーザー名とパスワードに問題がないことを確認します。認証トークンが作成されます。次のジャンププロセスで、認証トークンがパラメーターとして各サブシステムに送信され、サブシステムはトークン。、これは承認されています。これを使用してローカルセッションを作成できます。ローカルセッションのログイン方法は、単一システムのログイン方法と同じです。シングルサインオンの原則であるこのプロセスを次の図に示します。
以下は、上の図の簡単な説明です。
ユーザーがシステム1の保護されたリソースにアクセスすると、システム1は、ユーザーがログインしていないことを検出し、sso認証センターにジャンプして、自分のアドレスをパラメーターとして使用します
。sso認証センターは、ユーザーがログインしていないことを検出します。ユーザーをログインページに誘導します。
ユーザーは送信するユーザー名とパスワードを入力します。ログインして
sso認証センターに申請し、ユーザー情報を確認し、ユーザーとsso認証センターの間にグローバルセッションと呼ばれるセッションを作成します。そして、認証トークンを作成します。
SSO認証センターは、トークン（システム1）と、元の要求アドレスにジャンプします
システム1トークンは、トークンが有効であることを確認するために、SSO認証センターに行きなさい。
SSO認証センターの検証ことトークンは有効であり、登録システム1
システム1はトークンを使用して、部分セッションと呼ばれるユーザーとのセッションを作成し、保護されたリソースを返します。
ユーザーは
システム2の保護されたリソースにアクセスします。システム2は、ユーザーがログインしていない場合は、sso認証センターにジャンプし、そのアドレスをパラメーターとして使用します
。sso認証センターは、ユーザーがログインしていることを検出し、システム2のアドレスに戻って、コマンドを添付します。カード
システム2はトークンを取得し、トークンが有効であることを確認するためにsso認証センターに移動します
。sso認証センターはトークンを確認して有効を返します。登録
システム2はトークンを使用してユーザーとのローカルセッションを作成し、保護されたリソース
ユーザーを返します。ログインに成功すると、セッションは、sso認証センターと各サブシステムで確立されます。ユーザーとsso認証センターの間で確立されたセッションはグローバルセッションと呼ばれ、ユーザーと各サブシステムの間で確立されたセッションはローカルセッションと呼ばれます。ローカルセッションの後が確立されると、ユーザーはサブシステムにアクセスします。システムの保護されたリソースは、sso認証センターを通過しなくなります。グローバルセッションとローカルセッションには、次の制約があります。
ローカルセッションが存在する、グローバルセッションが存在する必要がある
グローバルセッションが存在する、ローカルセッションが必ずしも存在しない
グローバルセッションが破棄される、ローカルセッションが破棄される必要が
あるブログガーデン、Baidu、csdn、のログインプロセスを通じて、シングルサインオンの理解を深めることができます。 Taobaoなどは、ログインプロセス中にジャンプURLとパラメータに注意してください
。2。ログアウト。
シングルサインオンには、当然、シングルポイントログアウトも必要です。サブシステムでログアウトすると、すべてのサブシステムセッションが破棄されます。次の図を使用して説明してください。
グローバルセッションが破棄されると、リスナーはログアウト操作を実行するために、すべての登録済みシステムに通知しますSSO認証センターは、モニターグローバルセッションの状態となっています。
以下は上の写真の簡単な説明です
ユーザーが
システム1へのログアウト要求を開始するシステム1は、ユーザーとシステム1の間で確立されたセッションIDに従ってトークンを取得し、
sso認証センターへのログアウト要求を開始します。sso認証センターは、トークンが有効であることを確認し、破棄します。グローバルセッション、および使用されたすべてのトークンを取り出します登録済みシステムアドレス
sso認証センターは、すべての登録済みシステムへのキャンセル要求を開始します。
各登録システムは、sso認証センターのキャンセル要求を受信し、ローカルセッションを破棄し
、ユーザーをログインページ。
第四に、展開図
シングルサインオンSSO認証センターや公共システム、サブシステムおよびトークンを確認し、ログアウト要求を開始し、交換トークンに通信するために、SSO認証センターの必要性を必要とする。したがって、サブシステム必見ssoクライアントを統合し、sso認証センターはssoサーバーです。シングルサインオンプロセス全体の本質は次のとおりです。ssoクライアントとサーバー間の通信プロセスを次の図に示します。
sso認定センターとssoクライアント間で通信する方法はたくさんあります。これはシンプルで使いやすいhttpClient、Webサービス、rpc、restful apiがすべて利用可能です
。5つ目は、実装
は簡単な紹介です。javaベースの実装プロセスであり、完全なソースコードは提供されていません。原則を理解してください。自分で達成できると思います。ssoはクライアント/サーバーアーキテクチャを使用します。まず、sso-clientとsso-serverによって実装される機能を見てみましょう（以下：ssocertificationcenter = sso-server）
sso-client
サブシステムにログインしていないユーザー、およびSSO認証センターへのジャンプの要求インターセプト。
SSO認証センターによるトークンて送信を受信して保存する。
SSOサーバと通信し、トークンの有効性を検証する。
Aを確立
ユーザーのログアウト要求をインターセプトしてsso認証センターに送信するローカルセッションログアウト要求sso認証センターから送信されたログアウト要求
を受信し、ローカルセッション
sso-serverを破棄します
ユーザーのログイン情報を確認する
グローバルセッションを
作成する承認トークンを作成
するsso-clientと通信してトークンを送信する
sso-clientトークンの有効性を確認する
システム登録
sso-clientログアウト要求を受信し、すべてのセッションをログアウト
する次に、原則に従ってステップバイステップでssoを実現します。
1. sso-clientは、ログに記録されていないリクエストを
インターセプトします。Javaは、サーブレット、フィルター、リスナーの3つの方法でリクエストをインターセプトします。フィルターを使用します。sso-clientで新しいLoginFilter.javaクラスを作成し、Filterインターフェースを実装し、doFilter（）メソッドでログに記録されていないユーザーのインターセプトを追加します。