コンテンツにスキップ
utm-backend Docs

飛行計画機能 forDemo 認証仕様

認証仕様（飛行計画機能 forDemo）

Section titled “認証仕様（飛行計画機能 forDemo）”

本ドキュメントは、飛行計画機能 forDemo（10月デモ向け）の認証・認可方針を定義する。認証の詳細は共通認証仕様（AuthenticationSpecification_Common.md）を参照すること。forDemo では認証なしで実装し、以降のスプリントで認証連携を追加実装する。

1. forDemo の認証方針

Section titled “1. forDemo の認証方針”

forDemo では認証サービス（auth-service）が存在しないため、認証なしで実装する。以降のスプリントで認証連携を追加実装する。

認証の全体設計・auth-service 仕様・JWT 仕様・RBAC 等の詳細については、共通認証仕様（AuthenticationSpecification_Common.md）を参照すること。

2. forDemo 実装方針（認証なし）

Section titled “2. forDemo 実装方針（認証なし）”

forDemo では、認証関連の実装・依存関係を最小構成にするため、Spring Security 自体を導入しない。

  • spring-boot-starter-security 依存を build.gradle.kts に追加しない
  • SecurityConfig クラスを作成しない（@EnableWebSecurity も使用しない）
  • JWT検証フィルターを実装しない
  • TransactionSessionInitializer は no-op（何もしない）実装とする
  • PostgreSQL RLSは実装しない
  • SecurityContextHolder にユーザー情報を保持しない（Spring Security自体が存在しないため）

Spring Securityが存在しないため、認証チェックの仕組みそのものが無い。そのため Authorization ヘッダを付与せずにcurl等でAPIを実行しても、401（Unauthorized）が返ることはない。

2.1 forDemo コード例

Section titled “2.1 forDemo コード例”
// TransactionSessionInitializer（forDemo：no-op）
// 認証仕様確定後、set_config()関数（バインドパラメータ使用、SQLインジェクション対策）でRLS用のセッション変数を設定する
// 実装方式の詳細は AuthenticationSpecification_Common.md 27節を参照
@FunctionalInterface
public interface TransactionSessionInitializer {


  void initializeSession();
}

2.2 認証連携の追加実装手順

Section titled “2.2 認証連携の追加実装手順”

auth-service 実装後、以下を追加実装する。forDemoではSpring Security自体が存在しないため、既存設定の差し替えではなく、以下を新規に構築する。

  1. spring-boot-starter-security 依存を追加する
  2. SecurityConfig（@EnableWebSecurity）を新規作成し、JWT検証フィルターを実装する（実装方式は AuthenticationSpecification_Common.md 第 23.1 節参照。判断不可。要確認。）
  3. SecurityContext に user_id / org_id / permissions を格納する
  4. TransactionSessionInitializer を実装し、SET LOCAL ROLE と set_config('app.current_user_id', ?, true)（バインドパラメータ使用）を実行する
  5. 内部APIは認証不要（permitAll）設定とする
  6. 外部APIには JWT 検証フィルターを適用する
  7. 飛行計画機能では、organization_idによるデータ分離（FLIGHT_PLAN.organization_id。所属組織に属するユーザから登録された計画のみ一覧・詳細取得可能）をRLSポリシーとして追加する（listFlightPlansの説明「IX-UTMにログインしているユーザが所属している組織に属するユーザから登録された飛行計画」に対応。forDemoではRLSが無いため、この絞り込みはアプリケーション層の実装に委ねる。5節参照）

3. 認証対象外節（forDemo では実装対象外）

Section titled “3. 認証対象外節（forDemo では実装対象外）”

以下の節は forDemo では実装対象外とする。詳細は AuthenticationSpecification_Common.md を参照すること。

対象外項目参照節（AuthenticationSpecification_Common.md）
auth-service 連携（認証フロー・auth-service 設計）第 5 節〜第 6 節
OIDC Verifier / User Resolver（auth-service 実装）第 11 節〜第 12 節
RBAC / Permission 設計第 14 節〜第 18 節
内部JWT検証（バックエンドサービス側）第 23 節
RLS（PostgreSQL Row Level Security）第 26 節〜第 30 節
JWT 鍵管理第 31 節〜第 35 節
Caddy 連携第 36 節
Proxy Handler / エラー応答（認証エラー）第 37 節〜第 40 節

上記はいずれも「forDemo では実装対象外。詳細は AuthenticationSpecification_Common.md を参照すること。」

4. UTM Backends（飛行計画機能）実装時の前提

Section titled “4. UTM Backends（飛行計画機能）実装時の前提”

飛行計画機能（Java Spring Boot、UTM Backends共通レイヤに実装。ArchitecturePolicy_Flightplanning_forDemo.md3節参照）の実装では、以下を前提とする。

  • 外部JWTを検証しない
  • 内部JWTのみを検証する（forDemo では no-op）
  • 内部JWTから user_id / org_id / permissions を取り出す（forDemo では SecurityContext 未使用）
  • リクエストコンテキスト（SecurityContextHolder）に認証済みユーザー情報を保持する
  • TransactionManager.execute 経由で TransactionSessionInitializer を呼び出す
  • DBトランザクション開始時にRLS用の値を設定する（forDemo では no-op）
  • 業務処理では必要に応じてPermissionを再確認してよい
  • EntityやレスポンスDTOに不要な認証情報を含めない
  • forDemoではSpring Security自体を導入しない。将来導入する際は、コンストラクタインジェクションで依存を解決する（AppConfig の @Bean で登録）

飛行計画機能固有の留意点: listFlightPlans（一覧取得）は、本来「ログインユーザが所属している組織に属するユーザから登録された飛行計画」に絞り込む必要がある（BusinessLogicSpecifications.md参照）。forDemoでは認証情報（organization_id）を取得できないため、この絞り込みは実装対象外とする（全件を対象とする）。認証連携実装後は、本来RLSで透過的にフィルタされる設計（listFlightPlansのOAS説明）に従う。

5. Claude Code への実装指示

Section titled “5. Claude Code への実装指示”

Claude Code は認証・認可に関するコード生成時、以下を遵守すること。

  • 認証ロジックはアプリ本体から分離する
  • auth-service がOIDC検証を担当する
  • UTM Backends（Java Spring Boot）は外部IdPに直接依存しない
  • UTM Backends は内部JWTのみを信頼する
  • 複数IdPは iss クレームにより動的選択する
  • IdP設定は idp_connections を参照する
  • subjectから内部 user_id / org_id を解決する
  • RBACは roles / permissions / role_permissions を使用する
  • APIルート単位でPermissionチェックを行う
  • 内部JWTはRS256で署名する
  • 内部JWTのTTLは15分とする
  • JWT秘密鍵はAWS Secrets Managerから取得する前提とする
  • 秘密鍵をソースコードに直書きしない
  • 飛行計画機能ではトランザクションごとに TransactionSessionInitializer.initializeSession() を呼び出す（forDemo では no-op）
  • ALB OIDCは使用しない
  • SAMLは現時点では実装対象外。ただし将来拡張を妨げない構成とする
  • forDemo では Spring Security 自体を導入しない（spring-boot-starter-security 依存を追加しない、SecurityConfig を作成しない）。JWT検証フィルターも実装しない
  • forDemo では TransactionSessionInitializer は no-op とする
  • エラーレスポンスは RFC 9457 Problem Details 形式とする
  • アーキテクチャ方針は ArchitecturePolicy_Common.md および ArchitecturePolicy_Flightplanning_forDemo.md に従う

6. 実装対象外

Section titled “6. 実装対象外”

明示的な追加仕様がない限り、以下は実装対象外とする。

  • ALB OIDC認証
  • SAML認証の本実装
  • IdP管理画面
  • ユーザー管理画面
  • ロール管理画面
  • Permission管理画面
  • 独自パスワード認証
  • MFAの独自実装
  • OAuth2 Authorization Server実装
  • refresh token発行機能
  • ブラウザセッション管理
  • フロントエンド実装
  • UTM Backends 内でのOIDC検証（auth-serviceの責務）
  • JWT秘密鍵の管理（auth-serviceの責務）

7. 生成後の確認観点

Section titled “7. 生成後の確認観点”

Claude Code による生成後は、以下を確認すること。

  • auth-serviceとUTM Backendsの責務が分離されていること
  • UTM Backendsが外部JWTを直接信頼していないこと
  • issuerによりIdPを動的選択していること（auth-service側）
  • idp_connectionsを参照していること（auth-service側）
  • OIDC Verifierで署名、issuer、audience、expを検証していること（auth-service側）
  • subjectから内部user_idへ解決していること（auth-service側）
  • org_idを解決していること
  • roles / permissionsをDBから解決していること（auth-service側）
  • APIルート単位のPermissionチェックがあること（auth-service側）
  • 内部JWTがRS256で署名されていること
  • 内部JWTのTTLが15分であること
  • 秘密鍵がコードに直書きされていないこと
  • Secrets Managerから秘密鍵を取得する前提になっていること
  • forDemo では Spring Security の依存関係・SecurityConfig が一切存在しないこと
  • forDemo では TransactionSessionInitializer が no-op であること
  • UTM Backendsのエラーレスポンスが RFC 9457 Problem Details形式であること
  • AuthorizationヘッダやJWT全文をログ出力していないこと
  • 401と403の使い分けが適切であること
  • 将来のSAML対応を妨げない設計になっていること
  • 将来の認証追加を妨げない設計になっていること（no-opの差し替えが可能）