Cookie ベースの SSO ログインの分析と実装、cookieso login_PHP チュートリアル
- WBOYオリジナル
- 2016-07-12 09:05:35806ブラウズ
CookieベースのSSOログイン分析と実装、Cookiesoログイン
SSOとは何ですか?
現在、多くの大手インターネット企業が多くのアプリケーションを提供しています。たとえば、以下は Taobao のスクリーンショットです。
Tmall ジュファスアン Toutiao などはすべて別のアプリケーションであり、まったく異なるドメイン名を使用しているものもあります。ただし、淘宝網に登録されているすべてのユーザーは一連のユーザー名とパスワードを使用しているため、これらのシステムを直接切り替えると、ログインできなくなります。同じ時間です。 ステップ、経験は非常に貧弱です。別の例を挙げると、多くの企業には、人事システム、財務システム、勤怠システムなど、多数の社内システムがあります。従業員が 1 つのシステムにログインした場合、別のシステムにジャンプすることは依然として困難です。 ログインする必要があるので、非常に不快に感じます...
これに基づいて、
他のアプリケーション (同じドメイン内にない) に通知しますか? SSO(Single Sign On)应运而生。当然，我们来现实这个需求的方法有很多种，使用Cookie是其中比较简单的方式，主要需要解决的问题是:Cookie是不能跨域传递的，如何将一个域的Cookie
クロスドメインやその他の関連する問題を防ぐように設計されています。 so，如果你对cookie机制不太熟悉，请先google，并大致了解为什么cookie
SSOは次の方法で実装できます
Cookieを共有する
サブシステムがすべて親ドメイン名の下にある場合、親ドメインの下に Cookie を植えることができます。これにより、同じドメイン名の下にある Cookie をブラウザで共有できるようになり、Cookie の暗号化および復号化アルゴリズムを通じてユーザーのセッション ID を取得できるようになります。したがって、SSO を実装します。
ただし、この方法にはいくつかの欠点があることが後でわかりました。
a. 同じドメイン名を持つすべてのシステムが SessionID を取得できますが、これは簡単に変更され、安全ではありません。
b. ドメインをまたいで使用することはできません。
チケット認証、現在採用している方法です
この SSO の実装には次の手順があります:
a. ユーザーが特定のサブシステムにアクセスすると、ログインしていない場合は SSO ログイン ページにジャンプするよう指示されることがわかります。 b. SSO がログインしたかどうかを確認します。 c. すでにログインしている場合は、コールバック アドレスに直接ジャンプし、認証チケットを返します。 d. ログインしていない場合、ユーザーがユーザー名/パスワードを正しく入力すると、認証が成功してコールバック アドレスにジャンプし、認証チケットが返されます。 e. サブシステムはチケットを取得し、SSO を呼び出してユーザー ID およびその他の情報を取得し、成功後にユーザーがログインできるようにします。
前に述べたように、
属性を渡す方法。
Http プロトコルがコンテキストをある程度維持できるようにするために、server は応答ヘッダーに Set-Cookie を追加して、クライアント側では、Set-Cookie の domain フィールドを使用して、この cookie が配置されているドメインを示します。 Cookie来实现SSO，主要是如何解决跨域问题。首先来谈谈Set-Cookie中的domain栗: server が戻りヘッダーに Set-Cookie を追加する場合は、www.cookieexm.com にアクセスします。 を指定しない場合は、 <code>cookie の場合、この cookie のデフォルト ドメインは www.cookieexm.com になります。つまり、www.cookieexm.com にのみアクセスします。 > >クライアントはこの cookie をサーバーに返します。
domain を .cookieexm.com として指定すると、クライアントは次のドメイン名にアクセスします: www.cookieexm.com www1.cookieexm.com cookieexm.com ***.cookieexm.com は cookie を返すことができます。 それで、結論を導き出します:
クライアントは Cookie のドメインと最後から一致します これに基づいて、SSO ログインを実装できます。 Http协议在一定程度上保持上下文，server在响应的头部可以加入Set-Cookie来写入一些数据到客户端，Set-Cookie中的domain字段用来表示这个cookie所在的域。
栗子：
我们访问www.cookieexm.com，如果server在返回头部中加入了Set-Cookie,如果不指定domain,那么默认这个cookie的域就是www.cookieexm.com，也就是只有访问www.cookieexm.com时客户端才会把这个cookie返给服务端。
如果我们指定domain为.cookieexm.com，那么客户端在访问以下域名：www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com 时都能够把cookie返回。
所以，我们得出一条结论：客户端对cookie的domain的匹配是从结尾进行匹配的，有了这个基础，我们就可以实现我们的SSO
- http のみに設定します
- ログイン資格情報（チケットやユーザー名など）は暗号化する必要があります
- Cookie は個人データを保存できません
次のサブシステムが必要だとします
たとえば: **.a1.a2 **.b1.b2 **.c1.c2间实现单点登录，首先我们需要一个专门用于单点登陆的认证系统(sso.s1.s2)。假设目前系统处于未登录状态，访问www.a1.a2
各ステップの機能を個別に見てみましょう:
説明: ビジネス認証システムは存在しない可能性があります。機密性が高くない一部のシステムは、
認証情報から直接取得できます。 SSO Authorization重定向到业务系统，并把SSO
アプリケーションにアクセスする場合は、この時点で上記を続行します。 www.b1.b2
www.a1.a2 にアクセスする場合とは異なり、sso.s1 であるため、SSO 認証 にリダイレクトするときにユーザー名を入力する必要はありません。 > にはこの時点ですでに cookie があり、cookie で直接確認できます。 www.a1.a2不同的是我们在重定向到SSO Authorization时已经不需要再去输入用户名，因为sso.s1.s2此时已经存有cookie，直接用cookie验证。
以上，就是一个简单的基于Cookie上記は、Cookie に基づくシンプルなログイン システムです。
これらの問題のいくつかは解決する必要があります
- 大量の一時信頼データを効率的に保存する方法
- 情報転送プロセスの改ざんを防ぐ方法
- SSO システムにログイン システムとログイン システムを信頼させる方法
最初の問題については、通常、memcached に似た分散キャッシュ ソリューションを使用できます。これにより、スケーラブルなデータ量のメカニズムを提供できるだけでなく、効率的なアクセスも提供できます
2 番目の質問では、デジタル証明書署名または md5 などの方法によるデジタル署名方法が一般的に採用されます。これには、SSO システムがログイン URL を返すときに検証する必要があるパラメーターを md5 で暗号化する必要があります。ログインする必要があるシステムが最終的に信頼関係を検証するときに、トークンが SSO システムに渡される必要があります。SSO システムは、トークンを検証することで情報が変更されたかどうかを識別できます。
最後の問題については、ホワイトリストを通じて解決できます。簡単に言うと、ホワイトリストにあるシステムのみが本番信頼関係を要求でき、同様に、ホワイトリストにあるシステムのみがログインから除外されます。
転載アドレス: http://www.jianshu.com/p/baa94d5f1673
。