3

私たちは Shibboleth ID プロバイダーを運営しており、Shibboleth 以外の SAML ソリューションを使用してアプリケーションと統合するように求められることが増えており、属性の命名に関して困難に直面しています。純粋な Shibboleth IdP と SP の関係では、IdP がアサーションで任意の属性名を使用してユーザー属性をサービス プロバイダーに解放できることがわかっています。IdP が提供する名前を使用して特定の属性を受け取るように構成されたサービス プロバイダーは、attribute-map.xml ファイルの構成を使用して、IdP からの属性をサービス プロバイダーに役立つ属性名に再マップします。

私の問題は、Shibboleth Service Provider 以外のオペレーターにあり、その多くは IdP から送信された属性を再マップすることを拒否しており、代わりに (既存の属性で既に使用可能な値を保持するために) 新しい属性を IdP で定義するよう要求しています。サービス プロバイダーの所有者。これにより、IdP 上のユーザーの属性オブジェクトが (認証時に) 不必要に大きくなります。これは、定義されたすべての属性に最初に値が取り込まれ、次に要求側 SP へのリリースが承認された属性のみにフィルターダウンされるためです。

Shibboleth Service Provider に存在する属性マッピング機能は、SAML/SAML 2.0 仕様/標準の一部ですか? それとも Shibboleth 開発者によって導入された機能ですか? それが SAML ソリューションの標準的な関係/動作の一部である場合、誰かが信頼できる標準ドキュメントに誘導できますか?

SAML 標準に関して OASIS で見つけたものを読みましたが、この動作に関するものは何も見つかりません。

4

1 に答える 1

2

属性マッピングは、アプリケーション固有の機能です。

SAML 仕様は、メッセージ交換や XML スキーマなどを詳細に説明するものであり、ソフトウェアが提供する機能や、IdP と SP 間の双方向の取り決めをどのように編成する必要があるかではありません。SAML 仕様とは何の関係もありません。ごめん。

同様の属性マッピング機能を提供する SAML 製品は他にもたくさんあることに注意してください。これを行うのは shibboleth だけではありません。ここでの問題は、サービス プロバイダーが自分たちの要件をあなたの要件よりも重要であると考えており、例外を設ける準備ができていないことだと思います。それか、方法がわからないかのどちらかです。

于 2013-10-26T18:48:55.793 に答える