2016-07-07 4 views
0

私は現在次の問題に直面しています:サブドメインにログインしたセッション

メインドメインは、フレームワーク固有のセッションを持つ特定のPHPフレームワークを実行しています。別のPHPフレームワークを実行する新しいサブドメインがあり、メインドメインのログインセッション情報をサブドメインと共有する必要があります。私。ユーザーはメインドメインに登録するだけですが、ログインするとサブドメインのアカウントにもログインします。また、サブドメインはメインドメインdbにアクセスできないことにも注意してください。

これらの制限により、私は次の解決策を思いつきました。まず、ドメインCookieを.mydomain.comに設定しました。サブドメインのセッションCookieにアクセスできます。次に、メインドメインで簡単なAPI呼び出しを実装します。この呼び出しは、ログインしたステータスと他のセッション情報を返します。 API URLにはサブドメインサーバーに限定されたIPホワイトリストがあり、ユーザーがメインドメインからサブドメインにアクセスすると、ユーザーのCookieサーバーサイド(おそらくcURL)でAPI URLが要求されます。一度、ユーザーがサブドメインでこのように認証された場合、特定のセッションのトークンが割り当てられ、そこでサブドメインの通常のセッションと別のセッションとして管理できます。

私の質問は、この設定でセキュリティ上の欠陥があるかどうかです。または任意の改善またはこれを行うためのより好ましい方法を提案...私にとっては

+2

ちなみに、私は[OAuthまたはSAMLなしのクロスドメイン認証]に関する記事を書いています(https://paragonie.com/blog/2016/02/one-login-rule-them-all-seamless-and-secure -cross-domain-authentication)を使用します。 –

+0

ありがとう、それは面白い読書でした。私が集めたものから、私が説明したメカニズムは、あなたがブログの記事で説明したものと似ていますが、単純に(そして暗号がなくても)はるかに単純であり、dbストアドトークンを使用して、サブドメインのメインドメインからクッキーを共有するよりも、 –

答えて

0

おかげで、私は、シングルサインオン概念を使用すると思います。ユーザーがドメインまたはサブドメインのいずれかを使用してログインすると、そのユーザーのアクセストークンを生成してサインインします。 その後、同じアクセストークンを使用して、別々のセッションを使用せずに、異なるドメイン名に対してユーザーを確認および認証します。これにより、セッションのハイジャックが発生し、複数のセッションを管理することが難しくなります。セッションが作成されると、アクセスルールとともにアクセストークンを割り当てます。これにより、シームレスなサインインプロセスが可能になり、管理も容易になります。

詳細については、Single Sign-OnまたはOAuth 2.0プロトコルを検索してください。

+0

提案していただきありがとうございます。残念ながら、現在のケースでこれを実装することは現実的ではありません。そのため、私の質問に記載されている解決策を選択しました –

関連する問題