Shibboleth 認証を使用してアプリをフロントエンドしています。アプリに表示するために、認証済みのユーザー名を取得するにはどうすればよいですか?
質問する
1431 次
3 に答える
1
アプリケーションの言語と環境に固有の方法で属性にアクセスできます。推奨される方法は環境変数を使用することですが、HTTP 要求ヘッダーを使用することもできます。これは、クライアントが必要なヘッダーを「偽造」できるため、セキュリティ上の問題が発生する可能性があります (ただし、nginx などの一部の HTTP フロントエンドは、アンダースコアを持つヘッダーを削除します)。これは、Shibboleth Native SP が通常使用するものです)。
たとえば、Tomcat で Java を使用している場合はmod_proxy_ajp、Apache HTTP で を使用しmod_shib2、"AJP_" をヘッダー/変数の先頭に追加するように SP を構成して、mod_proxy_ajp コードが代わりにそれらを属性として要求に配置するようにします。ヘッダーの。
いずれにせよ、ユーザー名 (おそらくプリンシパル/サブジェクト) がアプリケーションに渡されていることがわかったら、上記のリンクに示されているように、プログラミング言語の典型的な属性アクセス メソッドを介して簡単にアクセスできます。
于 2011-12-15T05:32:19.670 に答える
1
その属性を解放する必要があります。通常、これはローカル SP によって要求にヘッダーとして追加されます。少なくとも、ISAPI 拡張機能を使用する IIS ではこのように動作します。
于 2011-12-09T21:56:56.327 に答える
0
eduPerson オブジェクト クラスの仕様 (200806)
2.2.8. eduPersonPrincipalName (eduPerson 1.0 で定義); OID: 1.3.6.1.4.1.5923.1.1.1.6
RFC 4512 定義 ( 1.3.6.1.4.1.5923.1.1.1.6
NAME 'eduPersonPrincipalName'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )
アプリケーション ユーティリティ クラス: 標準。値の数: 単一
意味
機関間認証のための個人の「NetID」。これは、スコープがローカル セキュリティ ドメインを定義する「user@scope」の形式で表す必要があります。複数の「@」記号は推奨されませんが、いずれにしても、左から始まる「@」記号の最初の出現は、構成要素間の区切り文字と見なされます。したがって、ユーザー識別子は最初の「@」の左側にあり、セキュリティ ドメインは右側にあります。この解析規則は、正規表現処理における POSIX の「貪欲な」曖昧さ回避方法に準拠しています。スコープが登録ドメイン名の場合は、対応する登録機関をスコープとする。たとえば、francis@trinity.edu は、ePPN の背後にあるアイデンティティに「NetID」「francis」があることを意味します。ドメイン名「trinity.edu」で登録した高等教育機関で。他の値のスタイルが使用されている場合、関係者はそのセマンティクスをプロファイリングする必要があります。スコープの各値は、割り当てられたプリンシパル名が一意である名前空間を定義します。この規則を考えると、eduPersonPrincipalName 値のペアが衝突することはありません。それらが同じである場合、それらは同じ管理ドメイン内の同じプリンシパルを参照します。
ノート
設定されている場合、ユーザーは、ローカルで運用されているサービスを使用して、この識別子で認証できるはずです。ローカル認証システムは、認証されたプリンシパルがこの識別子が発行された人物であることを (ローカル アプリケーションとリモート アプリケーションの両方に対して) 適切に確認できる必要があります。
最初の意図は、Shibboleth プロジェクト ( http://shibboleth.internet2.edu/ ) 内でこの属性を使用することです。ただし、他の多くのアプリケーションでもこの属性をうまく利用できることがすぐに明らかになりました (例: H.323 ビデオ、チャット ソフトウェアなど)。eduPersonPrincipalName (EPPN) は次のように使用されます。リソース所有者 A は、B のディレクトリ エントリを調べて、B の EPPN を検出します。次に、A はローカル認証システムに、B の EPPN がリソースの使用を許可されていることを伝えます。B がリソースにアクセスしようとすると、アプリケーション (またはアクセス制御インフラストラクチャ) は B の ID を検証し、ローカル認証システムをチェックして B に適切なアクセス権限が付与されていることを確認し、アクセスを許可または拒否します。
EPPN は Kerberos 識別子 (principal@realm) のように見えます。サイトは、EPPN を Kerberos プリンシパルとしてローカルに実装することを選択する場合があります。ただし、これは必須ではありません。サイトは、ローカルで受け入れられる任意の方法で認証を行うことを選択できます。
同様に、EPPN をユーザーの公開された電子メール アドレスと混同しないでください。ただし、2 つの値は同じ場合があります。一部のサイトでは、電子メール アドレスのユーザー部分とセキュリティ プリンシパルを同じ文字列にすることを選択しています。他のサイトはこれを行わないことを選択しました。それらが同じように見える場合でも、それらは異なるサブシステムで異なる目的で使用され、同じままでなければならないという要件はありません。
ローカル ホワイト ページ ディレクトリ内のユーザー オブジェクトの uid 属性には、ログイン ID、セキュリティ プリンシパルも含まれる場合があります。一部のシステム (NDS など) では、ログイン ID を cn 属性に入れる場合があります。これらの属性は、ユニバーサルな objectclasses 内で定義されます。残念ながら、それらの使用は、クロスドメイン認証で使用するための十分に正確で一貫した方法で規定されていません. さまざまなシステムが、これらの属性を矛盾して使用しています。したがって、この新しい属性を定義しました。
EPPN は、univ.edu の大学によって企業単位で管理されていると想定されています。特定の EPPN は、関連付けられたユーザーのみに割り当てられます。複数の人が共有するセキュリティ プリンシパル識別子ではありません。最後に、各 EPPN はローカル セキュリティ ドメイン内で一意です。
以前に割り当てられた EPPN が別の個人に再割り当てされるまでの期間は、組織の決定です。一部の機関は、EPPN を再割り当てしないことを選択します。他の人は、再割り当ての前に比較的短い休憩を選ぶかもしれません. これは依拠当事者の作業を複雑にしますが、制度上の自律性を考えると避けられません。これらの問題の詳細については、識別子に関する MACE ベスト プラクティス ドキュメントを参照してください。
この属性は、現在展開されているテクノロジーや、現在 LDAP を使用していないコードや PKI を必要としないコードに基づいたアプリケーションを作成する際に役立つはずです。この属性は、異なる技術を使用するサイト間の興味深い機関間コラボレーションを促進するためのフレームワークを作成するのに役立ちます。つまり、この属性は、さらに別の抽象化レイヤーの基盤を提供します。
この属性がリソースへのアクセスを制御するのに役立つアプリケーションの例
例 (LDIF フラグメント) eduPersonPrincipalName: hputter@hsww.wiz
構文: directoryString; 索引付け: pres、eq、sub
于 2011-12-21T16:06:40.033 に答える