次のセクションでは、Spring Security が統合される Servlet 3 メソッドについて説明します。

HttpServletRequest.login(String,String)

HttpServletRequest.login(String,String): Oracle (英語) メソッドを使用して、現在の  AuthenticationManager でユーザーを認証できます。例: 以下は、ユーザー名「user」とパスワード「password」で認証を試みます。

try {
httpServletRequest.login("user","password");
} catch(ServletException e) {
// fail to authenticate
}

	メモ
	Spring Security に失敗した認証試行を処理させたい場合は、ServletException をキャッチする必要はありません。

final AsyncContext async = httpServletRequest.startAsync();
async.start(new Runnable() {
    public void run() {
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        try {
            final HttpServletResponse asyncResponse = (HttpServletResponse) async.getResponse();
            asyncResponse.setStatus(HttpServletResponse.SC_OK);
            asyncResponse.getWriter().write(String.valueOf(authentication));
            async.complete();
        } catch(Exception e) {
            throw new RuntimeException(e);
        }
    }
});

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee https://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">

</web-app>

<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>
    org.springframework.web.filter.DelegatingFilterProxy
</filter-class>
<async-supported>true</async-supported>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>ASYNC</dispatcher>
</filter-mapping>

httpServletRequest.startAsync();
new Thread("AsyncThread") {
    @Override
    public void run() {
        try {
            // Do work
            TimeUnit.SECONDS.sleep(1);

            // Write to and commit the httpServletResponse
            httpServletResponse.getOutputStream().flush();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}.start();

次のセクションでは、Spring Security が統合される Servlet 3.1 メソッドについて説明します。

このサポートを使用するには、 org.springframework.security:spring-security-data 依存関係を追加し、型  SecurityEvaluationContextExtension の Bean を提供します。Java 構成では、これは次のようになります。

@Bean
public SecurityEvaluationContextExtension securityEvaluationContextExtension() {
    return new SecurityEvaluationContextExtension();
}

XML 構成では、これは次のようになります。

<bean class="org.springframework.security.data.repository.query.SecurityEvaluationContextExtension"/>

これで、Spring Security をクエリ内で使用できます。例：

@Repository
public interface MessageRepository extends PagingAndSortingRepository<Message,Long> {
    @Query("select m from Message m where m.to.id = ?#{ principal?.id }")
    Page<Message> findInbox(Pageable pageable);
}

これにより、 Authentication.getPrincipal().getId() が  Message の受信者と等しいかどうかが確認されます。この例では、プリンシパルが id プロパティを持つオブジェクトにカスタマイズされていることを前提としていることに注意してください。 SecurityEvaluationContextExtension Bean を公開することにより、すべての一般的なセキュリティ表現がクエリ内で利用可能になります。

Spring Security の同時実行性サポートの中で最も基本的な構成要素の 1 つは  DelegatingSecurityContextRunnable です。デリゲート用に指定された  SecurityContext で  SecurityContextHolder を初期化するために、デリゲート  Runnable をラップします。その後、 SecurityContextHolder をクリアすることを保証する Runnable デリゲートを呼び出します。 DelegatingSecurityContextRunnable は次のようになります。

public void run() {
try {
    SecurityContextHolder.setContext(securityContext);
    delegate.run();
} finally {
    SecurityContextHolder.clearContext();
}
}

非常にシンプルですが、SecurityContext をあるスレッドから別のスレッドにシームレスに転送します。ほとんどの場合、SecurityContextHolder はスレッドごとに動作するため、これは重要です。例: Spring Security の「<global-method-security>」サポート と呼ばれるセクションを使用して、サービスの 1 つを保護した可能性があります。これで、現在の  Thread の  SecurityContext を、保護されたサービスを呼び出す  Thread に簡単に転送できます。これを行う方法の例を以下に示します。

Runnable originalRunnable = new Runnable() {
public void run() {
    // invoke secured service
}
};

SecurityContext context = SecurityContextHolder.getContext();
DelegatingSecurityContextRunnable wrappedRunnable =
    new DelegatingSecurityContextRunnable(originalRunnable, context);

new Thread(wrappedRunnable).start();

上記のコードは次の手順を実行します。

SecurityContextHolder から  SecurityContext で  DelegatingSecurityContextRunnable を作成することは非常に一般的であるため、ショートカットコンストラクターがあります。次のコードは上記のコードと同じです。

Runnable originalRunnable = new Runnable() {
public void run() {
    // invoke secured service
}
};

DelegatingSecurityContextRunnable wrappedRunnable =
    new DelegatingSecurityContextRunnable(originalRunnable);

new Thread(wrappedRunnable).start();

このコードは簡単に使えますが、Spring Security を使っているという知識が必要です。次のセクションでは、Spring Security を使っているという事実を隠すために  DelegatingSecurityContextExecutor をどのように利用できるかを見ていきます。

前のセクションで、 DelegatingSecurityContextRunnable を使用するのは簡単であることがわかりましたが、Spring Security を使用するためには Spring Security に注意する必要があるため、理想的ではありませんでした。 DelegatingSecurityContextExecutor を使用して、Spring Security を使用しているという知識からコードを保護する方法を見てみましょう。

DelegatingSecurityContextExecutor の設計は、代理  Runnable の代わりに代理  Executor を受け入れることを除いて、 DelegatingSecurityContextRunnable の設計と非常に似ています。以下に使用方法の例を示します。

SecurityContext context = SecurityContextHolder.createEmptyContext();
Authentication authentication =
    new UsernamePasswordAuthenticationToken("user","doesnotmatter", AuthorityUtils.createAuthorityList("ROLE_USER"));
context.setAuthentication(authentication);

SimpleAsyncTaskExecutor delegateExecutor =
    new SimpleAsyncTaskExecutor();
DelegatingSecurityContextExecutor executor =
    new DelegatingSecurityContextExecutor(delegateExecutor, context);

Runnable originalRunnable = new Runnable() {
public void run() {
    // invoke secured service
}
};

executor.execute(originalRunnable);

コードは次の手順を実行します。

@Autowired
private Executor executor; // becomes an instance of our DelegatingSecurityContextExecutor

public void submitRunnable() {
Runnable originalRunnable = new Runnable() {
    public void run() {
    // invoke secured service
    }
};
executor.execute(originalRunnable);
}

これで、コードは  SecurityContext が  Thread に伝搬されていることを認識せず、次に  originalRunnable が実行され、次に  SecurityContextHolder がクリアされます。この例では、同じユーザーが各スレッドの実行に使用されています。 originalRunnable を処理するために  executor.execute(Runnable) （つまり、現在ログインしているユーザー）を呼び出したときに  SecurityContextHolder のユーザーを使用したい場合はどうなるでしょうか？ これを行うには、 DelegatingSecurityContextExecutor コンストラクターから  SecurityContext 引数を削除します。例：

SimpleAsyncTaskExecutor delegateExecutor = new SimpleAsyncTaskExecutor();
DelegatingSecurityContextExecutor executor =
    new DelegatingSecurityContextExecutor(delegateExecutor);

executor.execute(Runnable) が実行されると、 SecurityContext が最初に  SecurityContextHolder によって取得され、次に  SecurityContext を使用して  DelegatingSecurityContextRunnable が作成されます。これは、 executor.execute(Runnable) コードの呼び出しに使用されたのと同じユーザーで  Runnable を実行していることを意味します。

Java コンカレント API と Spring タスク抽象化の両方との追加統合については、Javadoc を参照してください。前のコードを理解すると、それらは非常に自明です。

	メモ
	Spring Security 4.0 以降、 @EnableWebMvcSecurity は非推奨になりました。代替は  @EnableWebSecurity であり、クラスパスに基づいて Spring MVC 機能の追加を決定します。

Spring Security と Spring MVC の統合を有効にするには、 @EnableWebSecurity アノテーションを構成に追加します。

	メモ
	Spring Security は、Spring MVC の WebMvcConfigurer を使用した構成を提供します。つまり、 WebMvcConfigurationSupport と直接統合するなど、より高度なオプションを使用している場合は、Spring Security 構成を手動で提供する必要があります。

Spring Security は、 MvcRequestMatcher を使用した URL で Spring MVC がどのように一致するかを深く統合します。これは、セキュリティルールがリクエストの処理に使用されるロジックと一致することを確認できます。

MvcRequestMatcher を使用するには、Spring Security 構成を  DispatcherServlet と同じ  ApplicationContext に配置する必要があります。Spring Security の  MvcRequestMatcher は、 mvcHandlerMappingIntrospector という名前の  HandlerMappingIntrospector Bean が、マッチングの実行に使用される Spring MVC 構成によって登録されることを想定しているため、これが必要です。

web.xml の場合、これは設定を  DispatcherServlet.xml に配置する必要があることを意味します。

<listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!-- All Spring Configuration (both MVC and Security) are in /WEB-INF/spring/ -->
<context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>/WEB-INF/spring/*.xml</param-value>
</context-param>

<servlet>
  <servlet-name>spring</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  <!-- Load from the ContextLoaderListener -->
  <init-param>
    <param-name>contextConfigLocation</param-name>
    <param-value></param-value>
  </init-param>
</servlet>

<servlet-mapping>
  <servlet-name>spring</servlet-name>
  <url-pattern>/</url-pattern>
</servlet-mapping>

DispatcherServlet の  ApplicationContext に配置された  WebSecurityConfiguration の下。

public class SecurityInitializer extends
    AbstractAnnotationConfigDispatcherServletInitializer {

  @Override
  protected Class<?>[] getRootConfigClasses() {
    return null;
  }

  @Override
  protected Class<?>[] getServletConfigClasses() {
    return new Class[] { RootConfiguration.class,
        WebMvcConfiguration.class };
  }

  @Override
  protected String[] getServletMappings() {
    return new String[] { "/" };
  }
}

	メモ
	HttpServletRequest とメソッドセキュリティを照合することにより、常に認可規則を提供することをお勧めします。 HttpServletRequest で照合することにより認可規則を提供することは、コードパスの非常に早い段階で発生し、攻撃対象領域 (英語) を減らすのに役立つため、優れています。メソッドセキュリティにより、誰かが Web 認証ルールをバイパスした場合でも、アプリケーションは引き続き保護されます。これは多層防御 (英語) として知られているものです

次のようにマップされているコントローラーを考えます。

@RequestMapping("/admin")
public String admin() {

このコントローラーメソッドへのアクセスを管理ユーザーに制限したい場合、開発者は  HttpServletRequest で次と照合することで認可ルールを提供できます。

protected configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests(authorizeRequests ->
            authorizeRequests
                .antMatchers("/admin").hasRole("ADMIN")
        );
}

または XML

<http>
    <intercept-url pattern="/admin" access="hasRole('ADMIN')"/>
</http>

どちらの構成でも、URL  /admin では、認証されたユーザーが管理ユーザーである必要があります。ただし、Spring MVC 構成によっては、URL  /admin.html も  admin() メソッドにマップされます。さらに、Spring MVC 構成に応じて、URL  /admin/ も  admin() メソッドにマップされます。

問題は、セキュリティルールが  /admin のみを保護していることです。Spring MVC のすべての順列に追加のルールを追加できますが、これは非常に冗長で面倒です。

代わりに、Spring Security の  MvcRequestMatcher を活用できます。次の構成は、Spring MVC を使用して URL で照合することにより、Spring MVC が照合する URL と同じ URL を保護します。

protected configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests(authorizeRequests ->
            authorizeRequests
                .mvcMatchers("/admin").hasRole("ADMIN")
        );
}

または XML

<http request-matcher="mvc">
    <intercept-url pattern="/admin" access="hasRole('ADMIN')"/>
</http>

Spring Security は、Spring MVC 引数の現在の  Authentication.getPrincipal() を自動的に解決できる  AuthenticationPrincipalArgumentResolver を提供します。 @EnableWebSecurity を使用すると、Spring MVC 構成にこれが自動的に追加されます。XML ベースの構成を使用する場合は、これを自分で追加する必要があります。例：

<mvc:annotation-driven>
        <mvc:argument-resolvers>
                <bean class="org.springframework.security.web.method.annotation.AuthenticationPrincipalArgumentResolver" />
        </mvc:argument-resolvers>
</mvc:annotation-driven>

AuthenticationPrincipalArgumentResolver が適切に構成されたら、Spring MVC レイヤーで Spring Security から完全に切り離すことができます。

UserDetails を実装する  Object を返すカスタム  UserDetailsService と独自の  CustomUser Object がある状況を考えてみます。現在認証されているユーザーの  CustomUser には、次のコードを使用してアクセスできます。

@RequestMapping("/messages/inbox")
public ModelAndView findMessagesForUser() {
    Authentication authentication =
    SecurityContextHolder.getContext().getAuthentication();
    CustomUser custom = (CustomUser) authentication == null ? null : authentication.getPrincipal();

    // .. find messages for this user and return them ...
}

Spring Security 3.2 以降、アノテーションを追加することで、引数をより直接解決できます。例：

import org.springframework.security.core.annotation.AuthenticationPrincipal;

// ...

@RequestMapping("/messages/inbox")
public ModelAndView findMessagesForUser(@AuthenticationPrincipal CustomUser customUser) {

    // .. find messages for this user and return them ...
}

場合によっては、何らかの方法でプリンシパルを変換する必要があります。例:  CustomUser をファイナルにする必要がある場合、拡張できませんでした。この状況では、 UserDetailsService は  UserDetails を実装する  Object を返し、 CustomUser にアクセスするために  getCustomUser という名前のメソッドを提供します。例: 次のようになります。

public class CustomUserUserDetails extends User {
        // ...
        public CustomUser getCustomUser() {
                return customUser;
        }
}

次に、 Authentication.getPrincipal() をルートオブジェクトとして使用する SpEL 式を使用して、 CustomUser にアクセスできます。

import org.springframework.security.core.annotation.AuthenticationPrincipal;

// ...

@RequestMapping("/messages/inbox")
public ModelAndView findMessagesForUser(@AuthenticationPrincipal(expression = "customUser") CustomUser customUser) {

    // .. find messags for this user and return them ...
}

SpEL 式で Bean を参照することもできます。例: JPA を使用してユーザーを管理しており、現在のユーザーのプロパティを変更して保存する場合は、以下を使用できます。

import org.springframework.security.core.annotation.AuthenticationPrincipal;

// ...

@PutMapping("/users/self")
public ModelAndView updateName(@AuthenticationPrincipal(expression = "@jpaEntityManager.merge(#this)") CustomUser attachedCustomUser,
        @RequestParam String firstName) {

    // change the firstName on an attached instance which will be persisted to the database
    attachedCustomUser.setFirstName(firstName);

    // ...
}

@AuthenticationPrincipal を独自のアノテーションのメタアノテーションにすることで、Spring Security への依存をさらに削除できます。以下に、 @CurrentUser という名前のアノテーションでこれを行う方法を示します。

	メモ
	Spring Security への依存を削除するために、 @CurrentUser を作成するのは消費アプリケーションであることを認識することが重要です。このステップは厳密には必要ありませんが、Spring Security への依存関係をより中央の場所に分離できます。

@Target({ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@AuthenticationPrincipal
public @interface CurrentUser {}

@CurrentUser が指定されたため、それを使用して、現在認証されているユーザーの  CustomUser を解決するためのシグナルを送ることができます。また、Spring Security への依存関係を単一のファイルに分離しました。

@RequestMapping("/messages/inbox")
public ModelAndView findMessagesForUser(@CurrentUser CustomUser customUser) {

    // .. find messages for this user and return them ...
}

Spring Web MVC 3.2 + は、非同期リクエスト処理 (英語) に優れたサポートを提供します。追加の構成を行わなくても、Spring Security は自動的に  SecurityContext を  Thread にセットアップし、コントローラーから返される  Callable を実行します。例: 次のメソッドでは、 Callable が作成されたときに使用可能であった  SecurityContext で  Callable が自動的に実行されます。

@RequestMapping(method=RequestMethod.POST)
public Callable<String> processUpload(final MultipartFile file) {

return new Callable<String>() {
    public Object call() throws Exception {
    // ...
    return "someView";
    }
};
}

	SecurityContext と Callable の関連付け
	技術的に言えば、Spring Security は  WebAsyncManager と統合されます。 Callable の処理に使用される  SecurityContext は、 startCallableProcessing が呼び出された時点で  SecurityContextHolder に存在する  SecurityContext です。

コントローラーによって返される  DeferredResult との自動統合はありません。これは、 DeferredResult がユーザーによって処理され、自動的に統合する方法がないためです。ただし、並行性サポートを使用して、Spring Security との透過的な統合を提供できます。

Spring Security 4.0 は、Spring メッセージング抽象化による WebSockets の認可サポートを導入しました。Java 構成を使用して認証を設定するには、 AbstractSecurityWebSocketMessageBrokerConfigurer を継承して  MessageSecurityMetadataSourceRegistry を設定するだけです。例：

@Configuration
public class WebSocketSecurityConfig
      extends AbstractSecurityWebSocketMessageBrokerConfigurer {  

    protected void configureInbound(MessageSecurityMetadataSourceRegistry messages) {
        messages
                .simpDestMatchers("/user/**").authenticated() 
    }
}

これにより、次のことが保証されます。

Spring Security は、WebSockets を保護するための XML 名前空間サポートも提供します。比較可能な XML ベースの構成は次のようになります。

<websocket-message-broker>  
    
    <intercept-message pattern="/user/**" access="hasRole('USER')" />
</websocket-message-broker>

これにより、次のことが保証されます。

WebSockets は、WebSocket 接続が確立されたときに HTTP リクエストで見つかった同じ認証情報を再利用します。これは、 HttpServletRequest 上の  Principal が WebSockets に引き渡されることを意味します。Spring Security を使用している場合、 HttpServletRequest の  Principal は自動的にオーバーライドされます。

より具体的には、ユーザーが WebSocket アプリケーションに対して認証されたことを確認するには、HTTP ベースの Web アプリケーションを認証するように Spring Security をセットアップすることだけが必要です。

Spring Security 4.0 は、Spring メッセージング抽象化による WebSockets の認可サポートを導入しました。Java 構成を使用して認証を設定するには、 AbstractSecurityWebSocketMessageBrokerConfigurer を継承して  MessageSecurityMetadataSourceRegistry を設定するだけです。例：

@Configuration
public class WebSocketSecurityConfig extends AbstractSecurityWebSocketMessageBrokerConfigurer {

    @Override
    protected void configureInbound(MessageSecurityMetadataSourceRegistry messages) {
        messages
                .nullDestMatcher().authenticated() 
                .simpSubscribeDestMatchers("/user/queue/errors").permitAll() 
                .simpDestMatchers("/app/**").hasRole("USER") 
                .simpSubscribeDestMatchers("/user/**", "/topic/friends/*").hasRole("USER") 
                .simpTypeMatchers(MESSAGE, SUBSCRIBE).denyAll() 
                .anyMessage().denyAll(); 

    }
}

これにより、次のことが保証されます。

Spring Security は、WebSockets を保護するための XML 名前空間サポートも提供します。比較可能な XML ベースの構成は次のようになります。

<websocket-message-broker>
    
    <intercept-message type="CONNECT" access="permitAll" />
    <intercept-message type="UNSUBSCRIBE" access="permitAll" />
    <intercept-message type="DISCONNECT" access="permitAll" />

    <intercept-message pattern="/user/queue/errors" type="SUBSCRIBE" access="permitAll" /> 
    <intercept-message pattern="/app/**" access="hasRole('USER')" />      

    
    <intercept-message pattern="/user/**" access="hasRole('USER')" />
    <intercept-message pattern="/topic/friends/*" access="hasRole('USER')" />

    
    <intercept-message type="MESSAGE" access="denyAll" />
    <intercept-message type="SUBSCRIBE" access="denyAll" />

    <intercept-message pattern="/**" access="denyAll" /> 
</websocket-message-broker>

これにより、次のことが保証されます。

ブラウザーが WebSocket 接続に対して同一生成元ポリシー (英語) を強制しないことを強調することが重要です。これは非常に重要な考慮事項です。

var headerName = "${_csrf.headerName}";
var token = "${_csrf.token}";

@RestController
public class CsrfController {

    @RequestMapping("/csrf")
    public CsrfToken csrf(CsrfToken token) {
        return token;
    }
}

...
var headers = {};
headers[headerName] = token;
stompClient.connect(headers, function(frame) {
  ...

}

@Configuration
public class WebSocketSecurityConfig extends AbstractSecurityWebSocketMessageBrokerConfigurer {

    ...

    @Override
    protected boolean sameOriginDisabled() {
        return true;
    }
}

SockJS は、古いブラウザーをサポートするフォールバックトランスポートを提供します。フォールバックオプションを使用する場合、SockJS が Spring Security と連携できるように、いくつかのセキュリティ制約を緩和する必要があります。

<http>
    <!-- ... -->

    <headers>
        <frame-options
          policy="SAMEORIGIN" />
    </headers>
</http>

@EnableWebSecurity
public class WebSecurityConfig extends
   WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http
      // ...
      .headers(headers ->
        headers
          .frameOptions(frameOptions ->
             frameOptions
               .sameOrigin()
          )
      );
  }
}

@Configuration
@EnableWebSecurity
public class WebSecurityConfig
    extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .csrf(csrf ->
                csrf
                    // ignore our stomp endpoints since they are protected using Stomp headers
                    .ignoringAntMatchers("/chat/**")
            )
            .headers(headers ->
                headers
                    // allow same origin to frame our site to support iframe SockJS
                    .frameOptions(frameOptions ->
                        frameOptions
                            .sameOrigin()
                    )
            )
            .authorizeRequests(authorizeRequests ->
                ...
            )
            ...

<http ...>
    <csrf request-matcher-ref="csrfMatcher"/>

    <headers>
        <frame-options policy="SAMEORIGIN"/>
    </headers>

    ...
</http>

<b:bean id="csrfMatcher"
    class="AndRequestMatcher">
    <b:constructor-arg value="#{T(org.springframework.security.web.csrf.CsrfFilter).DEFAULT_CSRF_MATCHER}"/>
    <b:constructor-arg>
        <b:bean class="org.springframework.security.web.util.matcher.NegatedRequestMatcher">
          <b:bean class="org.springframework.security.web.util.matcher.AntPathRequestMatcher">
            <b:constructor-arg value="/chat/**"/>
          </b:bean>
        </b:bean>
    </b:constructor-arg>
</b:bean>

タグを使用するには、JSP でセキュリティ taglib を宣言する必要があります。

<%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags" %>

このタグは、その内容を評価する必要があるかどうかを決定するために使用されます。Spring Security 3.0 では、^[10] の 2 つの方法で使用できます。最初のアプローチでは、タグの  access 属性で指定された Web セキュリティ式を使用し ます。式の評価は、アプリケーションコンテキストで定義された  SecurityExpressionHandler<FilterInvocation> に委譲されます（このサービスが利用可能であることを確認するには、 <http> 名前空間構成で Web 式を有効にする必要があります）。たとえば

<sec:authorize access="hasRole('supervisor')">

This content will only be visible to users who have the "supervisor" authority in their list of <tt>GrantedAuthority</tt>s.

</sec:authorize>

Spring Security の PermissionEvaluator と組み合わせて使用すると、タグを使用して権限を確認することもできます。例：

<sec:authorize access="hasPermission(#domain,'read') or hasPermission(#domain,'write')">

This content will only be visible to users who have read or write permission to the Object found as a request attribute named "domain".

</sec:authorize>

一般的な要件は、ユーザーが実際にクリックすることを許可されている場合にのみ特定のリンクを表示することです。何かが許可されるかどうかを事前に判断するにはどうすればよいですか？ このタグは、特定の URL を属性として定義できる代替モードで動作することもできます。ユーザーがその URL の呼び出しを許可されている場合、タグの本文が評価され、そうでない場合はスキップされます。次のようなものを持っているかもしれません

<sec:authorize url="/admin">

This content will only be visible to users who are authorized to send requests to the "/admin" URL.

</sec:authorize>

このタグを使用するには、アプリケーションコンテキストに  WebInvocationPrivilegeEvaluator のインスタンスも存在する必要があります。名前空間を使用している場合、名前空間は自動的に登録されます。これは  DefaultWebInvocationPrivilegeEvaluator のインスタンスで、指定された URL のダミー Web リクエストを作成し、セキュリティインターセプターを呼び出して、リクエストが成功するか失敗するかを確認します。これにより、 <http> 名前空間構成内の  intercept-url 宣言を使用して定義したアクセス制御セットアップに委譲でき、JSP 内で情報（必要なロールなど）を複製する必要がなくなります。このアプローチは、より具体的な一致のために、HTTP メソッドを提供する  method 属性と組み合わせることもできます。

タグの評価のブール結果（アクセスの許可または拒否）は、 var 属性を変数名に設定することにより、ページコンテキストスコープ変数に格納でき、他の場所で条件を複製および再評価する必要がありません。ページ。

このタグは、セキュリティコンテキストに保存されている現在の  Authentication オブジェクトへのアクセスを許可します。オブジェクトのプロパティを JSP で直接レンダリングします。そのため、たとえば、 Authentication の  principal プロパティが Spring Security の  UserDetails オブジェクトのインスタンスである場合、 <sec:authentication property="principal.username" /> を使用すると現在のユーザーの名前がレンダリングされます。

もちろん、この種のことのために JSP タグを使用する必要はなく、ビューの中にできるだけ少ないロジックを保持することを好む人もいます。MVC コントローラーの  Authentication オブジェクトにアクセスし（ SecurityContextHolder.getContext().getAuthentication() を呼び出すことにより）、データをモデルに直接追加して、ビューでレンダリングすることができます。

このタグは、Spring Security の ACL モジュールで使用する場合にのみ有効です。指定されたドメインオブジェクトに必要なアクセス許可のコンマ区切りリストをチェックします。現在のユーザーがこれらすべての権限を持っている場合、タグの本文が評価されます。そうでない場合はスキップされます。例は

	注意
	一般に、このタグは非推奨と見なされる必要があります。代わりにセクション 15.9.2: “ 承認タグ ” を使用してください。

<sec:accesscontrollist hasPermission="1,2" domainObject="${someObject}">

This will be shown if the user has all of the permissions represented by the values "1" or "2" on the given object.

</sec:accesscontrollist>

許可は、アプリケーションコンテキストで定義された  PermissionFactory に渡され、ACL  Permission インスタンスに変換されます。そのため、ファクトリでサポートされている任意の形式を使用できます。整数である必要はなく、 READ や  WRITE などの文字列でもかまいません。 PermissionFactory が見つからない場合、 DefaultPermissionFactory のインスタンスが使用されます。アプリケーションコンテキストからの  AclService は、提供されたオブジェクトの  Acl インスタンスをロードするために使用されます。 Acl は、すべてが許可されているかどうかを確認するために必要な権限で呼び出されます。

このタグは、 authorize タグと同様に、 var 属性もサポートします。

CSRF 保護が有効になっている場合、このタグは、CSRF 保護トークンの正しい名前と値を持つ非表示フォームフィールドを挿入します。CSRF 保護が有効になっていない場合、このタグは何も出力しません。

通常、Spring Security は、使用する  <form:form> タグに対して CSRF フォームフィールドを自動的に挿入しますが、何らかの理由で  <form:form> を使用できない場合、 csrfInput は便利な代替です。

このタグは、通常は他の入力フィールドを配置する HTML  <form></form> ブロック内に配置する必要があります。このタグを Spring  <form:form></form:form> ブロック内に配置しないでください。Spring Security は Spring フォームを自動的に処理します。

<form method="post" action="/do/something">
    <sec:csrfInput />
    Name:<br />
    <input type="text" name="name" />
    ...
</form>

CSRF 保護が有効になっている場合、このタグは、CSRF 保護トークンフォームフィールドとヘッダー名、および CSRF 保護トークン値を含むメタタグを挿入します。これらのメタタグは、アプリケーションの JavaScript 内で CSRF 保護を採用できます。

csrfMetaTags は、通常は他のメタタグを配置する HTML  <head></head> ブロック内に配置する必要があります。このタグを使用すると、JavaScript を使用してフォームフィールド名、ヘッダー名、トークン値に簡単にアクセスできます。この例では、タスクを簡単にするために JQuery が使用されています。

<!DOCTYPE html>
<html>
    <head>
        <title>CSRF Protected JavaScript Page</title>
        <meta name="description" content="This is the description for this page" />
        <sec:csrfMetaTags />
        <script type="text/javascript" language="javascript">

            var csrfParameter = $("meta[name='_csrf_parameter']").attr("content");
            var csrfHeader = $("meta[name='_csrf_header']").attr("content");
            var csrfToken = $("meta[name='_csrf']").attr("content");

            // using XMLHttpRequest directly to send an x-www-form-urlencoded request
            var ajax = new XMLHttpRequest();
            ajax.open("POST", "https://www.example.org/do/something", true);
            ajax.setRequestHeader("Content-Type", "application/x-www-form-urlencoded data");
            ajax.send(csrfParameter + "=" + csrfToken + "&name=John&...");

            // using XMLHttpRequest directly to send a non-x-www-form-urlencoded request
            var ajax = new XMLHttpRequest();
            ajax.open("POST", "https://www.example.org/do/something", true);
            ajax.setRequestHeader(csrfHeader, csrfToken);
            ajax.send("...");

            // using JQuery to send an x-www-form-urlencoded request
            var data = {};
            data[csrfParameter] = csrfToken;
            data["name"] = "John";
            ...
            $.ajax({
                url: "https://www.example.org/do/something",
                type: "POST",
                data: data,
                ...
            });

            // using JQuery to send a non-x-www-form-urlencoded request
            var headers = {};
            headers[csrfHeader] = csrfToken;
            $.ajax({
                url: "https://www.example.org/do/something",
                type: "POST",
                headers: headers,
                ...
            });

        <script>
    </head>
    <body>
        ...
    </body>
</html>

CSRF 保護が有効になっていない場合、 csrfMetaTags は何も出力しません。