フェデレーション API

目次
casso1283
目次
2
フェデレーション API は、アフィリエイト ドメイン オブジェクト(アフィリエイト、サービス プロバイダ、リソース パートナーなど)に関連するポリシー ストア データの操作をサポートします。
SiteMinder
フェデレーション製品は、SAML 1.x、SAML 2.0、および WS フェデレーション プロファイルをサポートします。パートナーは、セキュアな方式でユーザ プロファイル情報を交換することができます。
SAML アサーション
SAML アサーションには次の項目が含まれます。
  • アフィリエイト属性。以下に例を示します。
    • ユーザ ディレクトリからのユーザ プロファイル情報(ユーザの電子メール アドレス、肩書きなど)。
    • ユーザ権限(アフィリエイト サイトにおけるユーザの信用限度など)。
  • セッション情報(SAML 1.x アサーション) -- たとえば、アサーション プロデューサおよびコンシューマが個別のセッションを維持できるかどうかなど。
ポリシー サーバによって生成されたデフォルト アサーションを変更できます。その場合は、
SiteMinder
Java SDK で作成するカスタム Java クラスを使用してください。
SAML 1.x
SAML 1.x のサポートを使用することで、ユーザは 2 回以上認証情報を提供する必要なしに、コンシューマ サイトに直接またはアサーション プロデューサ サイトからアクセスできます。
ユーザがアフィリエイト サイトで保護されたリソースへのアクセスを要求すると、プロデューサ サイトのポリシー サーバに通知されます。ユーザを認証した後(ユーザがまだ認証されていない場合)、ポリシー サーバは、コンシューマ サイトに関連付けられたアフィリエイト オブジェクトから SAML アサーションを生成します。
すると、アフィリエイト サイトのアプリケーションは、ポリシー サーバから SAML アサーションを取得し、認可の目的およびその他の必要な目的のための情報を使用します。
たとえば、銀行のサイト(プロデューサ サイト)にユーザがログインするとします。プロデューサには、ポリシー サーバ ソフトウェアが含まれています。ポリシー サーバには、クレジット カード サービスを提供するサイトを表すアフィリエイト オブジェクトのほか、銀行と提携した他のサイトを表す他のアフィリエイト オブジェクトも含まれます。ユーザがプロデューサにおいて認証される場合、そのユーザは、クレジット カード サイトのリンクをクリックし、認証情報を再入力せずに、サイトにアクセスできます。
SAML 1.x 擬似コード例
このセクション内の擬似コードは、以下の操作を示しています。
  1. API を初期化します。
  2. アフィリエイト ドメインを追加します。
  3. ユーザ ディレクトリをアフィリエイト ドメインに追加します。
  4. アフィリエイト ドメインでアフィリエイトを作成します。
  5. アフィリエイトにユーザを追加します。
  6. アフィリエイトに属性を追加します。
  7. 既存のアフィリエイト ドメインを取得します。
  8. アフィリエイト ドメイン内のすべてのアフィリエイトを取得します。
  9. アフィリエイト内のすべての属性を取得します。
  10. アフィリエイト ドメインを削除します。
<> を使用して表記されたコメントは、わかりやすくするためにコードが省略されていることを表します。リターン コードの確認は、分かりやすくするために省略されています。
# 1. Initialize the API
use Netegrity::PolicyMgtAPI;
$policyapi = Netegrity::PolicyMgtAPI->New();
$session = $policyapi->CreateSession("adminid", "adminpwd");
 
# 2. Add an affiliate domain
$affdomain = $session->CreateAffDomain("name", "description");
 
# 3. Add a previously obtained user directory to the affiliate domain
# <Obtain $userdir via $session->GetAllUserDirs>
$affdomain->AddUserDir($userdir);
 
# 4. Create an affiliate in the affiliate domain
$affiliate = $affdomain->CreateAffiliate("affname", "password",
http://authurl, 60, 30);
 
# 5. Add users from a previously obtained user table to the affiliate
# <Obtain $user via $userdir->GetContents>
$affdomain->AddUser($user);
 
# 6. Add an attribute for the affiliate
$affdomain->AddAttribute(1, "staticAttrName=StaticAttrValue");
# 7. Get an existing affiliate domain
$affiliate = $affdomain->GetAffiliate("affname");
 
# 8. Get all the affiliates in an affiliate domain
@affiliates = $affdomain->GetAllAffiliate();
 
# 9. Get all the attributes in an affiliate
@affiliateAttrs = $affiliate->GetAllAttributes();
 
# 10. Remove an affiliate domain
$session->DeleteAffDomain($affiliate);
SAML 2.0
SAML 2.0 を使用する場合、セキュリティ アサーションはフェデレーション内の以下のエンティティ間で共有されます。
  • アイデンティティ プロバイダ
    アイデンティティ プロバイダは、SAML 2.0 フェデレーション内のプリンシパルのためのアサーションを生成します。アイデンティティ プロバイダは、プリンシパルがリソースへのアクセスを試行するサービス プロバイダに SAML アサーションを送信します。
  • サービス プロバイダ
    サービス プロバイダは、アサーションで提供される ID 情報を使用して、フェデレーション内のプリンシパルがアプリケーションおよび他のリソースを使用できるようにします。プリンシパルとは、ユーザまたは他のフェデレーション エンティティです。
    サービス プロバイダは、SAML 2.0 認証方式を使用して、SAML 2.0 アサーションの情報に基づいてユーザを検証します。
アイデンティティ プロバイダおよびサービス プロバイダは、SAML アフィリエーションに属することができます。SAML アフィリエーションは、単一のプリンシパルの名前識別子を共有する SAML エンティティのグループです。
サービス プロバイダおよびアイデンティティ プロバイダはアフィリエーションに属することができますが、1 つのエンティティが属することができるのは、1 つのアフィリエーションのみです。各種サービス プロバイダは、アフィリエーションの全域で名前 ID 定義を共有します。アイデンティティ プロバイダは、アフィリエーションにわたってユーザの不明瞭解消を共有します。
アフィリエーションを使用すると、各サービス プロバイダで必要とされる設定が少なくなります。さらに、1 つのプリンシパルに対して 1 つの名前 ID を使用することにより、アイデンティティ プロバイダでのストレージ容量が節約されます。
シングル サインオンの例
プリンシパルは、セキュリティ アサーションを共有することによって、1 つのサイト(アイデンティティ プロバイダとして機能するサイト)にログインした後、別のサイト(サービス プロバイダ)のリソースにアクセスでき、2 番目のサイトでは明示的に認証情報を提供する必要がなくなります。
例: <nete:proxyrules xmlns:nete="http://www.ca.com/" debug="yes">
  1. ユーザは住宅購入者で、不動産業者の Web サイトで認証します。
    ユーザの認証には、任意の認証方式を使用できます。
  2. ユーザは、不動産のリストを表示しながら、住宅ローン金利が魅力的な銀行のリンクに気が付ききます。
  3. ユーザはリンクをクリックします。
  4. 不動産業者のサイトでは、ID プロバイダとして機能するエンティティがユーザの情報を SAML アサーション内にパッケージングした後、SAML 2.0 POST バインディングを使用して、アサーションを銀行のサイトに転送します。
  5. 銀行のサイトでは、サービス プロバイダとして機能するエンティティが、ID プロバイダに関連付けられた SAML 2.0 認証方式を使用して、銀行のサイト上のリソースに対してユーザを検証します。
    この検証は、ユーザに透過的です。
  6. ユーザは、正常に検証されると、銀行のサイト上でレート情報の表示が許可されます。
SAML 2.0 擬似コード例
このセクション内の擬似コードは、以下の操作を示しています。
  1. API を初期化します。
  2. サービス プロバイダのアフィリエイト ドメインを取得します。
  3. メタデータ定数を変数に割り当てます。
  4. サービス プロバイダ メタデータに値を割り当てます。
  5. サービス プロバイダを作成します。
  6. アフィリエイト ドメインに関連付けられたディレクトリからユーザを取得します。
  7. サービス プロバイダにユーザを追加します。
  8. サービス プロバイダのデフォルト スキュー時間を 100 に更新します。
  9. 更新を保存します。
  10. 更新されたスキュー時間を印刷します。
    # 1. Initialize the API
    use Netegrity::PolicyMgtAPI;
    $policyapi = Netegrity::PolicyMgtAPI->New();
    $session = $policyapi->CreateSession("adminid", "adminpwd");
     
    # 2. Retrieve the affiliate domain for the Service Provider
    $affDom=$session->GetAffDomain("AffiliateDomain");
     
    # 3. Assign metadata constants to variables
    $SAML_NAME=SAML_NAME;
    $SAML_SP_AUTHENTICATION_URL=SAML_SP_AUTHENTICATION_URL;
    $SAML_KEY_SPID=SAML_KEY_SPID;
    $SAML_SP_IDPID=SAML_SP_IDPID;
    $SAML_AUDIENCE=SAML_AUDIENCE;
    $SAML_SP_ASSERTION_CONSUMER_DEFAULT_URL=
    SAML_SP_ASSERTION_CONSUMER_DEFAULT_URL;
    $SAML_SP_NAMEID_ATTRNAME=SAML_SP_NAMEID_ATTRNAME;
    $SAML_SKEWTIME=SAML_SKEWTIME;
     
    # 4. Assign values to the Service Provider metadata
    %hsh=($SAML_NAME=>'My Service Provider',
    $SAML_SP_AUTHENTICATION_URL=>
    'http://www.mysite.com/redirect.jsp',
    $SAML_KEY_SPID=>'http://www.spprovider.com',
    $SAML_SP_IDPID=>'http://www.idpprovider.com',
    $SAML_AUDIENCE=>'SSOAudience',
    $SAML_SP_ASSERTION_CONSUMER_DEFAULT_URL=>
    'http://www.defaultconsumer.com',
    $SAML_SP_NAMEID_ATTRNAME=>'attribute'
    );
    # 5. Create the Service Provider
    $sp=$affDom->CreateSAMLServiceProvider(\%hsh);
     
    # 6. Retrieve users from the directory associated with the #affiliate domain—in this case, users in the group HR
    $userDir=$session->GetUserDir("MyNtDirectory");
    $usr=$userDir->LookupEntry("HR");
     
    # 7. Add the users to the Service Provider
    $sp->AddUser($usr);
     
    # 8. Update the Service Provider's default skewtime to 100
    $sp->Property($SAML_SKEWTIME,"100");
     
    # 9. Save the update
    $sp->Save();
     
    # 10. Print the updated skewtime
    print "\n";
    print $sp->Property($SAML_SKEWTIME);
SAML 2.0 アフィリエーション
SAML 2.0 アフィリエーションは、名前 ID ネームスペースを共有するサービス プロバイダおよびアイデンティティ プロバイダから構成されます。また、アイデンティティ プロバイダは、アフィリエーションの全域でユーザ特定プロパティも共有しています。
SAML 2.0 アフィリエーションには、複数の サービス プロバイダおよびアイデンティティ プロバイダを含めることができます。ただし、1 つのサービス プロバイダやアイデンティティ プロバイダは、1 つの SAML 2.0 アフィリエーションにしか所属できません。
例:
プリンシパルは、セキュリティ アサーションを共有することによって、1 つのサイト(アイデンティティ プロバイダとして機能するサイト)にログインした後、別のサイト(サービス プロバイダ)のリソースにアクセスでき、2 番目のサイトでは明示的に認証情報を提供する必要がなくなります。
  1. ユーザは住宅購入者で、不動産業者の Web サイトで認証します。
    ユーザの認証には、任意の認証方式を使用できます。
  2. ユーザは、不動産のリストを表示しながら、住宅ローン金利が魅力的な銀行のリンクに気が付ききます。
  3. ユーザはリンクをクリックします。
  4. 不動産業者のサイトでは、アイデンティティ プロバイダとして機能するエンティティがユーザの情報を SAML アサーション内にパッケージングした後、SAML 2.0 POST バインディングを使用して、アサーションを銀行のサイトに転送します。
  5. 銀行のサイトでは、サービス プロバイダとして機能するエンティティが、アイデンティティ プロバイダに関連付けられた SAML 2.0 認証方式を使用して、銀行のサイト上のリソースに対してユーザを検証します。
    この検証は、ユーザに透過的に行われます。
  6. ユーザは、正常に検証されると、銀行のサイト上でレート情報の表示が許可されます。
SAML 2.0 属性認証機関
SiteMinder
は、リモートサイトで事前に判断されたユーザ属性の値を許可決定の根拠として使用する許可をサポートします。要求にはセッション情報が含まれません。これは、ユーザが必ずしもリモートサイトで認証されるとは限らないためです。
たとえば、カスタマがレンタカー取扱店のサイトにログオンして、料金について問い合わせるとします。カスタマは取扱店によって認証されますが、取扱店では、競争料金を提供するために、カスタマが指定する航空会社からの情報を使用します。レンタカー取扱店は、カスタマの貯めたマイレージに基づくカスタマ品質コードを取得するために、航空会社の Web サイトに要求を入力します。航空会社から品質コードの値(たとえば 1A)が返され、レンタカー取扱店はカスタマイズされた料金表を表示します。
この例では、レンタカー取扱店が SAML リクエスタとして機能し、航空会社が SAML 属性認証機関として機能します。カスタマは属性認証機関によって認証されていません。
ポリシー サーバは、ポリシー式内の変数を使用することにより、この種の認可決定を実施します。ポリシー式では、フェデレーション属性変数によって属性がリモート属性認証機関と関連付けられます。ポリシー サーバはフェデレーション属性変数の解決を試行するときに、属性の値を要求する属性認証機関を決定します。
ポリシー管理 API では、Sm_PolicyApi_SAMLRequesterAttr_t 構造体によって、SAML リクエスタから要求可能な属性が定義されています。この構造体は、属性認証機関で認識されている属性の実際名と、フェデレーション属性変数で使用されているローカル名を指定します。ローカル名は、SAML 2.0 認証方式で定義された変数にマップされます。
SAML 2.0 インデックス付きエンドポイント
アイデンティティ プロバイダでシングル サインオンを設定する際、アサーション コンシューマ サービス(サービス プロバイダが SAML アサーションを消費できるようにするサービス)に対して複数のエンドポイント設定できます。設定したエンドポイントのそれぞれには、アサーション コンシューマ サービスURL への明示的な単一の参照の代わりに、一意のインデックス値が割り当てられます。
割り当てられたインデックスは、サービス プロバイダがアイデンティティ プロバイダに送信するアサーションに対するサービス プロバイダの要求の一部として使用できます。これにより、サービス プロバイダにおいて、異なるアサーション コンシューマ サービスに別のプロトコル バインディング(Artifact または POST)の使用が可能になります。
ポリシー管理 API では、たとえば以下のように Sm_PolicyApi_AddAssertionConsumerServiceToSAMLSP() 関数をコールすることにより、新規のアサーション コンシューマ サービスをプログラム的にサービス プロバイダに追加できます。
iSmApiRetCode = Sm_PolicyApi_AddAssertionConsumerServiceToSAMLSP (
pSmApiSessionHandle,
&structSAMLSPACS2,
pszOid);
パラメータ:
  • pSmAPiSessionHandle は、管理セッションおよびクライアント セッションに関する情報を保持する構造体へのポインタです。
  • pstructSAMLSPACS2 は、Sm_PolicyApi_SAMLSPAssertionConsumerService_t へのポインタです。この構造体は、インデックス、バインディング、およびアサーション コンシューマ サービスURL を指定します。
  • pszOid は、サービス プロバイダの OID を含む文字列へのポインタです。
さらに、API には、アサーション コンシューマ サービスを削除する関数、およびサービス プロバイダ オブジェクトで定義されたすべてのアサーション コンシューマ サービスを取得する関数が含まれます。C ポリシー管理 API サンプル プログラム(smpolicyapiexample.cpp)では、これらの関数の実装方法を示しています。
アフィリエイトに関するサンプル アプリケーション
C サンプル プログラム smpolicyapi は、アフィリエイト機能が強化されています。
アフィリエイト部分を実行するには
  1. SiteMinder
    オプション パックをポリシー サーバにインストールします。
  2. アフィリエイト ポリシーストア オブジェクトを smpolicy.smdif に定義し、オブジェクトをポリシーストアにインポートします。
  3. サンプルをインストールします。これにより、アフィリエイト サンプルで使用されるサンプル ユーザ ディレクトリが作成されます。
3 つの選択肢が smpolicyapi プログラムに追加されています。
  • Affiliate Sample Api をインストールしますか? (Y/N):
    Y
    」を選択すると、smpolicyapi は以下のように動作します。
    • アフィリエイト ドメインを追加
    • サンプル ユーザ ディレクトリをアフィリエイト ドメインに追加します。
    • アフィリエイトをアフィリエイト ドメインに追加します。
    • サンプル ユーザ ディレクトリからユーザをアフィリエイトに追加します。
    • アフィリエイト属性をアフィリエイトに追加します。
  • アフィリエイト ドメインをトラバースしますか? (Y/N):
    「Y」を選択すると、smpolicyapi は以下のように動作します。
    • アフィリエイト ドメインを取得し、それを印刷します。
    • サンプル アフィリエイト ドメイン内のユーザ ディレクトリ OID をすべて取得し、それらを印刷します。
    • サンプル アフィリエイト ドメイン内のアフィリエイト OID をすべて取得し、それらを印刷します。
    • サンプル アフィリエイト ドメイン内のアフィリエイトをすべて取得し、それらのプロパティを印刷します。
    • アフィリエイト内のユーザをすべて取得し、それらを印刷します。
    • アフィリエイト内の属性をすべて取得し、それらを印刷します。
  • Affiliate Sample Api をアンインストールしますか? (Y/N):
    Y
    」を選択すると、smpolicyapi はアフィリエイト ドメインを削除します。
WS-フェデレーション
WS フェデレーション指定情報は、パッシブ クライアント(Web ブラウザなど)でどのようにフェデレーション フレームワークを実装するかを示すプロトコルを提供します。ADFS は Microsoft による WS フェデレーション パッシブ リクエスタ プロファイルの実装です。
WS フェデレーション環境での Web SSO およびサインアウトは、アカウント パートナーおよびリソース パートナーを使用して実装されます。アカウント パートナーは、ユーザを認証して、WS フェデレーション セキュリティ トークンを提供し、これらをリソース パートナーに渡します。リソース パートナーはセキュリティ トークンを使用し、WS フェデレーション セキュリティ トークンの内容に基づいてセッションを確立します。
SiteMinder
がアカウント パートナーとして動作するためには、セキュリティ トークンを消費するリソース パートナーを管理者が定義する必要があります。これは、アフィリエイト ドメインでリソース パートナーを定義することにより実行されます。
SiteMinder
がリソース パートナーとして動作するためには、セキュリティ トークンを提供するアカウント パートナーを管理者が定義する必要があります。これは、WS フェデレーション認証方式を定義することにより実行されます。
C ポリシー管理 API サンプル プログラム(smpolicyapiexample.cpp)には、リソース パートナーの定義、一覧表示、削除方法の例や、WS フェデレーション認証方式の定義、一覧表示、削除方法の例が含まれます。