クレームには、認証済みのユーザーまたは組織が自身または別のサブジェクトについて作成する複数のステートメントが含まれます。たとえば、ステートメントは、名前、グループ、購買嗜好、国籍、雇用状況、教育レベル、または能力に関連するものである場合があります。

SAML 1.1、SAML 2.0、Simple Web Token (SWT)、JSON Web Token (JWT) など、さまざまなクレーム トークン形式があります。

クレームは追加のデータを提供できます。これはつまり、アプリケーションは ID プロバイダと直接通信する必要がないことを意味します。

クレーム トークンは、正しい ID プロバイダ (IdP) によって発行されたことを検証するために署名されます。

セキュリティ トークン サービス (STS) はユーザーを認証し、クレーム トークンを返します。

セキュリティ トークン サービスの概念を理解するには、セキュリティ チェックポイントのある空港を想像してください。警備員の役割は、認証された適切な乗客のみが通過できるようにすることです。これを達成するために、警備員は乗客にパスポートまたは政府機関などの信頼できる第三者 (セキュリティ トークン サービス) によって付与された国発行の ID (トークン) の提示を求めます。これは、空港が乗客の身元を認証する義務を免除され、発行当局を信頼し、同時に、提示された書類の信頼性を保証することを意味します。したがって、空港は乗客の身元に関する主張を確認することができます。

さらに、空港ではエコノミー クラスの乗客とファースト クラスの乗客に対して異なる搭乗プロセスを提供する場合があります。警備員は、乗客のクラスを示す搭乗券などの追加のトークンを要求する場合があります。このトークンの信頼済みの発行機関は通常、航空会社自体です。搭乗券に乗客がファーストクラスの旅行者であることが示されている場合、空港はそれに応じたサービスを提供し、認証済みのファーストクラスのステータスを優先保安検査や高級ラウンジへのアクセスなどの特典に変換します。

ID プロバイダ (IdP) は、ユーザーを認証し、クレーム トークンを返す STS を提供します。

IdP の例:

• オンプレミス: AD FS 2.0 を使用した Windows Server Active Directory (SAML 2.0 およびその他のトークン形式をサポート)。

• パブリック クラウド: Microsoft Entra ID、OneLogin、Ping Federate など。

フェデレーション プロバイダ (FP) は、他の STS を信頼する STS (リソース STS とも呼ばれます) を提供します。FP は、信頼済み STS から受信したトークンに対してクレーム変換を実行できます。

フェデレーション プロバイダの例:

• オンプレミス: AD FS 2.0 および Ping Federate を使用した Windows Server Active Directory。

• パブリック クラウド: Microsoft Entra ID および Microsoft Entra ID アクセス制御。

クレームに依存するアプリケーションは、リライング パーティ (RP) アプリケーションです。RP の同義語には、「クレーム対応アプリケーション」や「クレームベース アプリケーション」などがあります。Web アプリケーションと Web サービスはどちらも RP であると言えます。リライング パーティ (RP) アプリケーションは、セキュリティ トークン サービス (STS) によって発行されたトークンを使用し、トークンからクレームを抽出して ID 関連のタスクに使用します。

この例では、TotalAgility アプリケーションがリライング パーティです。

• 認証メカニズムをアプリケーションやサービスから切り離します。

• ロールを、より柔軟で詳細な認証用のアーティファクトとしてクレームに置き換えます。

• ユーザーのプロビジョニングおよびプロビジョニング解除に関連する IT オーバーヘッドを削減します。

• 外部のフェデレーション パートナーを含む信頼済みドメインに、アプリケーションの機能へのアクセスを許可します。

• 複数の RP アプリケーションに対して単一の ID プロバイダへのシングル サインオンを許可します。

シングル サインオンで一般的に使用される 3 つの標準は、セキュリティ アサーション マークアップ言語 (SAML)、Web サービス フェデレーション言語 (WS フェデレーション)、および OAuth2 です。これらは非常に似通っていますが、互換性はありません。

これらすべての標準によって、すでに 1 つのサイトにログインしているユーザーは、再度ログインすることなく別のサイトにアクセスすることができます (シングル サインオン)。これは、サイトとユーザーが本人であるという証拠をサイトに提示できるようにすることで実現されます。

SAML と WS フェデレーション (WsFed) はシングル サインアウトをサポートし、当事者間で SSO 情報を交換するためのメタデータをサポートします。また、高度な信頼済み Web 内で多くのサイトからなる大規模かつ複雑なフェデレーションの構築もサポートします。シングル サインオン (SSO) は、ユーザーの単一の認証チケットまたはクレーム トークンが複数の IT システムまたは組織全体で検証されるフェデレーション セキュリティ システムのサブセットです。

実際には、ほとんどのユーザーは、Web サイト間のシングル サインオンを可能にする「パッシブ」機能のみを使用します。WS フェデレーションは主に Microsoft によって推奨されており、Microsoft は WS フェデレーションを自社製品に組み込むために多額の投資を行ってきました。SAML は古い仕様であり、多くの ID 管理ベンダーで広くサポートされています。ただし、Microsoft を含むほとんどのベンダーは、両方の標準をサポートするようになってきています。シングル サインオンの問題を解決する場合、両者に大きな違いはありません。これらの言語は異なる用語を使用しています。環境によっては、どちらか一方を使用するほうが簡単にセットアップできる場合もあります。ただし、どちらの言語もシングル サインオンに使用できます。

SAML は古いプロトコルであり、広くサポートされています。Software-as-a-Service (SaaS) ベンダーは、WS フェデレーションよりもこの言語をサポートしていることが多いでしょう。一方、主に Microsoft 環境を使用している場合は、WS フェデレーションのほうがより一般的です。Microsoft の Active Directory Federation Services (AD FS) には、WS フェデレーションと SAML に対する Active Directory のサポートが用意されています。

TotalAgility は、次のタイプのフェデレーションをサポートします。

• サービス プロバイダ (SP) が開始したフェデレーション

• ID プロバイダ (IdP) が開始したフェデレーション

2 つのタイプのフェデレーションにおける違いは、基本的に、誰がログオン シーケンスを開始したかによって決定されます。TotalAgility または ID プロバイダ。

ID プロバイダの場合は、URL でリダイレクト先 (Designer または Workspace) を指定して、logonprotocol クエリ文字列パラメータを指定する必要もあります。

フェデレーション セキュリティの設定は両方のフローに適用されます。

負荷分散されたサーバーにはデフォルトで一意のマシン キー ID があるため、TotalAgility は、負荷分散された環境では渡されたトークンを AD FS から一貫して正しく読み取ることができません。負荷分散環境で AD FS を使用して TotalAgility を設定するには、マシン キーを生成し、すべてのサーバーに伝達する必要があります。