RealServer認証を利用することにより、ストリームを送信するエンコーダ、RealSystem Administratorをチェックするサーバ管理者、料金を支払ってコンテンツを見るユーザなど、あなたのRealServerにアクセスできる人（またはアプリケーションなど）を制限することができます。
認証とは、ストリーム配信メディアをリクエストするユーザまたはRealPlayerの身元を確認することです。確認は名前とパスワードを尋ねる形をとることもあれば、ユーザに知らせないで行う場合もあります。
以下のRealServerエリアに対しては名前とパスワードを要求できます。
上記各項目について認められたユーザ名は別々のデータベースに保存されます。認証されたエンコーダユーザの名前が1つのデータベースに保存され、別のデータベースには他の管理者名、さらに別のデータベースにはプレゼンテーションを見られる人々の名前が保存されます。認証エリアとデータベースを追加設定できます。
RealServerは、保護コンテンツに対する（URL形式の）リクエストを、マウントポイントによって識別します。URLはマウントポイントを含まなければなりません。また、追加のディレクトリ情報を含むことがあります。エンコーダはこの例外です。RealServerはコンテンツを受け入れるかどうか決める場合に、ライブデータが到着するポート番号を調べます。
ユーザがエンコーダをセットアップしてストリームをRealServerへ送信するとき、ユーザ名とパスワードの提出を要求できます。こうすれば、認証された人々だけがあなたのRealServerへストリームを送信することができます。
認証されていないユーザがRealServerを変更できないようにするために、RealServerのインストール直後の状態では、RealSystem Administratorアクセスに対する認証が有効になっています。RealServerは、RealSystem AdministratorとしてRealServerを変更することを認められている人々のユーザ名とパスワードを別個にデータ保存しています。
もっとも一般的なのは、個々のプレゼンテーションやクリップのディレクトリへのユーザのアクセスを制限する使い方です。
他の方法と同様に、コンテンツを見ることを認められたユーザの名前とパスワードは1つのデータベースに保存されています。ただし、追加データベースを使って、各ユーザがどのコンテンツを見られるか、どんなタイプのアクセス権を持っているかをリストにまとめておくことができます。デフォルトの方法では、これらすべての情報を1つのデータベースに保存します。
個々のクリップへのアクセス権のタイプには、見る回数を制限する、あるいは回数を制限せずに、見た回数をRealServerが記録する、などがあります。他にも利用できる方法があります。それらの方法は「クリップとディレクトリのパーミッションタイプ」で説明しています。
認証には、名前およびパスワードを要求する認証（ユーザ認証）と、アクセスしてきたユーザのアクティビティを追跡できるプレイヤ認証の2つの「レベル」があります。
 |
追加情報 |
|---|
| 帯域幅、接続量、クライアントのバージョン、またはIPアドレ スに注目してRealServerへアクセスするユーザを制限するには、 第14章「RealServerへのアクセス制限」で説明する方法を使っ てください。 |
バージョン3.0以前のRealPlayerでは認証が機能しないので、エラーメッセージが表示されることがあります。RealPlayerバージョン4.0ではプレイヤ認証だけを利用できます。RealPlayerバージョン5.0以降はプレイヤ認証とユーザ認証の両方をサポートしています。
この機能を使うかどうかを決定するときに参考になる要因を以下に挙げます。
認証はRealServerの他のあらゆる機能と組み合わせて使えます。ただし、各機能ごとに注意事項があります。
Secureディレクトリ（またはサブディレクトリのどれか）に保存してあるすべてのオンデマンドファイルは、認証機能をセットアップすると自動的に認証されます。
認証機能がセットアップされている場合、ライブブロードキャストのパスの一部に/secure/が含まれている場合、そのブロードキャストは、イベントをエンコードするときに自動的に認証されます。
アーカイブされたファイルはオンデマンドファイルです。このタイプのファイルは、正しい場所に先に移動することにより認証されます。ファイルは、SecureディレクトリかSecure内のサブディレクトリに置かなければなりません。
他のライブイベントと同様に、livefileについて入力するパスに /secure/ を含めておいた場合、G2SLTAによって作成されたブロードキャストは認証されます。
スプリッタとして機能するRealServerにストリームを送信する場合、認証情報を保存するすべてのデータベースのコピーをスプリッタに置く必要があります。こうすることにより、認証負荷が分散されます。
バックチャネルマルチキャストとスケーラブルマルチキャストのどちらの場合も、ユーザやクライアントは最初の制御チャネル接続を通じて認証されます。必ずCommerce Rulesリストに、該当するマルチキャスト（/ または/scalable/）パスを置いてください。
RealProxyはクライアントの代理としてリクエストを行い、受信するストリームをキャッシュします。RealProxyはストリーム配信されるデータを保存しますが、リクエストするクライアントとRealServerの間に制御チャネルを必要とします。RealServerは制御チャネルを使って認証情報のリクエストや受信を行います。
認証は双方向チャネルで行います。クライアントがファイアウォールを介してRealServerへの接続を確立できる場合、ファイアウォールを介して接続しているクライアントにはすべてのマテリアルが認証されます。
クライアントのIPアドレスと 認証されているアドレスのリストとを照合するアクセス制御機能は、認証の前に使われます。このため、IPアドレスがブロックされている場合、認証は行われません。保護されたマテリアルを再生できるはずのユーザに対してエラーメッセージが表示される場合は、アクセス規則のリストを調べて、クライアントのアドレスが開示される設定になっているかどうか確かめてください。
コンテンツの認証は、ISPによりホスティングされているカスタマのファイルには適用されません。これらのカスタマのマテリアルは常にアクセス可能です。アクセスのニーズに応じて、アクセス制御規則を適用してカスタマが特定ユーザのコンテンツへのアクセスを許可または拒否できるように設定できる場合があります。
Javaモニタのファイルのパスを見れば、どの保護プレゼンテーションが使用中か監視できます。/secure/マウントポイントを含むものは認証されています。
アクセスログにはユーザ認証の試行は含まれず、成功した認証だけが含まれます。GETステートメントによってアクセスログ内の認証されたマテリアルを識別できます。保護マテリアルはパスに/secure/マウントポイントを必ず含んでいます。
さらに、認証済みマテリアルに対する接続試行は、適切なデータ保存ディレクトリのLogsディレクトリのaccesslog.txtファイル（テキストファイル法を使っている場合）か、Access_logテーブル（データベースによる方法を使っている場合）に保存されます。
エンコーダとRealSystem Administratorユーザの認証には2つの構成要素があります。
コンテンツユーザの認証-コマース機能とも呼ばれます-にはもう1つの構成要素があります。
さらに、プレイヤ認証を使っている場合、RealServerはもう1つのリストが必要です。
コンフィグレーションファイルの中で、これら4つのエリアはそれぞれ別個のリストにあります。
4つのメインエリアは互いへの参照を含みますが、フレキシビリティを考えて別にしてあります。2つの別個の保護パスが同じレルムを（したがって同じデータベースを）使って、別の場所にあるコンテンツに対して同タイプの認証を行うことがあります。これによって、認証されているユーザの同じリストを異なるタイプのコンテンツで共有することができます。
レルムには、認証プロトコルのタイプと認証されたユーザ名を保存するデータベースについての情報が含まれています。 Windows NTを使ってユーザを認証する場合、レルムにはNT認証のタイプとNT管理者が定義したグループ名が含まれています。
RealServerにはアクセスするユーザの身元を認証する方法が3つあります。
あなたのRealServer上にあるコンテンツにアクセスするクライアントがバージョン5.0またはそれ以前のRealPlayerである場合は、コンテンツ認証に必ずRealSystem 5.0方式を使ってください。
Basic認証プロトコルは、ユーザ名とパスワードをBase64アルゴリズムでエンコードして送り、RealServerはそのパスワードをデコードして確認します。
このプロトコルは、単純に一般のインターネット経由でユーザのパスワードを送ります。ユーザはこのマテリアルに対して一意のパスワードを使わなければなりません。
RN5認証は、RealServerバージョン 5.0で開発されたRealNetworks独自の認証プロトコルです。
RealPlayerバージョン 5.0以降を使うユーザにマテリアルを配信する場合は、この認証プロトコルを使います。
これはBasic認証より複雑な認証プロトコルです。解読可能な方法でパスワードを送信しないので、Basicより安全です。
RN5認証では、RealServerはすべてのパスワードをエンコードした形式で保存します。パスワードはRealServer Administrationページを通じて登録や変更ができます。
パスワードツールはコマンドラインユーティリティで、RealServer Binディレクトリに入っています。
mkpnpass username realm
usernameとは、認証に使うデータベースまたはテキストファイルに入力されている、またはこれから入力するとおりのユーザ名です。
realmとは、関連するリストで指定するRealm 変数の値です。エンコーダについては、RealSystem AdministratorのBroadcasting G2 EncodersページのAuthentication Realm にあります（コンフィグレーションファイルでは、G2_EncodersリストのRealm変数の値です）。
RealSystem Administratorユーザの場合、コンフィグレーションファイルのFS Mountリスト内のRealAdministrator_FilesリストにあるRealm変数の値を使います（この値を見るにはコンフィグレーションファイルを直接開く必要があります）。
RealServerはMD5ハッシングアルゴリズムでパスワードを暗号化します。MD5("username:realm:new_password")形式を使います。BSDシステムや他のいくつかのUNIXシステムでは、以下のコマンドでこれらのパスワードを作成できます。
echo -n "username:realm:new_password" | md5
企業イントラネットで一般的なNTベースのセキュリティモデルを使うサイトの場合、この方法を使うと、RealServerでユーザグループとパーミッションについて既存NTデータベースを使うことができます。NTFSファイルパーミッションによるコンテンツのアクセス制御もできます。NTLM AuthenticationプロトコルはWindows NT認証を使います。
この方法はWindows NTを使うシステムしか利用できず、RealServerがNTサーバにインストールしてある必要があります。コンテンツを認証するには、Microsoft Internet ExplorerとRealNetworks RealPlayerも必要です。
BasicまたはRealSystem 5.0を選択する場合、認証済みのユーザ名とパスワードを保存するデータベースも選択する必要があります。
|
|
追加情報 |
|---|
| データベースのセットアップについての情報は「データベース のセットアップ」にあります。 |
Windows NT Lan Managerを選択する場合は、データベースを選択する必要はありません。その代わりにRealServerはNTのユーザ名リストを使います。
特定のレルムに認証済みユーザのリストを追加するには、以下の手順に従ってください。
 |
メモ |
|---|
| NTLMユーザはWindows NTが提供するツールを使って管理 しなければなりません。 |
データベースのリストには、データベースインターフェースとデータベースの場所がまとめられています。RealServerには、4つのデータベースインターフェースが含まれています。
認証パッケージは、mSQLおよび一般的なODBCに従うデータベースをはじめとする、一般データベースのテンプレートを含みます。ユーザは、データソースに適当なテーブル構造をセットアップすることによって、テンプレートが存在しないデータベースも扱うことができます。このオプションを使うには、PluginIDリストからrn-db-msqlまたはrn-db-odbcを選択します。
インストール時に、テキストファイル法が使用可能に設定されます。これは、アクセスパーミッション構造をもっともよく見通せる方法だからですが、データベースをフル活用する場合のフレキシビリティはありません。このオプションを使うには、PluginIDリストからrn-db-flatfileを選択します。
 |
ヒント |
|---|
| テキストファイル法を使うのは、単純な記録用途か、完全な データベースをRealServerにリンクする前にシステムをトラブ ルシューティングするのに限って使うのがいいでしょう。小規 模なデータの場合は、テキストファイル法は完全なデータベー スよりも高速です。 |
RealServer 5.0で認証機能を使っていた場合や、サードパーティ製のデータソースプラグインを持っている場合も、RealServer G2でそのプラグインを使えます。このオプションを使うには、PluginIDリストからrn-db-wrapperを選択します。
この手順の手順5では、データ保存の方法を選択するように求められます。利用できるオプションを次のテーブルに示します。
| 使用するデータ保存の方法 | PluginIDリストから選択するオプション |
|---|---|
| テキストファイル | rn-db-flatfile |
| MSQLデータベース | rn-db-msql |
| ODBCに従うデータベース | rn-db-odbc |
| RealServer 5.0以降に対応している、サードパーティ製データ保存プラグイン | rn-db-wrapper |
Flat Fileの場合、必要なのはメインテキストファイルディレクトリへのパスだけです（たとえば、メインRealServerディレクトリ下のenc_r_dbディレクトリなど）。「RealServer データ保存」を参照してください。
mSQLの場合、名前が2つ必要で、ほかに3つのオプション項目があります。
ODBCはmSQLと同じ情報を使いますが、ODBCはHost Nameを要求しません（詳細は「他のタイプのデータ保存のセットアップ」を参照してください）。
RealServerは、URLのパスを見て、クリップまたはプレゼンテーションへのアクセスを認める前に認証が必要なリクエストであると判断します。
コンテンツへのアクセスを保護するには、Protected Pathsのリストにこのパスを追加します。
オンデマンドの認証済みコンテンツへのリンクは、Protected Pathが追加されること以外は、他のオンデマンドコンテンツへのリンクと同じです。
RealServer
Content
Speeches
President
Executives_only
この例で、リストの最後のディレクトリ、つまりExecutives_onlyを認証したい場合は、Protected Pathリストに以下のパスを追加します（メインマウントポイントは/で、RealServerContentディレクトリとして定義してあるとします）。
/Speeches/President/Executives_only
エンコーダユーザ認証はセットアップ時に自動的に設定されます。RealServerのインストール時に、RealServerが使うユーザ名とパスワードを指定してあります。これらは管理者データベースとエンコーダデータベースに追加されてます。RealSystem G2エンコーダのユーザはこのユーザ名とパスワードを使って接続しなければなりません。
RealServerは、エンコーダユーザ認証に以下の設定値を使います（Broadcasting > G2 EncodersをクリックすればRealSystem Administrator内からこれらの設定値を見られます）。
EncoderRealmという名前がついています。まだ存在しないレルムを使いたい場合は、「レルムのセットアップ」を参照してください。
以前のバージョンのエンコーダを使うコンテンツ作成者にはパスワード入力だけが要求されますが、全員が同一のパスワードを使う必要があります。このパスワードは、インストール時に設定するよう要求されたはずです。RealSystem Administratorを使ってパスワードを変更する場合は、接続する全員に必ず新しいパスワードを知らせてください。
RealServerは、エンコーダユーザ認証に以下の設定値を使います（Broadcasting > Pre-G2 EncodersをクリックすればRealSystem Administrator内からこれらの設定値を参照できます）。
「レルムへのユーザ名の追加」の説明に従って、それぞれのエンコーダのユーザとパスワードを追加します。
RealServerはインストール時に、すべてのRealSystem Administratorユーザにユーザ名とパスワードの入力を求めるように設定されます。セットアップ時に入力したユーザ名とパスワードを使ってください。
RealSystem Administratorユーザの認証は、インストール時に使用可能に設定されます。これをオフにするには、コンフィグレーションファイルを修正する必要があります。
付録C「コンフィグレーションファイルの内容」を参照してください。
「レルムへのユーザ名の追加」の手順に従ってください。
コンテンツ認証のセットアップには、エンコーダユーザ認証やRealSystem Administratorユーザ認証で使うオプションの他にもいくつかのオプションがあります。
2レベルの認証を利用できます。プレイヤ認証では、ユーザが最初に登録するときにユーザ名を要求します。それ以降はRealServerは、ユーザにユーザ名もパスワードも要求しません。そのプレイヤのIDは、そのプレイヤを使っているユーザに関係なく、最初のユーザ名に関連づけられます。
ユーザ認証では、ユーザが保護マテリアルへのリンクをクリックするたびにユーザ名とパスワードを要求します。
クリップやディレクトリへのアクセスを許可する前にユーザの身元を確認したいときは、ユーザ認証を選んでください。ユーザ認証の場合は、Webサイトに接続するユーザがどのコンピュータを使っているかは関係ありません。アクセスしてきたユーザが保護メディアを見る前に、管理者はユーザ認証アクセス権限を設定できます。ユーザ認証は、ペイパービュー、VIPデモ、通信教育などのアプリケーションに最適です。
プレイヤ認証は特定の人々ではなく、個々のクライアント（通常はコンピュータ1台に1クライアント）に対してアクセスを許可または拒否します。認証はアクセスしてきたユーザにとって透過的です。つまりユーザが認証を持っていないコンテンツへのアクセスを試みるときにだけダイアログボックスの警告が表示されます。このタイプの認証ではユーザとのやりとりは少なくなりますが、ユーザまたはRealServer管理者がクライアントを一つ一つ登録する必要があります。プレイヤ認証はファンクラブ、プレミアムグループ、マイクロコマース、イントラネット、統計情報の記録など、特定のタイプのマテリアルに対するリクエストを記録するのに最適の方法です。
「オンデマンドコンテンツ用の認証セットアップ」の9にユーザ認証を選択するための手順が記載されています。ユーザ認証は、保護されたパスに基づいて行われます。
RealServerによるユーザまたはクライアントの認証の後で、別のレベルの認証を利用できます。この認証では、すべてのファイルへのアクセスを認めるか、特定のファイルに限定するかを選択できます。これをコントロールするのがEvaluate Permissionsです。Noに設定すると、すべての認証済みユーザまたはプレイヤに対して全ファイルへのアクセスを許可します。Yesに設定すると、RealServerは、リクエストされたURLをチェックしてデータベース内で検索する追加手順を実行します。リクエストしたユーザまたはプレイヤがそのクリップまたはディレクトリに対するパーミッションを持っている場合、RealServerはリクエストされたファイルをストリーミングします。
特定のファイルまたはディレクトリへのパーミッションを調べる場合は、クリップのパーミッション情報を保存するデータベースも指定する必要があります。このデータベースは、ユーザ名とパスワードを保存するデータベースと同じであることもあります。
Commerceページで、Evaluate PermissionsリストからYesを選択します。この設定値は規則に適用されます。それぞれの規則に異なる設定値を使えます。
このボックスを選択した場合、各ユーザ、および各ユーザに対してアクセスを許可する各クリップまたはディレクトリに、パーミッションのタイプをセットアップする必要があります。パーミッションのタイプのリストについては以下のセクションを参照してください。
アクセス制御機能は、ユーザが特定のプレゼンテーションを見られる時間を決定します。これらはデータストレージに示されています。アクセス権には4タイプあり、以下に詳しく説明しています。
1つのRealServerで、クリップまたはクリップがあるディレクトリに対する複数のタイプのアクセス権を同時に与えることができます。
Eventアクセスでは、アクセスに先立って、1つまたは複数の特定のメディアクリップに、回数を制限しないでアクセスする権利がユーザに与えられます。
失効したアクセスの処理はEventアクセスの処理後に行われますが、パーミッションは、失効日中は与えられます（たとえば、複数の指定されたビデオのいずれかまたはすべてを、次の週の間、回数を制限しないで見られるパーミッション）。
ユーザがクリップを再生中に、失効する日付と時刻が来た場合、再生中のユーザへのそのクリップの送信は停止し、エラーメッセージが表示されます。
このタイプでは、ユーザにはクリップを見るための時間（秒単位）が決まった長さだけ与えられます。RealServerはこの時間から実際に使った時間を引いていきます。
タクシーのメーターと同様に、ユーザがアクセスを許可されているプレゼンテーションを再生した時間をカウントします。プレゼンテーションを見るのにかかった時間がRealServerにより記録されます。管理者は後でこの情報を課金目的に使います。アクセス権はプレゼンテーションまたはディレクトリ単位で与えられ、無制限です。
自分のデータベースを使っている場合は、RealSystem Administratorを使わずに直接修正できます。
|
|
メモ |
|---|
| クリップまたはディレクトリへのアクセス権は1タイプだけに します。複数のタイプがあるとコンフリクトが起きます。 |
アクセスを制限したいマテリアルがあるディレクトリを確認します。
保護マテリアルを含むディレクトリが複数あって、それらが物理的に異なる場所にあることがあります。
デフォルトのコンフィグレーションでは、認証するすべてのマテリアルを含む、Secureという名前のディレクトリが1つ作られます。保護ディレクトリがサブディレクトリを含む場合は、Protected Pathのマウントポイントにそれらのサブディレクトリを追加します。たとえば、Earningsという名前を持つ、Secureディレクトリのサブディレクトリの場合は、/secure/EarningsとしてProtected Pathに追加します。（保護されたパスとして1つのマウントポイントが追加されたことを確認してください。マウントポイントの追加が正しく行われなかった場合、メインのSecureディレクトリに何を入れても認証されなくなってしまいます）。
Noにします。データベースのパーミッション情報を参照する場合は、Yesを選択します。
Yesにします。通常ユーザが保護マテリアルに接続できるのは一度に1台のコンピュータからだけです。2台目のコンピュータからログインしようとすると、ユーザに対してエラーメッセージが表示されます。最初の場所からログアウトしてからでなければ、2つ目の場所からのログインは許可されません。
エンコードしたマテリアルを送信するパスが複数あることがあります。
SecureG2LiveContentを選択します。
encoder/secureと入力します。
これ以外に認証済みコンテンツ用のパスを使っている場合は、それらのパスで使う新しい規則を作成します。
「オンデマンドコンテンツ用の認証セットアップ」の手順5にある例を使って説明すると、コンテンツ作成者がsecure/Earnings/パスに対してエンコードする場合は、Rulesボックスにencoder/secure/Earningsを追加し、コンテンツ作成者がRealProducer PlusのFilenameボックスでsecure/Earnings/を必ず使うようにします。
http://RealServer.company.com:8080/ramgen/encoder/secure/Earnings/report.rm.
Noにします。データベースのパーミッション情報を参照する場合は、Yesを選択します。
Yesにします。設定値がNoで、異なる場所からログインしようとするユーザにエラーメッセージが表示された場合は、ユーザが最初の場所からログアウトしてからでなければ、2つ目の場所からのログインを許可されません。
RealServerのデフォルトの状態では、ユーザまたはクライアントが保護コンテンツを受信できるようにするには、適切なデータベースにユーザまたはクライアントの名前が追加されている必要があります。イントラネットサイトでRealServerを管理している場合なら、これで問題ありません。しかしユーザがWebページ経由で自分で登録できるようにしたい場合に備えて、RealServerの特定のバージョンには、WebサイトやRealServerと情報を交換してユーザが自分で登録できるようにするサンプルCGIプログラムとHTMLファイルが含まれています。ユーザによる登録をセットアップするには、提供されている2組のファイルをカスタマイズする必要があります。登録フォームが含まれているHTMLページと、.htmファイルをRealServerとデータ保存ファイルに接続させる.cgiファイルです。説明はメインRealServerディレクトリのCommerce サブディレクトリにあります。
個々のオンデマンドストリームまたはライブストリームへのリンクは、/secure/マウントポイントが追加されること以外は、認証済みでないコンテンツの場合と同様です。
Secureディレクトリにある、オンデマンドコンテンツへのWebページ上のリンクは、以下のような形式です。
http://address:HTTPPort/ramgen/encoder/path/file
http://address:HTTPPort/ramgen/encoder/secure/path/file
ライブブロードキャスト機能を呼び出す/encoder/マウントポイントが含まれていることに注意してください。
ユーザがSMILファイル用の名前とパスワードの入力を要求されるのは、プレゼンテーション内に含まれている、名前とパスワードを要求するファイルの数に関係なく、レルム1つにつき一度だけです。保護マテリアルを含むSMILプレゼンテーションへのリンクをユーザがクリックすると、RealServerはプレイヤに、最初のクリップについてのセキュリティ情報の入力を求めます。このときプレイヤは、ユーザに認証済みの名前とパスワードを入力するよう求めます。入力した情報はプレイヤに保存され、RealServerがそのレルム内の他のクリップに関するセキュリティ情報を要求すると、保存された情報が送信されます。
プレゼンテーションのいずれかのクリップが他のクリップより早く失効する場合、プレゼンテーション全体が停止します。そのプレゼンテーションを見ていたユーザは、管理者から追加の時間を割り当てられるまで、続きを見ることができません。
このため、プレゼンテーション内のすべてのファイルに関するパーミッションを同じにしておくことが重要です。
認証とSMILファイルを整理する最も効率的な方法は以下のとおりです。
SMILファイルを含むすべてのファイルに同一のパーミッションを与えても、期待通りの動作が得られない例の一つです。
ユーザが各クリップを見た時間に応じて、RealServerは該当するディレクトリから見た時間を差し引きます。各クリップの長さが10分で、プレゼンテーション内に3つのクリップがある場合、 RealServerはクリップを見るための時間の合計から30分引きます。ですから、このタイプのアクセス権をセットアップする場合は、割り当てる時間はすべてのクリップの合計でなければなりません。
すべてのクリップとその長さ、および総計ディレクトリアクセス時間を常に把握しておくのは、簡単ではないこともあります。SMILファイルに対してのみアクセス時間を制限するのがよりよい解決策です。