2

web.xml、security-constraint(s)、security-role(s)、および login-config を備えた標準の Web アプリを Spring Security 3.0 に移植しています。security-role-ref 要素を除く web.xml のほぼすべての機能について、同等のマッピングを見つけました。

セキュリティ ロール名がデプロイメント環境用であることを指示したくないので、J2EE セキュリティのマッピング機能を利用して、次のように論理ロール名を物理ロール名にマップします。

<servlet>
    <servlet-name>MyServlet</servlet-name>
    <servlet-class>org.example.MyServlet</servlet-class>
    <security-role-ref>
        <role-name>MANAGER</role-name>
        <role-link>DISTRICT_MANAGER</role-link>
    </security-role-ref>
</servlet>

上記のスニペットでは、ユーザーが論理ロール「MANAGER」に属しているかどうかを確認するために、コードまたは JSP に 1 つ以上のチェックがあることに注意してください。この特定のデプロイメントでは、そのロールは、JAAS コンテキスト (JDBC または LDAP) から返される物理ロール「DISTRICT_MANAGER」にリンクされています。

Spring Security 3.0 に同様のマッピング機能はありますか? 展開環境の物理的な役割を確認するためにアプリケーションを変更する必要がないようにしたいと考えています。また、システム管理者に、アプリケーションのためだけにユーザーの LDAP レコードに特定の役割/権限を追加させる立場にはありません。

前もって感謝します。

4

1 に答える 1

1

Spring Security 3.1には、GrantedAuthoritiesMapperと呼ばれる一般的なマッピング戦略があります。これを実装してに注入し、AuthenticationProviderロードする権限をアプリケーション内で決定を行うために使用される権限に変換する方法を指示できます。

以前のバージョンを使用している場合は、直接実装して、オブジェクトAuthenticationProviderの作成を自分でカスタマイズできます。Authentication例として、アプリケーションコンテキストファイルでマップとして定義されたマッピングのセットを定義し、それらを使用して、プロバイダーから返される最終的な権限のセットを作成できます。その後、マッピングは実際web.xmlにはアプリコンテキストファイルに移動しました（冗長性は低くなります）。

于 2012-05-17T13:42:18.540 に答える