セキュリティと権限

セッション認証、CSRF、JWT、セキュリティヘッダー、そして resource:action 権限モデル。

セキュリティと権限

ログインフロー

sequenceDiagram
    participant Form as Login Form
    participant Auth as Auth.bx doLogin()
    participant Sec as SecurityService
    participant Store as cbauth / Session Cache

    Form->>+Auth: POST /login (email + password)
    Auth->>Auth: CSRF check + cbvalidation
    Auth->>+Sec: authenticate( email, password )
    Sec->>Sec: bcrypt verify
    Sec->>+Store: cbauth.login() — write session
    Store-->>-Sec: ok
    Sec-->>-Auth: authenticated user
    Auth-->>-Form: redirect → /dashboard

認証レイアウト

認証フローは、cbLoginLayout 設定を通じて、同梱されているどちらのレイアウトも使用できます。

/settings ページで Auth Center または Auth Split を選択してください。選択したレイアウトは、ログイン、登録、招待の有効化、パスワード復旧の各ページに適用されます。レイアウトファイルとカスタムレイアウトの手順については、アプリ設定 を参照してください。

シングルサインオン

cbSSO は app/config/modules/cbsso.bx を通じて有効化されます。cbauth をセッションの 権威として使用しているため、ローカルのパスワードログイン、パスキー、SSO は同じ セッションと認可ルールを共有します。ログインページには、設定済みのプロバイダーごとに リンクがレンダリングされます。

Google が同梱されている例のプロバイダーです。Google にコールバック URL /cbsso/auth/Google を登録した後、.env に以下の値を設定してください。

GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
GOOGLE_REDIRECT_URI=https://example.com/cbsso/auth/Google

SSO の有効化と無効化

独立した SSO_ENABLED 設定はありません。実質的なプロバイダーの切り替えは app/config/modules/cbsso.bx にあります。cbGenesis は GOOGLE_CLIENT_ID、GOOGLE_CLIENT_SECRET、GOOGLE_REDIRECT_URI がすべて設定されている ときにのみ Google を登録します。Google SSO を無効にするには、これらの値のいずれか 1 つを クリアして、アプリケーションを再起動または再初期化してください。プロバイダーは、ログインや プロフィールのページに表示されなくなります。

これを enableCBAuthIntegration: false と混同しないでください。その設定は cbSSO の オプションの汎用 cbauth リスナーを無効にするものです。cbGenesis はローカルのアカウント 連携、プロビジョニング、アイデンティティの照合、監査ルールを強制できるよう、独自の SSOAuthorization インターセプターを使用しています。上流の契約や代替の汎用連携については、 cbSSO のドキュメントの設定、 アイデンティティプロバイダーのレスポンス処理、 インターセプションポイント、 cbauth 連携 を参照してください。

box migrate up

https://your-domain.example/cbsso/auth/Google

GOOGLE_CLIENT_ID=your-google-client-id
GOOGLE_CLIENT_SECRET=your-google-client-secret
GOOGLE_REDIRECT_URI=https://your-domain.example/cbsso/auth/Google

CBSSO_AUTO_PROVISION=true
CBSSO_ALLOWED_DOMAINS=example.com,example.org

セットアップ後、アイデンティティはプロバイダーと不変のサブジェクトによって照合され、 メールアドレスだけで照合されることは決してありません。既存のローカルアカウントは、 SSO 経由で使用される前に明示的にリンクされている必要があります。

クラスター化された SAML デプロイでは、デフォルトのインメモリなリプレイキャッシュを 使う代わりに、cbSSO の samlRequestCacheName を分散型の CacheBox リージョンに 設定してください。

cbSSO がどのようにローカルセッションになるか

cbSSO はプロバイダーのプロトコルとコールバックの検証を所有します。cbGenesis はその後に 続く判断を所有します。検証済みのアイデンティティがどのローカルアカウントに属するか、 それがプロビジョニングまたはリンク可能かどうか、そしてそれがどのように認証済みの アプリケーションセッションになるか、です。

flowchart LR
    Browser[Browser] --> Start[cbSSO start route]
    Start --> Provider[Identity provider]
    Provider --> Callback[cbSSO callback route]
    Callback --> Authorize[cbSSO Auth.authorize]
    Authorize --> Event[CBSSOAuthorization]
    Event --> Interceptor[SSOAuthorization.bx]
    Interceptor --> UserService[UserService]
    UserService --> Identity[(SSO identity records)]
    Interceptor --> Security[SecurityService.loginSSO]
    Security --> Session[(cbauth session)]
    Session --> Browser

アプリケーションは、cbSSO のドキュメント化された CBSSOAuthorization インターセプション ポイントに対して app/interceptors/SSOAuthorization.bx を登録しています。コールバックの ペイロードには、検証済みのプロバイダーレスポンスと、それを処理したプロバイダーが含まれます。 インターセプターは、次の 2 つのアプリケーション所有のパスのいずれかをたどります。

sequenceDiagram
    participant C as cbSSO callback
    participant I as SSOAuthorization
    participant U as UserService
    participant S as SecurityService
    participant A as AuditLogService

    C->>I: CBSSOAuthorization(response, provider)
    alt Link intent
        I->>I: Verify logged-in user and matching session intent
        I->>U: linkSSOIdentity(user, response, provider)
        U-->>I: Linked identity
        I->>A: Record link success
    else Login intent
        I->>U: findBySSO(response, provider)
        alt No local identity and provisioning allowed
            I->>U: createFromSSO(response, provider)
        end
        I->>U: updateFromSSO(user, response, provider)
        I->>S: loginSSO(user)
        S-->>I: cbauth session established
        I->>A: Record login or provisioning success
    end
    I-->>C: Store success or failure result for completion flow

このインターセプターが存在する理由

cbSSO は汎用の cbAuth 連携リスナーも提供します。cbGenesis は app/config/modules/cbsso.bx で意図的に enableCBAuthIntegration: false を 設定しています。なぜなら、汎用リスナーではアプリケーションのアイデンティティと アカウントセキュリティのルールを強制できないからです。このカスタムインターセプターは 次のことに責任を持ちます。

• アイデンティティをプロバイダーと不変のサブジェクトで照合し、メールアドレスだけで 照合しないこと。
• アカウントリンクに対して、認証済みセッションと一致する意図を要求すること。
• ユーザーを作成する前に、プロビジョニングと許可ドメインのポリシーを適用すること。
• ローカルパスワード、リメンバーミー、パスキー、SSO の各認証パスを、同じ cbauth セッション権威の下に保つこと。
• 成功・失敗した SSO 操作を監査トレイルに記録すること。

この分離は意図的なものです。cbSSO はプロバイダーが誰であると言っているかを 検証し、cbGenesis はそのアイデンティティがこのアプリケーションで何を行うことを 許可されているかを決定します。

上流の契約と代替の汎用連携については、 cbSSO のインターセプションポイント、 アイデンティティプロバイダーのレスポンス処理、 cbauth 連携 のドキュメントを参照してください。

セキュリティレイヤー

レート制限

app/interceptors/RateLimiter.bx は preProcess(ルーティングの前、どのハンドラーが 実行されるよりも前)で発火し、5 つの未認証の Auth エンドポイントをクライアント IP ごとに 制限します。

• doLogin、doRegister、doForgotPassword、doResetPassword、doActivateInvitation

上限を超えた呼び出し元は、フラッシュエラーとともにフォームへリダイレクトされます。リクエストは ハンドラーに到達しないため、ブロックされている間に正しいパスワードを送信してもユーザーは ログインできません。

3 つとも、他のアプリ設定と同様に /settings で編集できます - 詳細は アプリ設定 を参照してください。

カウントの仕組み

RateLimitService.attempt() はスライディングウィンドウです。許可されたものであれ ブロックされたものであれ、すべての試行がそのキーの有効期限をその時点から完全な期間まで リセットします。キーは、期間全体にわたって静かになったときにのみクールダウンします - これに より、攻撃が続く限りブロックし続けることになり、途中で再び開くことはありません。各 エンドポイントは独自のカウンター(event:ip をキーとします)を持つため、ログインの上限に 達しても登録やパスワードリセットには影響しません。

cbsecurity の設定

app/config/modules/cbsecurity.bx は、ファイアウォールの単一の信頼できる情報源です。

{
    authentication : {
        provider          : "authenticationService@cbauth",
        prcUserVariable   : "authUser"
    },
    firewall : {
        autoLoadFirewall         : true,
        validator                 : "CBAuthValidator@cbsecurity",
        handlerAnnotationSecurity : true,
        invalidAuthenticationEvent : "login",
        invalidAuthorizationEvent  : "dashboard.notAuthorized",
        rules                      : [] // authorization is annotation-based, not rule-based
    }
}

• prcUserVariable: "authUser" — 認証済みユーザーは常に、すべてのハンドラー、ビュー、レイアウトで prc.authUser として利用できます。
• handlerAnnotationSecurity: true — これが、ハンドラークラスやアクション上の @secured アノテーションに実際に効力を持たせるものです。
• rules: [] — このアプリはすべての認可をハンドラーのアノテーションで行っており、cbsecurity の代替となる URL パターンのルールリストは使用しません。

権限モデル

すべての権限は resource:action という形式のスラッグであり、resources/database/seeds/AdminData.bx によってシードされます。

ハンドラーで強制する — これが実際のセキュリティ境界であり、認証済みユーザーの権限に対して cbsecurity の CBAuthValidator によって解決されます。

@secured( "roles:admin,roles:read" )     // class-level: applies to index and any action without its own annotation
class extends="BaseSecureHandler" {

    @secured( "roles:admin,roles:write" )
    function create( event, rc, prc ) { ... }

    @secured( "roles:admin,roles:delete" )
    function delete( event, rc, prc ) { ... }

}

カンマ区切りのリストは OR チェックです — 挙げられた権限のいずれか 1 つがあれば十分です。

ビューでミラーする — これは UX のためだけのものであり、単体では決してセキュリティ境界にはなりません。User.bx は prc.authUser 上に hasPermission() を公開しており、保護されたハンドラーを通じてレンダリングされる任意のビューやレイアウトで利用できます。

<bx:if prc.authUser.hasPermission( "roles:write,roles:admin" )>
    <button type="button" class="btn btn-primary" @click="openCreate()">New Role</button>
</bx:if>

hasPermission() は文字列、カンマ区切りリスト、配列を受け付け、OR チェックを行います。hasAllPermissions() は AND の等価版です。どちらも getAllPermissions() を通じてリクエストごとにキャッシュされ、これはユーザー個別に割り当てられた権限と、ロールを通じて付与されたすべての権限を統合します。既存のすべての管理ビュー(サイドバーナビゲーション、Users/Roles/Permissions/Settings)はすでにこのパターンに従っています — 新しい保護されたモジュールのテンプレートとして扱ってください。

@secured チェックに失敗したユーザーはリダイレクトされます。

• 未認証 → login
• 認証済みだが権限がない → dashboard.notAuthorized

関連するセキュリティサービス

既知の問題

パスキー登録時の「This is an invalid domain」

パスキーは、ローカル開発時には localhost ドメイン向けに設定されています。http://127.0.0.1:8080 のような IP アドレスでアプリケーションを開くと、WebAuthn はそれを別のオリジンとして扱い、「This is an invalid domain.」 というエラーで登録を拒否します。

代わりに http://localhost:8080 でアプリケーションを開いてください。あるオリジン向けに登録されたパスキーは別のオリジンとは互換性がないため、別のホスト名を使用していたときに作成されたパスキーは、削除して再登録してください。