図 1 に示すように、このタイプのアプリケーションは、デーモン・アプリケーション (INETD など) が fork して、そのデーモンが listen しているソケットへの単一のパッシブ接続を処理します。 デーモンは、親ソケット上で bind()、listen()、および accept() サービスを起動します。 次にこのデーモンは、個々の子接続を操作するために新規のプロセスを fork し、オプションで新規プロセスを別の識別に変更し、オプションとして構成済みサーバー・アプリケーションを実行します。 サーバー・アプリケーションは、子接続でデータの読み取りまたは書き込みを行います。
一部のサーバー・アプリケーションは、クライアントとの第 2 の並列接続をサポートしています。この接続はアクティブ接続の場合が多く、クライアント IP アドレスでクライアントがオープンした一時ポートに戻って接続することにより確立されます。 このような特殊ケースのポリシー・マッピングを行う代替方式の説明は、2 次接続アプリケーション・モデルを参照してください。
多くのサーバー・アプリケーションは、クライアントがサーバー・システム上のユーザー ID によりログインすることを許可します。 一部のサーバー・アプリケーションは、クライアントに代わってリソースにアクセスする前に、サーバー・プロセスのセキュリティー環境をクライアント指定の識別に変更します。 その他のサーバー・アプリケーションは、別の通信パス (疑似端末、名前付きパイプ、UNIX ドメイン・ソケットなど) をセットアップしてから、追加のクライアント・プロセスを fork します。 このサーバーは、このクライアント・プロセスの中でセキュリティー環境をクライアント指定の識別に変更し、次にクライアント指定のプログラムまたはログイン・シェルを実行します。
デーモンがサーバー・プロセスに転送する最初の子接続、およびサーバー・プロセスが確立したどの追加接続も、オプションでクライアント認証を要求して、サーバーとして TLS ハンドシェークを行います。fork された各サーバー・プロセスは同じユーザー ID の下で実行されます。 親接続が同じである子接続を操作するために fork されたサーバー・プロセスはすべて、SSL 環境内でセッション ID キャッシュを共用できることが必要です。サーバー・プロセスは、サイト証明書を含む共有鍵リング、またはサーバー証明書を含む秘密鍵リングを使用することができます。使用される鍵リングには、サーバーがクライアントに提示したサイト証明書またはサーバー証明書を検証するために必要な一連のルート証明書が含まれていなければなりません。サーバーがクライアント認証を必要とする場合は、サーバーは、鍵リングで提示されるクライアント証明書を検証するために必要な他のルート証明書も持っていなければなりません。
サーバー・プロセスによって fork されたクライアントは、どれも AT-TLS により新規のアプリケーションとして扱われます。確立された新規の接続は、その接続を作成したサーバー・プロセスとの間で SSL 環境を共用しません。