1

私たちが持っている管理アプリケーションにシングルサインオン（sso）を実装したいのですが、それについてのヒントが1つか2つあります。現在のアプリケーションでは、クライアントは一般的なユーザーとパスの組み合わせでアプリケーションにログインします（CAPTCHAはオプション機能です）。

私が理解している限り（私が正しく行った場合）、ssoで行うことは、IDプロバイダー（つまり、... Google、Facebook、Yahoo！、Windows Liveなど）を「信頼」することであるため、クライアントは外部ページに実際にログインすると、値が返されるので、クライアントがIDプロバイダーによって検証されていることがわかります。

私の目には、次のようなことをしたいと思います（zwibbler FTW！）：

目的の認証メカニズム

しかし、現在のアプリケーションでは、ユーザー名とパスワードをデータベースと照合します。そこで、SSOの理解が無残に失敗します... IDプロバイダーから返された情報をユーザーデータと照合するにはどうすればよいですか？

または、より適切に表現すると...外部認証と一致させるためにユーザーアカウントデータでどのフィールド（「通常の」alaユーザー、パス、電子メールなど）を使用できますか？私はこれが商用アプリケーションであることに懸念を持っているので、ユーザーが自分のログインデータを使用できるようにしたいのですが、ユーザーがログインできるようにする（またはできない）ために、何らかの方法でデータと一致させる必要があります。 ...どうすればよいですか？

4

3 に答える 3

2

いくつかのオプションがあります。

  • あなた自身の解決策を転がしてください（面白くない）。
  • HybridAuthのようなソリューションを使用してください。各プロバイダーとIDをローカルユーザーIDにマップするには、いくつかの追加フィールドまたは追加のテーブルが必要です。
  • 戦術を少し変更し、完全に別のシステムで、次のようなサインインとアクセス許可の割り当て（つまり、タグ）を管理できるようにします。 シングルサインオンサーバー/クライアント

私は最後のアプローチにかなり部分的です。特に、相互に通信する必要のある複数の異なるログインシステムがある場合、またはその必要性を予測している場合はなおさらです。

于 2012-05-14T12:50:27.437 に答える
2

一般的な設計として、次の表があります

  • ユーザー
  • 役割
  • auth_OpenID
  • auth_Google
  • auth_Facebook
  • auth_Windows_Live

（同じ構造を共有する認証テーブルを1つのテーブルにロールします）。

usersテーブルは、システム上のすべてのアカウントを識別します。ロールテーブルは、処理する必要のあるすべての権限セットを識別します。次に、auth_ *テーブルには、リモートサインオンに必要な情報（GoogleアカウントIDや認証トークンなど）が含まれます。

次に、usersテーブルと他の各テーブルの間に多対多の関係があります。

誰かが未知のサードパーティ認証システムでサインインした場合、既存のアカウントにリンクするか（この場合、認識された一連の資格情報を使用して再度サインインする必要があります）、新しいアカウントを作成するように促します。

于 2012-05-13T18:47:47.380 に答える
0

ユーザー名としてメールアドレスを使用する場合は、そのように一致させることができます。ただし、認証されたユーザーが自分のユーザーアカウントを他の認証プロバイダーに関連付けることができるシステムを構築する必要があります（ログインしたまま）。このようにすると、関係は暗黙的になります。

于 2012-05-13T19:33:06.923 に答える