図 1 に示すように、このタイプのアプリケーションは、単一ユーザーのセキュリティー環境内で完全に実行されます。 多くのユーザーがこのアプリケーションを使用する可能性がありますが、それぞれの使用は独立しており、別々のプロセス内で実行され、他のプロセスとシステム SSL 情報を共用しません。 アプリケーションを使用するたびに行われるソケット呼び出しは、すべて同じ z/OS® UNIX プロセスから行われます。 ほとんどの接続はアクティブ接続であり、このアプリケーションが connect() サービスを使ってサーバーに対して開始する接続です。Web ブラウザーのような一部のクライアント・アプリケーションは、同じまたは異なる IP アドレスで繰り返しサーバーに接続します。
一部のクライアント・アプリケーション (FTP または REXEC など) は、サーバーとの 2 番目の並列接続をサポートします。 この接続はパッシブ接続であることが多く、その確立は、一時ポートにバインドし、サーバーの IP アドレスから戻される単一接続を listen することにより行われます。 このような特殊ケースのポリシー・マッピングを行う代替方式の説明は、2 次接続アプリケーション・モデルを参照してください。
アクティブかパッシブかに関係なく、このアプリケーションによって確立された接続はすべてクライアントとして TLS ハンドシェーク処理を行います。同一ユーザー ID の下で単一プロセスにより確立されたすべての接続は、SSL 環境内のセッション ID キャッシュを共用することができます。サーバーによるクライアント認証が不要な場合は、このクライアントは共有鍵リングを使用可能です。この共有鍵リングには、サーバー証明書の検証に必要なルート証明書のみが含まれます。サーバーによるクライアント認証が必要な場合は、各ユーザー ID はそれぞれ、必要なルート証明書に加えてユーザーの証明書を含む鍵リングを持っている必要があります。RACF® 鍵リング名は、所有ユーザー ID で修飾されて、ユーザー ID/鍵リングとして指定されます。AT-TLS 鍵リング・パラメーターでユーザー ID の明示指定がない場合、現行ユーザー ID が使用されます。したがって、異なるユーザー ID 間で鍵リング名が同じになることがあります。すべてのクライアント・ユーザー ID により同じ鍵リング名が使用されている場合は、単一の TTLSEnvironmentAction 鍵リング・パラメーターにより、クライアント認証のサポートが必要な全クライアントを表すことができます。個々の鍵リングのすべてに同一鍵リング名が付いていると、AT-TLS ポリシー管理は簡素化されます。