CAS
Provides Central Authentication Service (CAS) single sign-on authentication for Drupal websites.
cas
インストール
composer require 'drupal/cas:^2.3'
概要
CASモジュールは、Central Authentication Service（CAS）プロトコルを実装します。これはウェブ用のシングルサインオン/シングルサインオフプロトコルで、ユーザーが中央のCASサーバーアプリケーションに一度だけ認証情報を提供することで、複数のアプリケーションにアクセスできるようにします。
CASのようなシングルサインオンサービスを使用することは、利便性（ユーザーが複数のウェブサービスの認証情報を覚える必要がない）とセキュリティ（Drupalウェブサイトがユーザーのパスワードを見ることがない）の両面で有益です。このモジュールはCASプロトコルのバージョン1、2、3を実装しています。
主な機能には、自動ユーザー登録、特定ページでの強制ログイン、ユーザーがすでにアクティブなCASセッションを持っている場合のシームレスなログインのためのゲートウェイ認証、シングルログアウトサポート、CASプロキシ機能、および他のモジュールがサブスクライブできるイベントによる広範なカスタマイズが含まれます。
Features
- CASプロトコルバージョン1.0、2.0、3.0によるシングルサインオン（SSO）認証
- 設定可能なメール割り当て戦略を持つ初回CASログイン用の自動ユーザー登録
- 特定のページまたはパスでCAS認証を要求する強制ログイン機能
- 認証を強制せずに既存のアクティブなCASセッションを持つユーザー向けのゲートウェイログイン（自動ログイン）
- CASサーバーからログアウトしたときにDrupalからもユーザーをログアウトさせるシングルログアウト（SLO）サポート
- 他のサービスからCAS保護リソースにアクセスするためのCASプロキシサポート
- CASユーザーの通常のDrupalログインの防止（推奨セキュリティ機能）
- CASユーザーのパスワードおよびメール管理の制限
- ユーザー登録時の自動ロール割り当て
- トークン置換をサポートする設定可能なエラーメッセージ
- CAS認証の問題をトラブルシューティングするためのデバッグログ
- CASユーザーを事前登録するための一括ユーザー作成
- 管理者向けのユーザープロフィールフォームでのCASユーザー名管理
- シームレスなアクセス拒否からログインへのフローのための「r4032login」モジュールとの連携
- 他のモジュールが認証プロセスにフックできるイベント駆動型アーキテクチャ
- クライアント側およびサーバー側のゲートウェイリダイレクト方式
- Drupal 7からDrupal 10以降へのCASユーザー移行サポート
Use Cases
Enterprise Single Sign-On
Deploy CAS authentication for an organization where users authenticate once with their corporate credentials and gain access to the Drupal site along with other CAS-enabled applications. Enable 'Prevent normal login' and 'Restrict password management' for security, and configure automatic user registration to streamline onboarding.
University Portal Integration
Integrate a Drupal site with a university's existing CAS infrastructure. Students and staff log in using their university credentials. Use the CAS Attributes module to automatically assign roles based on attributes like department or student status returned by the CAS server.
Intranet with Seamless Authentication
Configure gateway login for an intranet site where users who are already authenticated to the organization's CAS server are automatically logged into Drupal without any additional action. This provides a seamless experience for internal users.
Restricted Content Access
Use forced login on specific content paths (like /admin or /private/*) to require CAS authentication for accessing sensitive areas while keeping other parts of the site publicly accessible. Combine with the r4032login module for automatic authentication on access denied pages.
Multi-site SSO with Single Logout
Enable single logout (SLO) so that when users log out of the CAS server or any other CAS-enabled application, they are automatically logged out of the Drupal site as well, maintaining consistent session state across all applications.
Proxy Authentication for Web Services
Configure CAS proxy functionality to allow the Drupal site to access other CAS-protected resources (like web services or APIs) on behalf of the authenticated user, using proxy tickets obtained during the initial authentication.
Pre-provisioned User Accounts
Use the bulk add CAS users feature to pre-register user accounts with specific roles before users authenticate for the first time. This is useful for course enrollment systems or employee onboarding where accounts need to exist before first login.
Tips
- Always use HTTPS for CAS server communication in production environments to protect authentication tickets
- Install the Token module to see available tokens for customizing error messages with dynamic values like the CAS login URL
- Use debug logging temporarily during initial setup to diagnose configuration issues, but disable it in production to keep logs clean
- The /caslogin path (or /cas legacy path) can be linked from anywhere on your site to trigger CAS authentication
- Add a 'destination' query parameter to the /caslogin URL to redirect users to a specific page after authentication: /caslogin?destination=/node/123
- Consider using the CAS Attributes module if your CAS server returns user attributes that should be mapped to Drupal fields or roles
- For high-traffic sites using gateway login, prefer the client-side redirect method to maintain page caching compatibility
- Set a login failure page to prevent redirect loops when forced login is enabled and authentication fails
Technical Details
Admin Pages 2
/admin/config/people/cas
Configure CAS server connection, authentication behavior, user account handling, error messages, and advanced options for CAS single sign-on authentication.
/admin/people/create/cas-bulk
Pre-register one or more CAS users by providing their CAS usernames, allowing them to log in using CAS before they authenticate for the first time.
権限 2
Hooks 8
hook_cron
Cleans up stale proxy granting tickets (older than 1 hour) and expired single logout session mapping data based on configured lifetime.
hook_user_role_delete
Removes deleted roles from the auto-assigned roles configuration to prevent configuration errors.
hook_user_logout
Removes session data from the cas_login_data table when a user logs out of Drupal.
hook_form_user_form_alter
Adds CAS username fields to the user entity form, allowing administrators to associate CAS usernames with Drupal accounts.
hook_form_user_login_form_alter
Adds a CAS login link to the standard Drupal login form when configured, and prevents CAS users from using normal login.
hook_form_user_pass_alter
Adds validation to the password reset form to prevent CAS users from resetting their Drupal password when restricted.
hook_validation_constraint_alter
Replaces core's ProtectedUserFieldConstraint with a decorated version that skips validation when restricted password management is enabled for CAS users.
hook_menu_links_discovered_alter
Adds 'Add CAS user(s)' menu item to the People admin menu when the Admin Toolbar Tools module is enabled.
Troubleshooting 7
Enable debug logging in Advanced settings to see detailed error messages. Common causes include incorrect CAS server hostname/port, SSL certificate verification failures, or network connectivity issues between the Drupal server and CAS server.
If using a self-signed certificate or private CA, either add the CA certificate to your web server's trust store, or configure a custom CA certificate path in the CAS settings. Never disable SSL verification in production.
Verify that roles are selected in 'Automatically assign roles on user registration' setting. For attribute-based role assignment, install and configure the CAS Attributes module.
Ensure the gateway recheck time is not set to 'Every page request' when using client-side redirect method. Also verify that gateway paths are correctly configured and not including CAS-related paths.
Verify that your CAS server supports SLO and is properly configured to send logout requests. Check that the cas_login_data table is being populated (session IDs are stored). Note: SLO requires storing un-hashed session IDs.
Enable 'Restrict password management' in User Account Handling settings. This prevents CAS users from using the forgot password functionality.
Ensure the user account has a CAS username association in the authmap table. Administrators can set this on the user profile form by enabling 'Allow user to log in via CAS' and providing the CAS username.
Security Notes 6
- Single logout (SLO) stores session IDs un-hashed in the database, which is a deviation from Drupal's default session security hardening. Only enable SLO if required by your organization's authentication policy.
- Never disable SSL certificate verification in production environments. This makes the site vulnerable to man-in-the-middle attacks.
- The 'Prevent normal login for CAS users' setting is strongly recommended to ensure CAS users cannot bypass CAS authentication even if they know their randomly-generated Drupal password.
- Proxy functionality should only be enabled when necessary, and proxy chains should be strictly configured to allow only trusted proxy servers.
- Debug logging should never be enabled in production as it may log sensitive authentication information to the Drupal watchdog.
- CAS users' Drupal passwords are randomly generated 30-character strings. While theoretically brute-forceable, preventing normal login eliminates this attack vector entirely.