ESF API には 2 つの認証関数があります:AUTH および XAUTH。AUTH は MTO で使用されます。XAUTH は現在 MFDS によって使用されていますが、将来的には、その他の非 MTO 機能 (Web サービスなど) でも使用される可能性があります。
AUTH にはメインフレーム形式のアクセス許可が実装されており、ユーザーはすべての "下位" アクセス許可 (たとえば、書き込みアクセスは暗黙的に読み取りアクセスを示す) を含むアクセス許可レベルを付与されます。XAUTH には、最大 32 ビットの独立アクセス許可ビットを使用するより近代的な自由裁量のアクセス制御 (DAC) が実装されています。Enterprise Server MTO サブシステム (CICS など) は AUTH とメインフレーム アクセス許可を使用し、MFDS は XAUTH と独立 (別名 "拡張") アクセス許可を使用します。
通常リソースは MTO 用または MFDS 用のいずれかとして定義されるため、1 つのオブジェクトに 2 種類のアクセス許可が適用されることはほとんどありません。もし何らかの理由でそのようになってしまった場合、目的の MFDS アクセス許可を指定した allow ACE は、指定された最も高いアクセス レベルをメインフレーム形式アクセス許可にも付与します。たとえば "allow:user:read,update" は、MFDS で読み取りと更新のアクセス許可、MTO で更新レベルのアクセス許可を付与します。
メインフレーム形式アクセス許可は 6 つのレベルからなる厳格な階層です。
メインフレーム形式アクセス許可では、ACE 内の "add" および "delete" トークンは "update" と同じ意味になります。"none" トークンは allow ルールでは最下位レベル (no access) と同じ意味となり、deny ルールでは低い順位の deny ルールをオーバーライドするだけで、それ以外の効果はありません。"all" トークンは最高レベル (現在は "alter") と同じ意味です。
そのため直交的なアクセス許可のセットではなく、多くの DAC システムのように allow ルールで増やすことが可能な現在のアクセス許可レベルを採用しました。
求めているアクセス レベルまたはそれより下位のアクセス レベルに対する deny ルールがある場合、要求は拒否されます。たとえば、ユーザーが更新のアクセス権を求めている場合、そのユーザーは control の deny の影響は受けませんが、read の deny の影響を受けます。なぜなら、更新には read が必要になるためです。
独立 (または拡張) アクセス許可では、各アクセス許可が個々に独立しています。独立アクセス許可モデルでは、ユーザーがリソースへの書き込みアクセス権を持ちながら、読み取りアクセス権を持たないこともあります。独立アクセス許可は、ESF の呼び出し元が XAUTH 要求を使用している場合に使用されます。現在は MFDS のみが XAUTH を使用しています。
独立アクセス許可では特定のリソースに対するアクセス許可のセットがユーザーに付与されます。このアクセス許可のセットには、次の一部またはすべてが含まれるか、いずれも含まれません。
Allow ACE は指定されたアクセス許可をセットに追加し、deny ACE は指定されたアクセス許可を削除します。(順位が同等の allow と deny の ACE がユーザーに対して同一のアクセス許可を指定している場合、deny が allow をオーバーライドするため、そのアクセス許可は無視されます。)
独立アクセス許可の場合、"all" トークンはすべてのアクセス許可 (つまり、"execute、read、update、add、delete、control、alter" と同じ意味) を設定することに相当し、"none" トークンはいずれのアクセス許可も設定しないことを意味します。