複数のドメインにシングルサインオンを設定するにはどうすればよいですか？
同じドメインに存在する2つのサイト、a.domain.comとb.domain.comにシングルサインオンを設定しました
私はCookieを使用してそれを行いましたが、ドメインに依存しています。そして-それがGreat Bookに書かれているように-異なるドメインでのシングルサインオンの必要性がその醜い頭を上げました:)私はOpenIdの使用を忘れることができると99％確信しています（外部サービスは好きではありません）ここでは、それらを受け入れることさえできません reCaptcha ）
異なるWebサイト（a.domain.com、b.anotherdomain.comなど）の誰かを識別できるようにしたいのですが。複数のドメインでシングルサインオンをセットアップ/管理するための推奨される方法は何ですか？提案を起草する前に知っておくべき具体的なセキュリティの懸念はありますか？
Stack Exchange Network にシングルサインオンを実装する方法は、非常に興味深いものです。 HTML 5ローカルストレージ を使用します。必要なブラウザーサポートによっては、同様の方法を使用できる場合があります。
詳細については、stackoverflowブログの投稿 Global Network Auto Login を確認してください。
OpenIdに外部サービスを使用する必要はありません。 OpenIdサーバーを内部でホストし、SSOに使用できます。これにより、オープンソースコードと、OpenIdを安全にするために行ったすべての作業を活用できます。
PS：OpenIdは、多くのサイトで使用される一意のIDを持つために使用できますが、各ドメインに「手動で」ログインする必要があります。
これに適した2つのプロトコルは、OAuth（http://en.wikipedia.org/wiki/OAuth）とSAMLです。OpenIDまたはその他の認証を使用して、独自の「IDプロバイダー」サイトを実行できます。アプローチ。
おそらくADFSv2（Windows 2008R2の無料ダウンロード）は、共通ドメインCookieを使用するのに役立ちます。次に、C:\inetpub\adfs\lsにあるweb.configの抜粋を示します。これは、目的の効果を実現するために構成する必要があります。
<!--
Common domain cookie. A common domain cookie stores a list of recently visited Claims Providers
(also called Identity Providers), as described in Section 4.3.1 of Profiles for the OASIS Security
Assertion Markup Language (SAML) V2.0. It is recommended that you enable common domain cookies by
including the <commonDomainCookie> element in the web.config file.
1.The writer attribute of the <commonDomainCookie> element specifies the address of the writer
service that a Claims Provider uses to set the common domain cookie once it has authenticated a user.
This address should be a valid URL.
2.The reader attribute of the the <commonDomainCookie> element specifies the address of the reader
service that a claims-aware service (also called a Service Provider) uses to get the list of Claims
Providers that it should present to the user. This address should be a valid URL.
The following configuration enables the use of common domain cookies and specifies writer and reader
services as described previously.
A common Domain Cookie is named "_saml_idp" in 4.3.1 http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
Space delimited URI encoded
RULES:
Must be secure
Must have path = /
Must be leading period as in .domain.com
Can be session or persistant
All providers should be configured similarly
TODO-->
<commonDomainCookie writer="" reader="" />
ここにたくさんの良い答えがあります。
これらはいくつかの優れたソリューションです。
- OpenId
- OAuth
- SAML
- ADFS
- ローカルストレージ
これらについて少し学ぶことなく、これらを実装するのは簡単なことではないと思います。
あなたの質問からそれはオプションではないようですが（私はあなたに再考し、あなたの上級者を納得させるように試みるように勧めますが）より適切ですが、適切なWeb-SSO製品を実装するでしょう。
私が見たかなり単純なソリューションの1つであり、実際に一部のWeb-SSO製品もこのトリックを使用しています（すべての状況でこのアプローチを必ずしも推奨するわけではないことに注意してください。以下を参照してください）。
（ユーザーの認証後に）「ID Cookie」を発行する3番目の「認証」ドメインを用意します。他のドメインのWebサイトは、単純にPOSTリクエストを認証ドメインに送信できます。もちろん、そのドメインのユーザーのCookieが含まれます）。応答は基本的に、元のドメイン、ユーザーが認証されているかどうか、必要に応じてユーザーのIDを通知します。
ユーザーがまだ認証されていない場合-認証ドメインのページにリダイレクトされ、パスワードなどを送信します。
これは設定がかなり簡単ですが、実際に安全にすることにはいくつかの課題があることに注意してください。
たとえば、定義されているように、anyウェブサイトはあなたのアイデンティティを取得できます。また、依存するWebサイトは、返された応答を変更することで「だまされ」ます。
もちろん、これらの問題を解決する最も簡単な方法は、あなたが推測したとおり、SAML/OpenId/etcです。
登録したばかりですが、他の場所で回答を見つけられなかったのは驚くべきことです。ご存知のとおり、Cookieを使用して代理認証トークンを渡すことはできません。
現在のサイトの認証の実装方法や、サイトのプログラミングに使用できるツールの詳細は提供していません。ただし、認証メカニズムは、Webサーバーで実行され、Cookieを使用してセッションを追跡する言語で記述されていると想定します。
その場合、セッションが認証されているかどうかを確認するために認証を必要とするすべてのURLにすでにコードがあり、適切なアクション（要求のアクションまたはログインページへのリダイレクト）を実行します。認証済みのセッションがなく、URLで暗号化された変数が渡される（つまり、GETとして）シナリオに対処するだけで済みます。値を復号化し、その有効性を確認して、この時点でセッションを作成します。次に、ログインページで、ログインが成功した後、リダイレクトし、適切なキーと値のペアをURLに追加します。
これは簡単な概要です-考慮する必要がある微調整がいくつかあります（たとえば、同じセッションデータをすべてのサイトで共有したいですか、別のセッションにセッションを再バインドして、サーバー側で期限切れにならないようにしますか）また、リプレイ攻撃を防ぐ方法についても考慮する必要があります（ランダムに生成されたチャレンジを含む暗号化されたペイロードにTTLを含めますが、クライアントIPアドレスの使用に注意してください）。
サーバー側だけを暗号化/復号化するので、対称暗号化で十分です。