test

Sun Enterprise Authentication Mechanism ガイド

SEAM はどのように動作するのか

次に、SEAM 認証システムの概要を説明します。詳細は、「認証システムの動作」を参照してください。

SEAM セッション開始後、自動的に認証システムが働くのでユーザーは認証について意識する必要はありません。rsh や ftp などのコマンドは通常の方法で動作します。SEAM セッションを初期化するには、ログインして Kerberos パスワードを入力するだけです。

SEAM システムにおいて重要な概念は「チケット」です。チケットとは、ユーザーやサービス (NFS サービスなど) の身元証明書となる電子情報の集合です。免許証が人を識別し、どの種類の免許を持っているかを示すように、チケットはユーザーを識別し、どのネットワークアクセス権を持っているかを示します。SEAM ベースのトランザクションを実行するとき (たとえば、rlogin を使用して他のマシンにリモートログインするとき)、ユーザーは透過的にチケットの要求を鍵発行センター (KDC) に送信します。そして KDC はデータベースにアクセスして、ユーザーの身元を認証します。そして、他のマシンにアクセスする特権を与えるチケットをユーザーに戻します。「透過的」とは、ユーザーが明示的にチケットを要求する必要がないと言うことです。この要求は、rlogin コマンドの一部として実行されます。認証されたクライアントだけが特定のサービスのチケットを取得できるため、他のクライアントは rlogin できません。

チケットは特定の属性を持っています。たとえば、チケットには転送可能 (新たに認証を行う必要なしに他のマシンで使用できること) や、遅延 (指定した時間までは有効でない) を設定できます。どのようにチケットが使用されるか (たとえば、どのユーザーがどのタイプのチケットを取得できるか) は、SEAM をインストールまたは管理するときにポリシーで設定します。

注 -

「資格」と「チケット」という用語はよく用いられます。Kerberos では、広い意味でこれらの用語を同じ意味で使用します。しかし、技術的には、資格はチケットにそのセッションのセッション鍵を加えたものです。この違いについては、「SEAM によるサービスへのアクセス」を参照してください。

次の節では、SEAM 認証プロセスを簡単に説明します。

初期認証: チケット許可チケット

Kerberos 認証には 2 つの段階があります。1 つは初期認証で、この後に続くすべての認証に関して許可を与えます。もう 1 つは、それ以後の認証です。

図 1-1 に、初期認証がどのように行われるかを示します。

図 1-1 SEAM セッションの初期認証

Graphic

  1. クライアント (ユーザーまたは NFS などのサービス) は、チケット許可チケット (TGT) を鍵発行センターに要求し、SEAM セッションを開始します。これはしばしばログイン時に自動的に行われます。

    チケット許可チケットは、他の特定のサービスのチケットを取得するために必要です。たとえば、チケット許可チケットはパスポートのようなものです。パスポートと同様に、チケット許可チケットはユーザーを識別し、さまざまな「ビザ」を取得できるようにします。この場合、「ビザ」(チケット) は、外国に行くためのものではなく、リモートのマシンやネットワークサービスのチケットのことです。パスポートやビザと同様に、チケット許可チケットと他のさまざまなチケットには有効期限があります。異なる点は、「Kerberos 化」されたコマンドは、ユーザーがパスポートを持っており、ビザを取得できることを認識しているということです。ユーザー自身がトランザクションを実行する必要はありません。

  2. KDC はチケット許可チケットを作成し、暗号化して、クライアントに戻します。クライアントは、クライアントのパスワードでチケット許可チケットを復号化します。

  3. 有効なチケット許可チケットを取得した後、クライアントはあらゆる種類のネットワーク操作 (rlogin や telnet など) のチケットを要求できます。ただし、これはチケット許可チケットが有効な間だけです。通常、チケット許可チケットが有効なのは数時間です。クライアントは、固有のネットワーク操作を実行するたびに、その操作に必要なチケットを KDC に要求します。

その後の認証

クライアントが初期認証を受け取った後、個々の認証は次のパターンに従います (図 1-2 を参照)。

図 1-2 サービスへのアクセスの取得

Graphic

  1. クライアントは特定のサービスのチケットを KDC に要求します。つまり、rlogin を実行して他のマシンにリモートログインします。このとき、身元の証明として、クライアントのチケット許可チケットを KDC に送信します。

  2. KDC は特定のサービスのチケットをクライアントに送信します。

    たとえば、ユーザー joe がサーバー boston 上で rlogin を実行すると仮定します。joe はすでに認証されている (つまり、すでにチケット許可チケットを持っている) ため、joe は、rlogin コマンドの一部として、チケットを自動的および透過的に取得します。joe はこのチケットを使用して、チケットの有効期限が来るまで、boston にリモートログインを何度でもできます。マシン denver にリモートログインしたい場合、joe は手順 1 と同様に別のチケットを取得します。

  3. クライアントはチケットをサーバーに送信します。

  4. サーバーはクライアントにアクセスを許可します。

上記手順を考えてみると、サーバーが KDC と通信していないように見えます。しかし、実際には通信しています。最初のクライアントと同様に、サーバーは自分自身を KDC に登録します。ここでは詳細な説明は省略します。

SEAM ベースのコマンド

次に、ユーザー (上記例の joe など) が使用できる SEAM ベースの (あるいは「Kerberos 化」された) コマンドを示します。

これらのアプリケーション名は Solaris アプリケーション名と同じです。ただし、SEAM ベースのコマンドは Kerberos プリンシパルを使用してトランザクションを認証します。つまり、Kerberos ベースのセキュリティを提供します。プリンシパルについては、「プリンシパル」を参照してください。

SEAM ベースのコマンドについての詳細は、「SEAM コマンド」を参照してください。

プリンシパル

SEAM のクライアントはそのプリンシパルによって識別されます。プリンシパルとは、KDC がチケットを割り当てることができる、固有に識別される対象です。プリンシパルはユーザー (joe など) でもサービス (nfs や telnet など) でもかまいません。

慣習上、プリンシパル名は 3 つの部分からなります。プライマリ、インスタンス、およびレルムです。典型的な SEAM プリンシパルとして joe/admin@ENG.ACME.COM という例を考えてみましょう。

次に、すべての有効なプリンシパル名を示します。

レルム

レルムは、ドメインのような論理的なネットワークで、同じマスター KDC (下記を参照) の下でシステムのグループを定義します。図 1-3 に、どのようにレルムが他のレルムと関連するかを示します。いくつかのレルムは階層構造 (つまり、他のレルムのスーパーセット) になっています。レルムが階層構造でない場合は、2 つのレルム間のマッピングが定義されている必要があります。SEAM の特徴はレルム間で認証を許可することです。各レルムは、その KDC に他のレルムのプリンシパルエントリを持つだけでよいのです。

図 1-3 レルム

Graphic

レルムとサーバー

各レルムには、プリンシパルデータベースのマスターコピーを保持しているサーバーが必要です。このサーバーのことをマスター KDC サーバーと呼びます。さらに、各レルムで、プリンシパルデータベースの複製コピーを持つサーバーがあれば望ましいですが、なくても動作します。このサーバーのことをスレーブ KDC サーバーと呼びます。マスター KDC サーバーとスレーブ KDC サーバーは両方とも、認証を確立するためのチケットを作成します。

さらに、レルムは 2 種類の SEAM サーバーを持つことができます。SEAM ネットワークのアプリケーションサーバーは、Kerberos 化されたアプリケーション (ftp、telnet、rsh など) へのアクセスを提供するサーバーです。レルムは、Kerberos 認証で NFS サービスを提供する NFS サーバーを持つこともできます。

図 1-4 に、レルムの例を示します。

図 1-4 典型的なレルム