.NETショップのA.NETとJavaショップのB.Javaの2社があるとします。各企業のユーザーは、他の企業の Web サイトにアクセスする必要があるため、2 つの企業は ADFS と Oracle Identity Federation または OpenSSO Federation を使用してフェデレーションを設定します。
.NET の世界では、属性は IClaimsPrincipal および IClaimsIdentity 内のクレームとしてアクセスされます。
Java の世界では、属性は HTTP ヘッダーとしてアクセスされます。
フェデレーション インフラストラクチャはこのマッピングを自動的に行いますか。
A.NET ユーザーが B.Java サイトにアクセスした場合、ユーザーは自分の属性をクレームとして取得しますか?
B.Java ユーザーが A.NET サイトにアクセスした場合、属性はヘッダーとして取得されますか?
両側で WS-Federation を使用できると仮定すると、どちらの場合でも、扱う主なアーティファクトは SAML トークンです。
一般に、フェデレーション インフラストラクチャはアプリケーション スタックから完全に独立しています。ADFS は、どちらの場合でも SAML トークンを発行します (Java アプリの場合と .NET アプリの場合)。また、OIF は両方のユーザー セットに対して SAML トークンを発行する必要があります。
.NET の世界では、WIF が SAML トークンを解析/検証して、その中の情報 (クレーム、発行者など) を表す .NET オブジェクト モデルにします。そのオブジェクト モデルがClaimsPrincipal (および関連するすべてのインターフェイスと型) です。Javaの世界でWIFに相当するものを見る必要があります。ただし、どちらの場合も、入力は SAML トークンです。
あなたのシナリオでは、両方の STS でトークン変換が行われる可能性があります。
.NET アプリの場合:
1- B 社のユーザーが OIF で認証され、A 社の SAML トークンを取得します 2- ユーザーが ADFS にトークンを送信します 3- ADFS が B からトークンを読み取り、検証して新しいトークンを発行します (追加/変換/削除する可能性が非常に高い)クレーム) 4- ユーザーは変換されたトークンをアプリ A に送信します
A のユーザーが B の Java アプリにアクセスするシーケンスは、まったく同じです。この場合、双方向の信頼があることに注意してください (会社 A は B の発行者を信頼し、その逆も同様です)。