0

SAML 2.0シングル ログアウトに問題があります。

IdP (ID プロバイダー) と SP (サービス プロバイダー) として機能する Web アプリケーションを備えた SAML 2.0 環境があります。

ユーザーとして、ユーザー エージェント (ブラウザー) で Web アプリケーション セッションを開始します。ユーザーは IdP を使用して認証されます。

別のブラウザー (同じクライアント マシンで実行中) で、同じ Web アプリケーション (つまり、SAML に関して同じ SP) で同じユーザーとして別のセッションを開始します。

これで、同じユーザーが認証される 2 つの独立した Web アプリケーション セッションができました。

その後、ブラウザーの 1 つで IdP によって開始された単一のログアウトを実行すると、IdP は、そのブラウザーで実行されているセッションを終了する 1 つのログアウト要求のみを発行します。IdP によって発行されたログアウト要求の要素は、そのブラウザ (ユーザー エージェント) を使用して SP に送信されたアサーションの AuthnStatement の属性 SessionIndex で IdP によって送信されたものと同じです。

真の「シングル ログアウト」を実現するには、IdP が開いているすべてのセッションに対してログアウト リクエストを送信する必要があるのではないでしょうか?

4

1 に答える 1

0

簡単な回答: SAML 仕様では、Single Logout (SLO) を希望どおりに動作させることができますが、一般的な実装はそれほど洗練されていません。

SAML プロファイル仕様、セクション 4.4 (シングル ログアウト プロファイル)から:

プリンシパルが ID プロバイダーに対して認証されると、認証エンティティはプリンシパルとのセッションを確立できます (通常は、Cookie、URL の書き換え、またはその他の実装固有の手段によって)。その後、ID プロバイダーは、この認証イベントに基づいて、サービス プロバイダーまたは他の依存者にアサーションを発行できます。依拠当事者はこれを使用して、プリンシパルとの独自のセッションを確立できます。このような状況では、ID プロバイダーはセッション機関として機能し、依拠当事者はセッション参加者として機能できます。

SLO シーケンスがセッション参加者の 1 人によって開始された場合、この議論全体は意味がありません。仕様では、セッション参加者は、ID プロバイダーによって最初にセッション参加者に送信された一意の ID (セッション インデックスとも呼ばれます) を介して、終了する「共有」セッションを識別する必要があります。仕様で要求されているように、この ID は SP セッション #1 と SP セッション #2 で異なります。

...しかし、SLO シーケンスが IdP によって開始されると、シナリオが可能になります。セクション 4.4.4.1 では、発行と処理に関するルールについて説明しています<LogoutRequest>。

リクエスタがセッション参加者である場合、リクエストに少なくとも 1 つの<SessionIndex>要素を含める必要があります。[...] リクエスタがセッションオーソリティである (またはその代理として行動している) 場合、そのような要素を省略して、プリンシパルの適用可能なすべてのセッションの終了を示すことができます (MAY)。

翻訳: IdP に a<LogoutRequest>なしで a<SessionIndex> を発行するように指示でき、 SP がそのような要求を正しく解釈するのに十分なほど洗練されており、SP がバックエンドを介して特定のユーザーのすべてのセッションを終了できる場合、あなたは勝ちました。

実際には、上記の条件の組み合わせは非常に困難です。デフォルトでは、ほとんどの IdP<LogoutRequest>は<SessionIndex>. わざわざ SLO を実装している非常に少数の SP は、<SessionIndex>. 非常にまれなケースで、正しいものを思いつくことができ<LogoutRequest>、SP がそれを詰まらせない場合、SP が IdP によって開始されたすべてのセッションを正しく識別し、終了できる場合は非常に幸運です。それらをバックエンド経由で。

于 2020-03-24T00:47:20.767 に答える