DECwindows では，DECnet トランスポートもサポートされています。このトランスポートを有効にして使用する前に， HP DECnet Phase IV for OpenVMS ソフトウェアまたは HP DECnet-Plus (Phase V) for OpenVMS ソフトウェアをシステムにインストールして動作させておく必要があります。
ユーザ・ベースのアクセス制御 では，ホスト，トランスポート，およびユーザ名の組み合わせ (たとえば DECNET ZEPHYR JONES) に対して X ディスプレイ・サーバへのアクセスが許可されます。指定したユーザ名，ノード名，およびトランスポート情報は，選択したユーザ・クラス以外のユーザを遮断するフィルタとして機能します。
ユーザ・ベースのアクセス制御は，許可ユーザ・リストまたはアクセス許可リストのどちらかにエントリがあるかぎり常に有効です。この形式のアクセス制御は，暗号化機能がなく， TCP/IP 環境でユーザ名を指定することができず，最もセキュリティが低いため，ローカル，DECnet，または LAT 環境でアクセスを許可するためにだけ使用することをお勧めします。
トークン・ベースのアクセス制御では，接続要求時にクライアント・アプリケーションから提示されたパスワードまたはトークンに基づいて X ディスプレイ・サーバへのアクセスが許可されます。クライアントの認証レベルと認証方法は， Magic Cookie (MIT-MAGIC-COOKIE-1) と Kerberos (MIT-KERBEROS-5) のどちらのプロトコルを使用するかで変わります。
一般に，トークン・ベースのアクセス制御で保護されたサーバにクライアント・アプリケーションがアクセスしようとするたびに，サーバは X authority ファイルを参照して，使用する適切なプロトコルと，接続を許可するために使用する認証方法を判断します。
トークン・ベースのプロトコルでは，より高い保護が得られるだけでなく，オープンされたサーバ接続上で実行できる操作についてもより詳細な制御が可能です。たとえば，トークンを使用して信頼特権を許可または拒否することができます。 X ディスプレイ・サーバへの信頼されていない接続では，その接続上で実行できる操作が大幅に制限されます。
注意
XDM-AUTHORIZATION-1 や SUN-DES-1 などのその他の X ウィンドウ・システムのセキュリティ・プロトコルは，現在サポートされていません。これらのプロトコルを使用して DECwindows の X ディスプレイ・サーバにアクセスする他社製のクライアント・アプリケーションは，デフォルトでユーザ・ベースのアクセス制御になります。
Magic Cookie は，ホスト・ベースのセキュリティ・メカニズムに代わるより安全なメカニズムを提供するために設計されたもので， X ウィンドウ・システムの以前のリリースでも利用可能です。このプロトコルは，トークン・ベースのアプローチとしては最初のものであり， X ディスプレイ・サーバへのアクセスをユーザ・レベルで制限するための標準的な手段として初めて提供されました。
Magic cookie では，cookie と呼ばれる，クライアントがサーバに対して提示するバイナリ数値に基づいてサーバへの接続が許可されます。通常，クライアントはこの cookie 値を X authority ファイルから取得しますが，プログラムによっては他の方法も使用します。
X authority ファイル内の Magic Cookie アクセス制御の各エントリには，以下の内容を指定します。
X ディスプレイ・デバイスのアドレス
プロトコル名 (MIT-MAGIC-COOKIE-1)
ランダムな数値の cookie 値
注意
Kerberos は，ネットワーク接続上でやり取りされるすべてのデータを暗号化するために使用するセッション鍵を生成するように設計されています。 X ウィンドウ・システムでは，この鍵を使用して最初の認証メッセージだけが暗号化されます。いったんクライアントの身元が確認されると，以降のデータは暗号化されずにネットワーク・チャネル上で送信されます。そのため，サーバ自体はネットワーク・レベルの攻撃を受けることがあります。
X authority ファイル は，X ディスプレイ・サーバへの接続を許可するために使用する情報が格納されたバイナリ・データ・ファイルです。クライアント・アプリケーションは，X サーバに接続しようとするたびに，最新の X authority ファイルを参照して，接続を認証するために適用する適切な承認キーを決定します。
デフォルトでは，Magic Cookie または Kerberos アクセス制御が構成されたシステム上のデスクトップにユーザが最初にログインしたときに，自動的に X authority ファイルが作成されます。このファイルはそのユーザの OpenVMS ログイン・ディレクトリ (SYS$LOGIN:DECW$XAUTHORITY.DECW$XAUTH) に保存されます。以降ユーザがそのシステムのデスクトップにログインするたびに，新しい承認キーが生成され，X ディスプレイ・サーバに渡されて，ユーザの X authority ファイルに書き込まれます。このキーは， DECwindows Motif セッションの間，X ディスプレイ・サーバへのアクセスを制御します。
通常の DECwindows Motif のログイン処理とは異なるサーバへのアクセスが必要なクライアント・アプリケーション用に，別の X authority ファイルを手動で定義することができます (DECW$SERVER_XAUTHORITY シンボルを使用します)。
セキュリティ拡張が有効な場合，承認キーを手動で生成することもできます。手動で生成したキーを使用して，サーバへのアクセスをさらに制限することができます。生成されたキーはクライアント・システム上の X authority ファイルに格納され，指定されたディスプレイ・サーバに対する既存の値を上書きします。特定のサーバへの接続を許可するために，キーをさまざまなクライアント・システムに配布したり，以降の接続を止めるために破棄することができます。
生成されたキーには，承認 ID が割り当てられます。これによって，キーとそれを生成したユーザが関連付けられます。その結果，キーを生成したユーザだけがキーを破棄することができます。
デフォルトでは，ローカルの SYSTEM アカウントに対して信頼権限が与えられます (ローカル・トランスポートまたは DECnet トランスポート上で)。このファイルのエントリは，トークン・ベースの認証方式が有効になっていないかぎり，アクセス許可ファイルに自動的に追加されます。トークン・ベースの認証方式が有効な場合は，アクセス許可リストに手動でエントリを追加するか，適切な X authority ファイルにエントリを追加することで，信頼されたユーザによる X ディスプレイ・サーバへのアクセスを許可する必要があります。
