sso での memcache の使用に関する質問

複数のサイト間でのシングル サインインの実現
目標:
oa ステーション www.oa.com、フォーラム ドメイン www.bbs.com フォーラムにログイン機能がないと仮定し、ユーザーが oa からログインに成功した後、 bbs のジャンプリンクまたは直接アドレスバーの bbs にアクセスすると、ログイン状態は成功になります。

シンプルなアーキテクチャ: セッション共有には独立した memcache サーバーが使用されます。2 つのサイトには独自のユーザー テーブルがありますが、データは oa ユーザー テーブルの ID や bbs ユーザーの ID など、ある程度関連しています。 table;

私の実装 :
ユーザーが oa からログインすると、user_id 関連のキャッシュ データ user_id=>xxx が memcache に生成され、その後、p3p プロトコルを使用して bbs システムで Cookie が生成されます。 >xxx は、特定の暗号化アルゴリズムを通じて memcache の user_id= を取得するために使用され、ユーザーが bbs にジャンプするか直接アクセスすると、バックエンドによる復号化後に cookie データが読み取られ、それに基づいて bbs 内のユーザー データが取得されます。 memcache 内のデータであり、セッションに書き込まれ、ログインが成功したことを示します。

質問:
1、ユーザー データのこの部分を共有するために memcache を使用するのは冗長ですか?
2. SSO でのセッション共有に memcache が使用される場合、データのどの部分が共有されますか?具体的な操作方法
3. SSO でのセッション共有に memcache を使用していますが、このソリューションでは Cookie が使用されていますか?クロスドメインですか？
4. Cookie を使用せずに SSO を実装できますか?

ディスカッション (解決策) への返信

同じドメイン内でシングル サインオンを実現するには、p3p インテリジェンスのみを使用してください。これは、複数のブラウザを使用するとわかります
ログイン ユーザー情報を保存するには、memcache を使用してください。後続のチェックのために、より便利であり、sso とは直接関係ありません

同じドメイン内でシングル サインオンを実現するためにのみ p3p インテリジェンスを使用します。これは、複数のブラウザを使用することでわかります
ログイン ユーザー情報を保存するために memcache を使用します。後続の検査の便宜のため、これらは sso とは直接の関係はありません

モデレータが意味するのは、p3p は同じドメイン内でのみ Cookie を書き込むことができ、ドメインを越えて Cookie を書き込むことはできないということです
しかし、私はこのマシンで Cookie を書き込むことができることをテストしました?ドメイン間で、ドメインの下に Cookie を書き込むことで、他のドメインについて考えます。この解決策は何ですか?
モデレータはより良い解決策を持っていますか? (cas または同様のシステムは使用しないでください)

p3p は同じドメイン内にのみ Cookie を書き込むことができることをテストしました。
どのように書くか見てみましょう

p3p は同じドメイン内にのみ Cookie を書き込むことができることをテストしました。
どのように書くか見てみましょう

おそらく次のようになります:
www.a.com と www.b.com をローカルに構築します

www.b.com==> コードは p3p Cookie を通じて記述されます。 ,
www.a.com==>index.php は を呼び出し、www.a.com/index .php にアクセスすると、 www.b.com ドメインの下に Cookie を生成します

1. ユーザー データのこの部分を共有するために memcached を使用するのは冗長ですか?
このデータをサイト間で使用する必要があるかどうかによって異なります。使用しない場合は冗長です。

2. SSO でのセッション共有に memcached が使用される場合、データのどの部分が共有されますか?操作方法
上記と同じ。一般に、SSO では、アクセス許可を迅速に検証するために、グローバル アクセス許可ビットを memcached に保存することを検討できます。ただし、あなたが言及した統合方法では、さまざまなシステムに権限が分散されているため、データのこの部分は必要ありません。 H Memcached は、システム間の送信方法を提供します。P3P は、ドメイン内のデータを小さなバッチでしか受け渡すことができません。

3. SSO でのセッション共有に memcache を使用しますか? このソリューションでは Cookie が必要ですか?クロスドメインですか？
Cookie は通常、トークンを渡すために使用されます。トークンは、あるシステムが別のシステムを起動するときにパラメーターとして渡す必要がある 1 回限りのデータです。
クロスドメインとは、サーバーコンポーネントとしての Memcached とは何の関係もない、ブラウザーの異なるドメイン間のデータ転送を指します。
urlパラメーターを介してより信頼性が高くなります

4. Cookie を使用せずに SSO を実装できますか? 数 URL パラメータを使用すると信頼性が高くなりますが、サーバー側のコードがさらに必要になります

4. SSO は Cookie を使用できませんか? URL パラメータを使用すると信頼性が高くなりますが、より多くのサーバー側コードが必要になります。Cookie を実装できますか? URL パラメータを使用すると信頼性が高くなりますが、より多くのサーバー側コードが必要になります。サーバー側のトークンを介してログイン検証を実行できる場合は、url パラメーターが最も便利です。タオバオのような SSO がブラウザ クライアントでのみ使用できる場合、URL パラメータ メソッドは機能しません。

SSO を自分で実装する場合、トークンを保護するために、サードパーティが使用する場合は Cookie のみを使用する方法を必然的に実装します。

SSO を自分で実装する場合、トークンを保護するために、サードパーティが使用する場合は Cookie のみを使用する方法を必然的に実装します。

このメソッドは、アドレスバーを介して他のサイトに直接アクセスしてログイン状態を表示することはできません

SSO を自分で実装する場合、トークンを保護するために、必然的に URL パラメータを渡すメソッドを実装することになります。第三者が使用する場合にのみ発行されます。


この方法では、アドレスバーから他のサイトに直接アクセスしてログイン状況を表示することはできません

そうです。 URL メソッドには多くの制限がありますが、信頼性が高く、JavaScript サポートなしでも実行できます。

Cookie メソッドは、サーバーにアクセスせずにブラウザーでユーザーのステータスを直接判断できるため、SSO サーバーへの負荷を軽減するのに非常に役立ちます。