中央認証サービス（CAS）プロトコルについて
中央認証サービス（CAS）は、Webサイトがユーザーを認証できるようにするシングルサインオン（SSO）プロトコルです。
ログイン資格情報は、安全なパスワードを明らかにすることなく、認証のために複数のアプリケーションに対して一度だけ使用されます。認可を必要とするアプリケーションは、一元化された信頼できる単一サーバーであるCASサーバーにユーザーをリダイレクトします。
CASプロトコルを使用することで、アクセスのためにサービスチケットを必要とする信頼できないWebアプリケーションを認証できます。CASはユーザーを認証するためのツールですが、これはユーザーを認可することと同義ではありません。認可は、実際のアプリケーションに固有のものです。
CASのアプローチは、保守が簡単であり、初期構成後に大規模なコンピューターネットワークに容易に配布できます。ユーザーに利便性、一貫性、そして高いレベルのセキュリティを提供できます。
中央認証サービス（CAS）について
CASは、複数のWebアプリケーションにSSO（シングルサインオン）ソリューションを提供し、よりシームレスなエンドユーザーエクスペリエンスを実現できます。集中認証サーバーであるCASサーバーは、認証目的で使用できる信頼できるソースです。
CASプロトコルと認可フローは次のとおりです。
- ユーザーが、まだ検証されていないWebアプリケーションにアクセスを試みます。CAS化されたアプリケーション（CASサービスを使用するWebアプリケーション）へのアクセスを試みるのはこれが初めてです。
- ユーザーがCASサーバーにリダイレクトされます。
- 次に、ユーザーはCASサーバーでログイン資格情報を1回入力し、CASサーバーはユーザーが本人かどうかを判断します。
- ユーザーがCASサーバーを介して認証されると、サービスチケットがURLに添付されます。
- 次に、アプリケーションはCASサーバーに要求を送信し、サービスチケットを検証します。チケットが有効であれば、ユーザーは認証され、アプリケーションに返されます。
CASを使用すると、ユーザーはシングルサインオンセッション内でアプリケーションを切り替えるときに、このプロセスを繰り返す必要がありません。ユーザーが集中認証システムにサインインすると、同じセッションで複数回再認証を行うことなく認証状態を示すように、Cookieまたはシステムデータが設定されます。
CASの主要コンポーネント
CASプロトコルと認証フローには、3つ（または4つ）のコンポーネントが関与します。
- クライアントのWebブラウザ：CASサービスを使用してWebアプリケーションに組み込まれるソフトウェアです。
- Webアプリケーション：認証を求めるアプリケーションです。
- CASサーバー：CASサービスを使用してユーザーを認証し、Webアプリケーションへのアクセスを許可するために使用されるスタンドアロンのコンポーネントです。
- バックエンドサービス：CASプロトコルでは、データベースサーバーが使用されることもあります。このサーバーは、独自のHTTPインターフェイスを持ちませんが、Webアプリケーションと通信できます。
CASは、CASプロトコルを使用するソフトウェアパッケージを指すこともあります。
WebサイトでCASを使用する方法
アプリケーションにCASプロトコルを統合するには、まずCASサーバーを指定します。これらのアプリケーションの認証を求めるすべてのユーザーは、CASサーバーにログインする必要があります。CASは事実上すべてのWebアプリケーションに統合でき、Java、Python、PHP、PL/SQLなど多くのプログラミング言語をサポートしています。
CASを使用して認証できるクライアントライブラリも多様に存在します。PHPの場合は、phpCASライブラリを使用できます。Python（FlaskとDjangoを含む）の場合は、python-CASライブラリが最適です。他の言語を使用している場合は、既存のライブラリを検索できます。
CASプロトコルはオープンソースであり、公開されています。CASプロトコルの仕組みと実装方法の詳細は、こちらをご覧ください。
Authentication vs. Authorization（認証 vs. 承認）
認証と認可は同義ではありません。
CASプロトコルは、Webアプリケーションへのユーザーのアクセスを認証するだけであり、ユーザーの認可は提供しません。ユーザーがログイン資格情報を使用してCASサーバーにログインすると、CAS認証によってユーザーが誰であるかが判別され、誰がログインしているかが記録されます。しかし、パスワードとログインの情報をアプリケーションが直接「見る」ことはありません。
アプリケーション内で認可アクセスと特権を持つユーザーを決定してシステムにセットアップする必要があります。たとえば、特定のユーザーIDに「管理者」特権を設定して、特定ファイル内での読み書きを許可できます。これは認可の一形態です。
つまり、認証はユーザーのアイデンティティを検証し、認可はユーザーが持つデータと特権への具体的なアクセスを検証します。システムは、認証と認可の両方を要求します。CASサービスは認証部分のみを提供し、別のレイヤーに認可も実装する必要があります。
CASの利点
CASプロトコルには、次のような多くの利点があります。
- 利便性：ユーザーは、1つのセッション中にCASサーバーに1回ログインするだけで、追加のログインを必要とせずに複数のWebアプリケーションにアクセスできます。
- 一貫性：各ユーザーは、CASサーバー上で同じログインページを持ちます。
- アプリケーションに必要な労力の削減：Webアプリケーションは、独自の認証インフラストラクチャ/プロセスを使用したり、継続的に発明したりする必要がありません。
- セキュリティ：Webアプリケーションは、ログイン資格情報やパスワードにアクセスできません。
CASプロトコルは、初期セットアップに少し時間がかかる場合がありますが、摩擦の少ないエンドユーザーエクスペリエンスを提供できます。また、個々のWebアプリケーション内で認証プロセスを管理する代わりに、1つのシステムで処理する集中サーバーがあるため、継続的な保守が容易です。
認証プロトコルを一度に1つずつ埋め込む必要はありません。代わりに、WebメールサーバーやWebメールクライアントなど、複数のWebアプリケーションを一元化された信頼できる1つの場所で管理できます。
主なポイント
CASプロトコルは、オープンソースのシングルサインオンサービスであり、ユーザーは1つのセッションで1つの信頼できるサーバーに1回サインインすると、その後何度もサインインせずに複数のアプリケーションにアクセスできます。これにより、生産性、速度、そしてエンドユーザーエクスペリエンスが向上します。
CASプロトコルでは、すべてのユーザーが直接ログインする信頼できる集中型CASサーバーが使用されます。ユーザーがログインすると、システムはCookieを使用して残りのセッションでユーザーを「記憶」します。
認可を必要とするWebアプリケーションにアクセスしようとするユーザーは、最初に認可のためにCASサーバーにリダイレクトされます。認可されると、サービスチケットがURLに添付されます。ユーザーが別のWebアプリケーションにアクセスすると、認可はバックエンドで処理され、ユーザーが関与する必要すらありません。
CASプロトコルは安全であり、Webアプリケーションからパスワードを隠します。また、利便性が高く、ユーザーフレンドリーです。
参考文献
Central Authentication Service（Microsoft Academic）
CASEnterprise Single Sign-On（Apereo Foundation）
Python-cas/ Python-cas（2021年、GitHub, Inc.）
Getting Started（Apereo Foundation）