1

SSO の概念と、それらが自分の状況にどのように適合するかについて頭を悩ませようとしていますが、少し行き詰まっています。Azure AD や Ping Identity などを使用すると仮定すると、ソーシャル ログイン (Google アカウントや Facebook など) を有効にする必要があります。これで問題ありません。私が行き詰まっているのは、その ID に添付するクレームをどのように制御するかということです。

プロセス (私の頭の中) の概要: - ユーザーは Google (Facebook など) アカウントでログインし、Google アカウントを「レガシー」アカウントに関連付けます (つまり、ソーシャル ログインを、ビジネスとして識別される内部識別子にリンクします)。 ）そのプロセスが何であれ、この議論には関係ありません（私は思いません）。

ユーザーがソーシャル アカウントでログインしたときに、そのマッピングを内部識別子にルックアップしてクレームとして追加し、組織がユーザーについて知っている情報に基づいて、そのユーザーに関連する他のクレームを追加するにはどうすればよいですか (たとえば、 21 歳以上の場合、メンバーの「レベル」など)。

SSO を使用する RP が 1 つある場合、RP がこのロジックを実行できるため、SSO を使用して結合したい複数の内部 (および外部で管理されている可能性がある) システム (現在は 4 ～ 5) がある状況があることがわかります。 - アクセス/パーソナライゼーションなどのためにこれらのクレームに依存します。

私がこれに最も近いのは RP-STS の概念です。これは、効果的に Ping / AZ AD の前に座ってチェーンの一部を形成することができるため、内部ルックアップを実行して追加できます。必要に応じて追加の主張 - それは概念として意味がありますか? それは正しいアプローチですか？

これは珍しいことではないと確信していますが、必要な完全な統合（AZ AD / Pingなどだけで十分）に関する良い例/ドキュメントを見つけることができないようです. これを行うことができる既製の製品があるに違いありませんか? (可能であれば、カスタム SSO 実装/コンポーネントは本当に必要ありません)

4

1 に答える 1

1

私がこれに最も近いのは RP-STS の概念です。これは、効果的に Ping / AZ AD の前に座ってチェーンの一部を形成することができるため、内部ルックアップを実行して追加できます。必要に応じて追加の主張 - それは概念として意味がありますか? それは正しいアプローチですか？

これがまさに RP-STS (または一部の文献では「フェデレーション プロバイダー」) の役割です。アプリと複数の「ID プロバイダー」の間に位置し、通常は次の 2 つのことを担当します。

  1. プロトコル遷移(たとえば、アプリは WS-Fed または SAML かもしれませんが、Facebook は OAuth2 です)
  2. クレームの変換と強化(例: いくつかのロジックに基づいたクレームの追加、削除、変換)。

これには、さまざまな程度の洗練度/柔軟性とトレードオフを伴ういくつかの実装があります。

  1. Azure Access Control Service は、#1 と (ある程度制限されています) #2 を実行できます。ただし、サービスに将来性があるかどうか、または Azure AD に組み込まれるかどうかは不明です。
  2. IdentityServer はすべてを行うことができます。これは OSS であるため、「所有」します (ホスト、操作、カスタマイズなど)。これは、専門家 (Dominick Baier と Brock Allen) によって作成され、非常に柔軟で、本番環境で使用される優れた実装です。
  3. ADFS はいくつかのことを実行できます (限られた数のプロトコル、デバッグが複雑であるが機能する独自のクレーム変換言語)。ADFS を自分でホストする必要があります。これは MSFT 製品です。

私が働いている会社も同様の機能を提供しています。

于 2014-03-03T05:21:54.950 に答える