Cookie ベースの SSO ログインの分析と実装

Cookie ベースの SSO ログイン分析と実装

SSO とは何ですか?

多くの大手インターネット企業は現在、多くのアプリケーションを持っています。たとえば、以下は Taobao のスクリーンショットです:

Tmall Ju Huishan。 Toutiao とその他のアプリケーションは別のアプリケーションであり、まったく異なるドメイン名を使用している場合もあります。ただし、淘宝網に登録されているすべてのユーザーは一連のユーザー名とパスワードを使用するため、これらのシステム間で直接切り替えると、ログイン状態が同期されなくなります。とても悪い。別の例として、多くの企業には人事システム、財務システム、勤怠システムなどの多くの社内システムがあります。従業員が 1 つのシステムにログインし、別のシステムにジャンプするためにログインする必要がある場合、非常に不快になります。

これに基づいてSSO(Single Sign On)が誕生しました。もちろん、この要件を実現するにはさまざまな方法がありますが、Cookie を使用するのが最も簡単な方法の 1 つです。解決する必要がある主な問題は、Cookie をドメイン間で転送する方法です。 🎜> 他のアプリケーション (同じドメイン内ではない) に通知しますか? Cookie

、so メカニズムに詳しくない場合は、まず cookie を理解して、google がドメインを越えないよう設計されている理由やその他の関連問題について一般的に理解してください。 。 cookie

それを達成するにはどうすればよいですか?

SSO には、

共有 Cookies

を実装する次の方法があります。サブシステムがすべて親ドメイン名の下にある場合、Cookie はその下に植えられます。これにより、同じドメイン名の Cookie をブラウザ間で共有できるようになり、Cookie 暗号化および復号化アルゴリズムを通じてユーザーのセッション ID を取得できるようになり、SSO が実現されます。

しかし、この方法にはいくつかの欠点があることが判明しました:
a. 同じドメイン名を持つすべてのシステムが SessionID を取得できますが、これは変更されやすく安全ではありません。ドメイン間で。


チケット検証では、現在このアプローチを採用しています。

この SSO 実装には次の手順があります。

a. ユーザーは特定のサブシステムにアクセスし、ログに記録されていない場合は確認します。

b. すでにログインしている場合は、コールバック アドレスに直接ジャンプし、
を返します。 >d. ログインしていない場合、ユーザーはユーザー名/パスワードを正しく入力し、認証パスがコールバック アドレスにジャンプし、認証チケットを返します。
e. サブシステムはチケットを取得し、SSO を呼び出してユーザー ID を取得します。およびその他の情報が表示され、成功後にユーザーがログインできるようになります。


前に述べたように、

から

を実装する方法は、主にクロスドメインの問題を解決する方法に関するものです。まず、 の Cookie 属性について説明します。 SSOSet-CookiedomainCookie ドメイン

プロトコルのコンテキストをある程度維持するために、応答のヘッダーに

を追加してデータを書き込むことができますクライアント側では、

の Http フィールドは、この server が配置されているドメインを示すために使用されます。 Set-Cookie チェストナット: Set-Cookie domain にアクセスすると、cookie が戻りヘッダーに
を追加し、
が指定されていない場合、この www.cookieexm.com のデフォルト ドメインは server になります。つまり、クライアントは Set-Cookie にアクセスする場合にのみ、この domain をサーバーに返します。 cookiewww.cookieexm.com を www.cookieexm.com として指定すると、クライアントはドメイン名 cookie にアクセスするときに
を返すことができます。 domainしたがって、次の結論が導き出されます: .cookieexm.comクライアントは Cookie のドメインと最後から一致します www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com この基礎により、cookie ログインを実装できます。
Cookie の注意点SSO

は http のみに設定されています

関連するログイン認証情報 (チケットやユーザー名など) は暗号化する必要があります

• cookies プライベートデータは保存できません
• 具体的な解決策
• 次のサブシステム間でシングルサインオンを実装する必要があるとします

まず、専用の認証システムが必要です。シングルサインイン (sso.s1.s2)。システムが現在ログインしていないとします。たとえば、

にアクセスします。

**.a1.a2 **.b1.b2 **.c1.c2www.a1.a2

各ステップの効果を見てみましょう。個別に:

1. リクエストwww.a1.a2
2. www.a1.a2リクエストを受信したら、ログイン Cookie が含まれているかどうかを確認し、まだログインしていない場合は、SSO 認証センター
にリダイレクトします。
3. SSO が提供する ログイン ウィンドウで、ユーザーはユーザー名とパスワードを入力します。 SSO システムはユーザー名とパスワードを検証します
4. このステップが重要です。ログインが成功すると、まず SSO システムの Cookie がクライアントに配置され、同時にユーザーの認証情報が渡されます。リダイレクトを通じてビジネス パーティに転送されることに注意してください。この転送は明らかに Cookie (異なるドメイン) を介して渡すことはできませんが、通常は暗号化されたクエリ文字列を介して行われます。
5. 事業者側の認証システムはSSO認​​証情報を受け取り、認証を行います。
6. 事業者側の認証後、認証結果のCookieを.a1.a2に書き込みます。 、SSO が認証されました。ビジネス システム
への
7. www.a1.a2 のリダイレクトが完了します。前述の結論から、.a1.a2 で終わるすべてのビジネス システムは、その後 cookie
8. 応答を使用できます。

注記:
ビジネス認証システムは必ずしも存在するわけではありません。システムによっては、SSO Authorization からビジネスに直接リダイレクトされる場合があります。システムに SSO を入力し、認証情報を取得します。

上記に従って、現時点でユーザーが www.b1.b2 アプリケーションにアクセスすると、次のようになります。

www.a1.a2 にアクセスする場合との違いは、SSO Authorization にリダイレクトするときにユーザー名を入力する必要がなくなったことです。これは、この時点で sso.s1.s2 にはすでに cookie があるため、cookie を直接使用して確認できるためです。
上記は Cookie をベースにした簡易ログインシステムです。

これらの問題のいくつかは重点的に解決する必要があります

• 大量の一時的な信頼データを効率的に保存する方法
• 方法情報転送プロセスの改ざんを防ぐ
• SSO システムにログイン システムとバインディング システムを信頼させる方法

最初の質問については、通常、分散キャッシュを使用できます。 memcached に似たソリューションで、スケーラビリティを提供できます。 データ ボリューム メカニズムにより、効率的なアクセスも提供できます

2 番目の質問では、デジタル証明書の署名または md5 などの方法のいずれかによるデジタル署名方法が一般に採用されます。 URL を使用する場合、md5 は検証が必要なパラメータを暗号化し、トークンとともに返します。最後に、ログインが必要なシステムが信頼関係を検証するために使用される場合、トークンが必要になります。 SSO システムは、情報が変更されたかどうかを確認できます。

最後の問題については、簡単に言うと、システムだけで解決できます。同様に、ホワイトリストにあるシステムは、ログインする必要がなく、ホワイトリストにあるシステムのみが本番信頼関係を要求できます。

転載アドレス: http://www.jianshu.com/p/baa94d5f1673