0Pricing
Spring Security 6 & JWT Authentication · レッスン

カスタムアクセスルールでエンドポイントを保護する

単純なロールチェックを超えて、AuthorizationManager、SpEL式、リクエストマッチャーを使い、Spring Security 6でカスタム認可ロジックを記述します。

「カスタムアクセスルールでエンドポイントを保護する」はCoddyKit上の無料Spring Security 6 & JWT Authenticationレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはSpring Security 6 & JWT Authentication学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Spring Security 6 & JWT Authenticationコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Custom Access Rules?

Roles and methods cover most cases, but real apps need finer control: only the owner of a resource may edit it, or access depends on the time of day or a feature flag.

Spring Security 6 lets you express these rules declaratively or programmatically.

The authorizeHttpRequests DSL

In Spring Security 6 the modern way to secure URLs is authorizeHttpRequests. Each matcher maps a request pattern to an access rule.

http.authorizeHttpRequests(auth -> auth
    .requestMatchers('/public/**').permitAll()
    .requestMatchers('/admin/**').hasRole('ADMIN')
    .anyRequest().authenticated());

Matching by HTTP Method

You can scope rules to a specific HTTP method, so reads and writes have different requirements.

http.authorizeHttpRequests(auth -> auth
    .requestMatchers(HttpMethod.GET, '/api/orders/**').authenticated()
    .requestMatchers(HttpMethod.POST, '/api/orders/**').hasRole('MANAGER'));

SpEL with access()

The access() rule takes a Spring Expression Language (SpEL) condition for dynamic logic that plain matchers cannot express.

http.authorizeHttpRequests(auth -> auth
    .requestMatchers('/reports/**')
    .access(new WebExpressionAuthorizationManager(
        "hasRole('ANALYST') and request.getHeader('X-Region') == 'EU'")));

The AuthorizationManager Interface

For full control, implement AuthorizationManager. It returns an AuthorizationDecision that grants or denies access based on the authentication and the request.

public interface AuthorizationManager<T> {
    AuthorizationDecision check(Supplier<Authentication> auth, T object);
}

Writing a Custom AuthorizationManager

Here is a manager that only allows access during business hours. The supplier gives the current user; the object holds request context.

AuthorizationManager<RequestAuthorizationContext> businessHours =
    (auth, ctx) -> {
        int hour = LocalTime.now().getHour();
        boolean ok = hour >= 9 && hour < 18;
        return new AuthorizationDecision(ok);
    };

Plugging It In

Attach your custom manager to a matcher with access(). Any request to the path is now evaluated by your logic.

http.authorizeHttpRequests(auth -> auth
    .requestMatchers('/maintenance/**').access(businessHours)
    .anyRequest().authenticated());

Owner-Based Access

A common rule: only the resource owner can modify it. You can read a path variable from the request context to compare against the logged-in user.

AuthorizationManager<RequestAuthorizationContext> ownerOnly =
    (auth, ctx) -> {
        String pathUser = ctx.getVariables().get('userId');
        boolean same = auth.get().getName().equals(pathUser);
        return new AuthorizationDecision(same);
    };

Combining Rules

Spring evaluates matchers top to bottom and stops at the first match. Order matters: put specific rules before broad ones, and always end with a catch-all like anyRequest().

Denying by Default

A secure baseline denies everything not explicitly allowed. Use denyAll() as the final rule when you want a strict allow-list.

http.authorizeHttpRequests(auth -> auth
    .requestMatchers('/health').permitAll()
    .anyRequest().denyAll());

Testing Access Rules

Verify your rules with @WithMockUser and MockMvc. Assert that authorized users get 200 and unauthorized users get 403.

mockMvc.perform(get('/admin/dashboard'))
    .andExpect(status().isForbidden());

Quick Check

Test your understanding of custom access rules.

Recap

You learned to write custom authorization in Spring Security 6:

  • Use the authorizeHttpRequests DSL with path and method matchers
  • Apply SpEL conditions via access()
  • Implement AuthorizationManager for dynamic, owner-based, or time-based rules
  • Order matters; end with a catch-all and prefer deny-by-default

These tools let you enforce business-specific security policies precisely.

よくある質問

「カスタムアクセスルールでエンドポイントを保護する」レッスンは無料ですか？

はい。「カスタムアクセスルールでエンドポイントを保護する」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Spring Security 6 & JWT Authenticationコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Spring Security 6 & JWT Authenticationコースには全4レッスンが含まれています。

「カスタムアクセスルールでエンドポイントを保護する」で何を学びますか？

単純なロールチェックを超えて、AuthorizationManager、SpEL式、リクエストマッチャーを使い、Spring Security 6でカスタム認可ロジックを記述します。 ブラウザで直接実行するハンズオンコードでSpring Security 6 & JWT Authenticationを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Spring Security 6 & JWT Authenticationを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのSpring Security 6 & JWT Authenticationは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。

「カスタムアクセスルールでエンドポイントを保護する」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このSpring Security 6 & JWT Authenticationレッスンでコードを書いて実行できますか？

はい。すべてのSpring Security 6 & JWT Authenticationレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. ロールベースアクセス制御（RBAC）
  2. アノテーションによるメソッドレベルセキュリティ
  3. HttpSecurity設定の詳細
  4. カスタムアクセスルールでエンドポイントを保護する
← Spring Security 6 & JWT Authenticationに戻る